Skip to main content ↑ ↓
Topic: uCAN: A protocol stack for microcontroller networking (Read 142341 times) previous topic - next topic

Re: uCAN: A protocol stack for microcontroller networking

Reply #75 –
Quote
Oh, awesome! It'd need a switching regulator too, ideally. If you don't design one, I will. ;)

Not really my thing, I will stick to what I know, kernel driver dev isn't my area and supporting that is way beyond my bandwidth ;-)

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #76 –
[quote author="Folknology"]
Quote
Oh, awesome! It'd need a switching regulator too, ideally. If you don't design one, I will. ;)

Not really my thing, I will stick to what I know, kernel driver dev isn't my area and supporting that is way beyond my bandwidth ;-)
[/quote]

Well, no dev ought to be required. On the RPi it'll take a bit of tweaking but should only require configuration. On the Beaglebone Black it's even simpler: http://www.embedded-things.com/bbb/enab ... one-black/

I just ordered a Beaglebone Black off Farnell, though.

Re: uCAN: A protocol stack for microcontroller networking

Reply #77 –
Well a Beaglebone Black uLan cape would be nice in the collection if you fancy building one. Right now I'm concentrating on LPC11cxx and Xmos based uLan, that will keep me busy for a while!

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #78 –
[quote author="Folknology"]Well a Beaglebone Black uLan cape would be nice in the collection if you fancy building one. Right now I'm concentrating on LPC11cxx and Xmos based uLan, that will keep me busy for a while![/quote]

Awesome! What form factor are you going to use?

Re: uCAN: A protocol stack for microcontroller networking

Reply #79 –
for which?

Re: uCAN: A protocol stack for microcontroller networking

Reply #80 –
[quote author="Folknology"]for which?[/quote]

For the LPC11Cxx and XMOS based expansion boards.

Re: uCAN: A protocol stack for microcontroller networking

Reply #81 –
Well for the Xmos it will be part of an OEC 80x90mm board, with powering and  segmenting (more on this shortly I'm just finishing the layout) but I may also do a slice board in addition after. I haven't quite decided on final form factor for the LPC11c board, but again I will have some specific goals for it beyond just uLan maybe have some led controllers and PWMs, possibly a few switches.

Anything specific folks here want to see on the LPC11C board?

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #82 –
At hardware level I probably run CAN Analizer from a ST microcontroller connectivity line and establish a bridge between CAN and USB or Ethernet (via web service for use with any client). I not see the advantage of using a complex operative system or a powerfull board like RPi. CAN run in processors of low power, at max protocol speed we are in less than 200KByte second. Almost all the ARM Cortex that I use permit DMA between stack buffers or format  text around the CAN stack and redirect it at more high rates than 200Kbyte.

But let´s go with the solution that you are more comfortable and I adapt the C code to my hardware implementation, its the beauty of open solution :-).

Re: uCAN: A protocol stack for microcontroller networking

Reply #83 –
[quote author="Tarloth"]At hardware level I probably run CAN Analizer from a ST microcontroller connectivity line and establish a bridge between CAN and USB or Ethernet (via web service for use with any client). I not see the advantage of using a complex operative system or a powerfull board like RPi. CAN run in processors of low power, at max protocol speed we are in less than 200KByte second. Almost all the ARM Cortex that I use permit DMA between stack buffers or format  text around the CAN stack and redirect it at more high rates than 200Kbyte. [/quote]

Well, just because it's really easy to write and use an analyzer/dumper for a full OS like Linux. I don't know what existing analysis tools are out there, though.

Re: uCAN: A protocol stack for microcontroller networking

Reply #84 –
[quote author="Tarloth"]At hardware level I probably run CAN Analizer from a ST microcontroller connectivity line and establish a bridge between CAN and USB or Ethernet (via web service for use with any client). I not see the advantage of using a complex operative system or a powerfull board like RPi. CAN run in processors of low power, at max protocol speed we are in less than 200KByte second. Almost all the ARM Cortex that I use permit DMA between stack buffers or format  text around the CAN stack and redirect it at more high rates than 200Kbyte. [/quote]

I concur and will be doing this with my Xmos adaptations over the longer term, however sometimes it is useful to short cut this using linux command line tools for doing dirty simulation and testing as it's easy to knock up a set of exercise frames as well as cheap (if not completely reliable) logging.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #85 –
Yes, I can agree with both in other cases when the final product isn´t an analyzer or a measure instrument.

In the practice sometimes Linux (or windows, not apologies here!) it´s a swamp. In the chain of tools sometimes fail the driver, sometimes crash the operative system, sometimes an angel cry and all work ends in the trash bin. Even I don´t know if in the next year when I need other "CAN Analyzer" (because I lost mine board or toast it for sure!) I can buy an exact  RPi ver. B or a BeagleBoard like this design uses and then begin´s with hardware tweaking and software adaptations.

I not say to do the graphic client in an LCD or something similar in the Cortex ucontroller (it´s possible but I need to start from scratch and is silly) but use the ucontroller as a smart interface (perhaps with a SD memory card) and read the commands from something (Rpi, Beagle, tablet, PC, Phone, etc.) connected to an ethernet port as a file or a data stream ( a lot of well know tools do this) or format  the output as HTML code and show it in a web side that act as fast front end. Then if I prefer use it from a tablet or smartphone in the field or from a desktop PC in the laboratory and all works ok. I can use the OS to implement a client, but it only interpret a result in a standard port, not implements a bitbanging CAN library or a specialized hardware. Sorry, I fall in this trap a lot of times in my life and prefer not fall again.

Recently I have a similar situation with OLS from this site. The FPGA Code its a Jewell of Work! It´s left behind a lot of other LA and with some signal conditioning works even better than my old HP Logic Analyzer, but, the interface between core and PC was done with a "slow" USART port with a "slow" controller and for completeness uses JAVA for the client with not very reliable serial drivers. Work? YES, OFF COURSE! It´s a wonder full piece of technology; but Murphy Laws are mandatory and Java client hang up in my worst day, losing the entire data and in some times trying lot of time to communicate. I need to go with my big notebook to a site when a small tablet do his best work.

For justice 90% of time it works like a charm, but in a reliable tool we need almost 99.5% of time. Even when work OK took a "lot of time" download long captures to the client. Somebody says that this LA it´s a toy, but I thing that somebody do a excellent work in the Core and somebody do an excellent work in the client and OLS can be a lot more than a toy. I recommend it for all my friends and we are almost happy but some disappointing. If the people at design time spend 5 more dollars (10% + of final cost) they can use a powerfull processor plenty of memory and power to manage alternatives at the original SUMP protocol and now somebody can try a different approach in the same board. Can I build my own OLS? Yes, off course in the near future but today I continues using my HP in the field.

For all of this prefer a "smart" box that I can use as CAN logger and use something else to read the data an configure the logger.

Re: uCAN: A protocol stack for microcontroller networking

Reply #86 –
Yes, I wasn't suggesting using an RPi in a dedicated CAN logger - I think it would make more sense to have a USB <-> CAN interface. Though I still think it makes more sense to expose it as a CAN network interface on the target PC (where supported - such as in Linux) and allow the use of userspace programs to do the actual analysis, rather than expect that to be done on the device.

Re: uCAN: A protocol stack for microcontroller networking

Reply #87 –
Just wanted to comment and say I think this is a great idea.  It's also the same idea I have been thinking about for a while, which contributed to me finally creating a forum account here.  :-)

Nick, you said you wanted to stick to existing standards / standard pinout.  Do you have anything CAN based in mind that you want to be compatible with? (and is it something that a hobbyist / artist / etc is likely to have or be able to afford?)

I've felt that for the sorts of uses you mention, and I've thought about, it would make sense to have something that is compatible with standard Ethernet cabling instead - that is, picking the CAN pair so that it is possible to run 100Mbit Ethernet in parallel on the same cable.  (Maybe even PoE.)  It's not such a big deal for hackerspaces to run an extra cable, but I can think of a couple of places where running on an already installed Cat 5 would come in useful.

Re: uCAN: A protocol stack for microcontroller networking

Reply #88 –
Quote
Nick, you said you wanted to stick to existing standards / standard pinout.  Do you have anything CAN based in mind that you want to be compatible with? (and is it something that a hobbyist / artist / etc is likely to have or be able to afford?)

Good question! No, I don't have any particular devices in mind - I just think it makes sense to reuse existing standards wherever possible.

Quote
I've felt that for the sorts of uses you mention, and I've thought about, it would make sense to have something that is compatible with standard Ethernet cabling instead - that is, picking the CAN pair so that it is possible to run 100Mbit Ethernet in parallel on the same cable.  (Maybe even PoE.)  It's not such a big deal for hackerspaces to run an extra cable, but I can think of a couple of places where running on an already installed Cat 5 would come in useful.

That's a good point. I'm not sure if it's worth abandoning a standard pinout for, though. How easily available are appropriate splitters?

Re: uCAN: A protocol stack for microcontroller networking

Reply #89 –
Hi and welcome Magetoo

Unfortunately POE (and for that matter Ethernet RJ45) and CAN RJ45 based pinouts are incompatible from a power POV and could result in shorting, one must be very careful not to mix these, I normally use different shell types, colour coding and or warnings when the two are mixed on a given board/product as it is all too easy to mix them up for the end user.

regards
Al