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

Re: uCAN: A protocol stack for microcontroller networking

Reply #15
At work, we've used CAN in building- (and sometimes short inter-building-) sized runs / networks of up to a hundred nodes or so, using the same MCP2551 chip, for about a decade now. While our experience is still severely limited due to very modest volumes (still a lot larger than an average hobbyst might see though), I can confirm having occasional issues with the transceivers burning out for unknown reasons (worse, subsequently shunting the bus). Due to rarity of such events we never could pinpoint the cause, nor reproduce the results (event though at some point we were purposefully jamming a long cable run with anything we could think of, including arc welding right next to it - we didn't have any Tesla coils to test, sorry). Admittedly, the line is a simple twisted pair and the termination a simple 120R resistor at each end. Recently we tried protecting the transceivers with modern low-capacitance TVSs, but one of the new devices also failed the same way soon after, on a short intra-cabinet network no less; so we're really out of ideas and not particularly a fan of the 2551. Hopefully the new 2561/2 will be better.

Other than that, the arrangement worked beautifully all along - because of the run length we only use 125K baud though (still quite sufficient with our rather sparse traffic). I have to say though that while at the time we did look into the existing CAN frameworks, we found all of them a massive overkill for passing around various sensor / actuator data in a homogenous network of MCUs with quite limited resources, so we just went with our own arbitrary low-level CAN ID-based addressing system instead...

Re: uCAN: A protocol stack for microcontroller networking

Reply #16
[quote author="EasyRider"]At work, we've used CAN in building- (and sometimes short inter-building-) sized runs / networks of up to a hundred nodes or so, using the same MCP2551 chip, for about a decade now. While our experience is still severely limited due to very modest volumes (still a lot larger than an average hobbyst might see though), I can confirm having occasional issues with the transceivers burning out for unknown reasons (worse, subsequently shunting the bus). Due to rarity of such events we never could pinpoint the cause, nor reproduce the results (event though at some point we were purposefully jamming a long cable run with anything we could think of, including arc welding right next to it - we didn't have any Tesla coils to test, sorry). Admittedly, the line is a simple twisted pair and the termination a simple 120R resistor at each end. Recently we tried protecting the transceivers with modern low-capacitance TVSs, but one of the new devices also failed the same way soon after, on a short intra-cabinet network no less; so we're really out of ideas and not particularly a fan of the 2551. Hopefully the new 2561/2 will be better.[/quote]

Thanks for the real-world feedback on something very close to the sort of deployment I'm considering.

Quote
Other than that, the arrangement worked beautifully all along - because of the run length we only use 125K baud though (still quite sufficient with our rather sparse traffic). I have to say though that while at the time we did look into the existing CAN frameworks, we found all of them a massive overkill for passing around various sensor / actuator data in a homogenous network of MCUs with quite limited resources, so we just went with our own arbitrary low-level CAN ID-based addressing system instead...

This is something I've yet to address - feedback would be appreciated. I really want to offer simple and consistent APIs across all platforms, and using a system people are already familiar with would be ideal. I tentatively selected CANOpen as a candidate because it's baked right in to some NXP chips, but I'm entirely flexible on this.

I suspect ideal basic functionality would be:
 - Short datagrams (like UDP)
 - Streams (like TCP)
 - RPC-type invocations
 - Some way to discover if a given address is present (enabling eventual implementation of a switch)

Re: uCAN: A protocol stack for microcontroller networking

Reply #17
I've updated the designs with the PESD1CAN TVS, as well as silkscreen improvements.

Here's the power injector PCB; very simple:


Re: uCAN: A protocol stack for microcontroller networking

Reply #18
[quote author="nickjohnson"][quote author="EasyRider"]Other than that, the arrangement worked beautifully all along - because of the run length we only use 125K baud though (still quite sufficient with our rather sparse traffic). I have to say though that while at the time we did look into the existing CAN frameworks, we found all of them a massive overkill for passing around various sensor / actuator data in a homogenous network of MCUs with quite limited resources, so we just went with our own arbitrary low-level CAN ID-based addressing system instead...[/quote]

This is something I've yet to address - feedback would be appreciated. I really want to offer simple and consistent APIs across all platforms, and using a system people are already familiar with would be ideal. I tentatively selected CANOpen as a candidate because it's baked right in to some NXP chips, but I'm entirely flexible on this.

I suspect ideal basic functionality would be:
 - Short datagrams (like UDP)
 - Streams (like TCP)
 - RPC-type invocations
 - Some way to discover if a given address is present (enabling eventual implementation of a switch)[/quote]

Unfortunately I can't much comment on specific aspects of CANOpen considering we never used it ourselves. I'm sure in an open,  varied environment the widely known and used CANOpen would make a lot more sense than in our closed, rigidly-defined environment.

However, I can outline what we had - we simply took the CAN ID and divided it up into a few fields like priority, type (get/set/reply), address (a unique one per device), and "variable number" (defining what specific data in what specific format the following data bytes were supposed to mean). No messages longer than 8 bytes (yet we do firmware update over this - only in tiny chunks, each including the address they're supposed to be written to), no layer for guaranteed delivery (if you didn't get a reply, you knew what happened) etc.

A few universally present "variables" provided switching to/from bootloader, "ping" functionality (including unrequested periodic ping "replies" if desired, as a heartbeat), error counter stats, address assignment (based on an internal unique ID), node identification (command to flash the mandatory bicolor LED in a specific manner) and so on. Every single "variable" message was rigorously checked individually for presence and range of all its elements, etc - any invalid messages were promptly rejected by nodes. Discovery, if desired, was possible by pinging the broadcast address (a specific one all nodes were listening to) then querying all responding nodes about their "class", a single variable which defined unequivocally what the node was/did and which specific "variables" it was supposed to support - that's about it, really; we never needed more.

I'll try to respond to any specific question about CAN as best as I can, but unfortunately I can't tell you much about common protocols currently in use...

Re: uCAN: A protocol stack for microcontroller networking

Reply #19
One thing to consider is cost for micro-controller applications both financial and even power consumption. CAN tends to add quite a lot of cost compared to say RS485/422 which can be implemented very economically. Also many modern micro-controllers have hardware 9 bit uart support for these standards making development easier and in many cases allowing power down (using wakeups/interrupts). Also RS485/422 can normally work across larger distances than CAN which can be important in some cases. Just some points worth considering.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #20
[quote author="Folknology"]One thing to consider is cost for micro-controller applications both financial and even power consumption. CAN tends to add quite a lot of cost compared to say RS485/422 which can be implemented very economically. Also many modern micro-controllers have hardware 9 bit uart support for these standards making development easier and in many cases allowing power down (using wakeups/interrupts). Also RS485/422 can normally work across larger distances than CAN which can be important in some cases. Just some points worth considering.

regards
Al[/quote]

I've found the reverse - MCP2515 + MCP2562 only costs $2-$3, and some microcontrollers have CAN support built-in. RS-485 transceivers aren't any cheaper, and no microcontrollers have them built in to the best of my knowledge.

Re: uCAN: A protocol stack for microcontroller networking

Reply #21
RS485/422 chips like ISL83490IBZ can be had for about $0.60 and can be used with $0.50 µCs which lowers the entry barrier somewhat

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #22
[quote author="Folknology"]RS485/422 chips like ISL83490IBZ can be had for about $0.60 and can be used with $0.50 µCs which lowers the entry barrier somewhat

regards
Al[/quote]

Fair point; somewhat academic now, as I've already started down the CAN bus route. :)

Re: uCAN: A protocol stack for microcontroller networking

Reply #23
No probs just thought I would flag it up as it is something we discovered building various networks. I am not knocking CAN BTW it has its own advantages just not cost/overhead/power (at top of your initial list) :-)

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #24
I not sure that RS485 can comunicate across larger distances than CAN.

CAN it´s a semi complete protocol involving more layers than RS485 and it´s not necessary to create or specify a protocol to arbitry errors and bounces that ever reduce bandwith or reduce the range with electrical restrictions.

At reasonably speeds for a microcontroller that need to comunicate some bytes of data CAN permit 2KM internode. Off course nobody that needs to send multimedia content think in use CAN, it´s only for sensor an actuator data. I see RS485 with 500 meters between master an slave, I hear of a node 1 Km away working and think that it´s possible to implement something similar to 2Km but I´m sure than no better than CAN.

Modern vehicles uses CAN (or their realtime cousin) for life save communication, even modern Airbus uses a modified CAN. In industrial applications CAN is displacing other well know and probed protocols like smbus or profibus and I believe that is replacing this old protocols (some based in RS485). In all the cases it´s necessary a confident network with simplified wired.

Cost point it´s relevant but not to me. I´m not going to produce thousands or millions of devices, at better situations perhaps a hundred and one plus dollar it´s not a matter. Just for this point I migrate all of my projects from 8 bits to 32 bits. I add perhaps 0.5-2 dollars per board but I have a freedom and power that it´s impossible in 8 bits. All of the microcontrollers that I use in the last three years have almost one CAN port and in the case that I need a reduced or cheap but realiable communication I use LIN for long wires or directly I2C for "short" wires. Even more, I´m not sure that a proper RS485 transceiver cost less than a CAN transceiver.

But, I read long time ago that exit a CAN protocol mounted over a electrical RS485 network, perhaps it´s a good option to somebody that not like CAN, but like to use this development.

Re: uCAN: A protocol stack for microcontroller networking

Reply #25
I really like CAN's built in arbitration and guaranteed response times as this has to be cooked up oneself with RS485 (It's up to you what you do on top), But I don't see how you are going to run UDP and TCP like sockets/streams given CAN's 8 byte restrictions and packet expectations, I would have thought that RS485 with your own stack would be far less restrictive for these type of goals. When you go down the CAN route you tend to follow the standard CAN abstracts such as CanOpen etc which have a rather different representation/operation to those you have indicated a preference for (UDP/Sockets/Streams). Often you can layer networks by joining smaller CAN segments using RS485 or Ethernet, this enables one too build bigger networks but still benefit from the arbitration and response times on the local segments. however if you want UDP all of the way through then RS485 segments and ethernet/TCP/IP bridging might be a better route. I guess it depends on how important UDP/Sockets/Streams are to your requirements or if your happy going down the CAN abstracts route, to me you seem to be indicating you have started down the hardware design route with CAN and will continue to do so, therefore it's as you say academic.

Either way I will be interested to see how it all pans out as it's an interesting coms project.

P.S. just for reference here is an RS485 uLan example which you might find interesting ideas wise if you do choose to roll your own.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #26
[quote author="Folknology"]I really like CAN's built in arbitration and guaranteed response times as this has to be cooked up oneself with RS485 (It's up to you what you do on top), But I don't see how you are going to run UDP and TCP like sockets/streams given CAN's 8 byte restrictions and packet expectations, I would have thought that RS485 with your own stack would be far less restrictive for these type of goals.[/quote]

This doesn't seem too difficult. Datagrams are what you already have, albeit with a limit of 8 bytes of payload; streams can be accomplished with a recipient and port identifier in the address field; there's probably no need for TCP's 3-way handshake.

Quote
When you go down the CAN route you tend to follow the standard CAN abstracts such as CanOpen etc which have a rather different representation/operation to those you have indicated a preference for (UDP/Sockets/Streams). Often you can layer networks by joining smaller CAN segments using RS485 or Ethernet, this enables one too build bigger networks but still benefit from the arbitration and response times on the local segments. however if you want UDP all of the way through then RS485 segments and ethernet/TCP/IP bridging might be a better route. I guess it depends on how important UDP/Sockets/Streams are to your requirements or if your happy going down the CAN abstracts route, to me you seem to be indicating you have started down the hardware design route with CAN and will continue to do so, therefore it's as you say academic.

I'm not actually suggesting UDP - I was using it as an example of a datagram protocol.

Re: uCAN: A protocol stack for microcontroller networking

Reply #27
I would just add that datagrams by their very nature are designed and optimised to make maximum network data transfers, by having a a large data to frame ratio, normally via arbitrary length 'grams', they also do not guarantee reception or delivery, they are shaped for data density rather than integrity. This is almost the reciprocal of the CAN 'message' or 'dataframe' which was designed to prioritise data integrity and deterministic operation. If one expects the majority of the network traffic to be shaped like datagrams as opposed to deterministic dataframes you might find that your network does not match your design expectations. Basically CAN networks do have a shape and one needs to go with the flow of that shape, if you wanted something different, you would be better rolling your own, or building on something that already met the requirements.

Remember if you let the network choose you rather than the other way around the network will win out in the long run, a good requirements discussion may be a better place to start than a single network standard unless you want your network to determine your requirements.

Whatever you choose will be your legacy, choose carefully...

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #28
[quote author="Folknology"]I would just add that datagrams by their very nature are designed and optimised to make maximum network data transfers, by having a a large data to frame ratio, normally via arbitrary length 'grams', they also do not guarantee reception or delivery, they are shaped for data density rather than integrity. This is almost the reciprocal of the CAN 'message' or 'dataframe' which was designed to prioritise data integrity and deterministic operation. If one expects the majority of the network traffic to be shaped like datagrams as opposed to deterministic dataframes you might find that your network does not match your design expectations. Basically CAN networks do have a shape and one needs to go with the flow of that shape, if you wanted something different, you would be better rolling your own, or building on something that already met the requirements.

Remember if you let the network choose you rather than the other way around the network will win out in the long run, a good requirements discussion may be a better place to start than a single network standard unless you want your network to determine your requirements.

Whatever you choose will be your legacy, choose carefully...

regards
Al[/quote]

I think this is a disagreement of nomenclature more than anything else. UDP datagrams have the properties you describe, but I don't think that's a fundamental property of anything called a datagram.

My intention was simply to provide for low-overhead packet-based data transmission between nodes as a convenient option.

Re: uCAN: A protocol stack for microcontroller networking

Reply #29
Quote
I think this is a disagreement of nomenclature more than anything else. UDP datagrams have the properties you describe, but I don't think that's a fundamental property of anything called a datagram.

Well all of the datagrams I am familiar with UDP (IP), DDP (Appletalk), IDP (XNS) as wells as RS485 datagram implementations all exhibit features of high data to frame ratios and non guaranteed reliability as opposed to integrity and determinism.

Quote
My intention was simply to provide for low-overhead packet-based data transmission between nodes as a convenient option.
Does CAN provide the best solution to this requirement for you?

regards
Al