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

Re: uCAN: A protocol stack for microcontroller networking

Reply #30
[quote author="Folknology"]
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[/quote]

My desire is simply to offer basic, familiar abstractions to people using the system. Obviously, thus far the software layer is ill-defined, but obvious abstractions seem to be:

 - Datagram based point-to-point or broadcast messaging
 - Stream based point-to-point messaging
 - RPCs

All of these seem tractable over CAN.

Re: uCAN: A protocol stack for microcontroller networking

Reply #31
I agree all of these are tractable over CAN but should also just point out some likely speedbumps :

1) Datagrams - I have already covered the impedance mismatch between datagrams and CAN's dataframes, I would go with native messages instead on a CAN network, it excells at this.
2) Stream based point to point messaging - will likely prove difficult and very inefficient over CAN, due to frame overheads, you also have to be careful you don't end up flooding the network and impeding the single frame messages when imposing these network costs (scaling problems).
3) RPCs - Your remote procedure calls will either suffer severely limited argument passing or impose multi-packet inefficiencies on the transport significantly reducing RPC response times (with your own design these could be better matched and optimised)

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #32
If you still really want to go with CAN take a long look at CanOpen which provides an excellent set of abstractions and good impedance match with the underlying CANBus, it's been developed over a long period and has been heavily tested and deployed, it also has a great deal of community support. If you like what you see go with it, if you don't take a look at other CANBus abstraction layers, however I think it is unlikely you will find the 'familiar abstractions' you appear to desire most. If those 'familiar abstractions' are a priority then you may benefit from revisiting your requirements and tackle the network choice with those as the basis for the requirements, there are plenty of choices out there and you could even think up your own if that's your thing.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #33
[quote author="Folknology"]If you still really want to go with CAN take a long look at CanOpen which provides an excellent set of abstractions and good impedance match with the underlying CANBus, it's been developed over a long period and has been heavily tested and deployed, it also has a great deal of community support. If you like what you see go with it, if you don't take a look at other CANBus abstraction layers, however I think it is unlikely you will find the 'familiar abstractions' you appear to desire most. If those 'familiar abstractions' are a priority then you may benefit from revisiting your requirements and tackle the network choice with those as the basis for the requirements, there are plenty of choices out there and you could even think up your own if that's your thing.

regards
Al[/quote]

I believe CAN to be the best match to the requirements of this sort of bus, though RS485 would work similarly well. My issue with the software layer is that I want this to be really easy for hobbyists to use - and that means abstracting away as much of the complexity of protocols like CANopen as possible. If you've got suggestions for useful abstractions and message types, I'm all ears!

Re: uCAN: A protocol stack for microcontroller networking

Reply #34
Well typical message based abstractions are things like 'Producer and consumer' which is employed by CANOpen and patterns like 'Publish and Subscribe' i.e. simple mailbox type abstractions. These can provide easy to understand clean abstractions from the lower level protocols. however with CANBus you still have message size issues that can't just be papered over.

One approach that handles both small fast messages and larger data transfers is to use two stages, a notification (getting basic header info) stage followed by a query stage (to access the larger data parts)

P.S. Don't forget when employing CANBus (and to a larger extent CANOpen and it's competitors) you are also signing up to some fairly predefined OSI layering some of which you cannot escape.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #35
BTW whatever you do with with CANBus you will need to get your head around it's oddities, I found this    CAN System Engineering: From Theory to Practical Applications by Wolfhard Lawrenz online Goog book link
 rather useful as it went to lengths in order to explain the background why CAN was designed and later successfully emerged. Without this it can be seen as quite a puzzling network protocol bound to a specific transmission layer. I am not really familiar with more modern treatments of CANBus book wise, perhaps some others might be able to help in that regard.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #36
Dear Folknology, I partially agree with you but the part that I not agree it´s really big.

I think that if we are trying to establish a "poor man ethernet" to send images, audio, content of a sdhc memory or something bigger than, for example, 256 bytes, then probably CAN protocol is the worst option. But RS485 too! For some reason millons of devices uses "expensive" ethernet with buffers and horsepower demanding processors and not a simple twisted pair with RS485 isn´t it?

But if we need a standard network protocol and physical media to communicate between different relative low power microcontroller, negotiating a very reasonable amount of data (90% of time less than 256 bytes, 99.9% of time a few bytes) then use a sub protocol of CAN would be a clever option, and not use RS485.

Why? Can was designed to fill a specific hole where Ethernet networks or some protocol mounted on RS485 not cover very well. It´s around this hole that we are talking. 

The most important thing than I think that wee need to remember is that we dealing with microcontrollers with a limited amount of memory and it´s really an exception transmit a ""long"" message. Most of the 8 bit ucontrollers (that implement for years a full CAN network) has less total data memory than the data inside an ethernet packet.

RS485 has a long run in industry but the same industry recognizes a lot of failures or partial success histories when they try to use it in several scenarios. RS485 it´s only the first OSI layer and then barely specifies electrical signaling and a few and very rude and imprecise procedure (not protocol) to address packets of data, data collisions, manage failures, handshaking of a busy network, etc

If we decide to use CAN it´s for not reinvented the wheel.

The electric specification of CAN and RS485 can be compared but It´s not the point. I think the important here it´s not only the electrical wiring and noise immunity of CAN. The protocol behind the wires it´s a big piece of clever design from people that know that they doing. Perfectible? Yes, allways, but it works between the walls that was imposed.

I need when I connect some actors or nodes (sensors, actuators, text displays, keyboards, controllers, etc) to a network :
 
* Ensuring data consistency over all nodes.
* Addressing messages between nodes.
* Avoiding data collisions.
* Detect failures in the messages.
* Automatic repetition of corrupted data.

To obtain that ALL protocols establish rules, some more stricter than others. CAN specifies the structure of the message, with identifier, data and control bytes. To rule them in small ucontrollers they need to balance max message length among other restrictions.

When I use a ucontroler that have a "CAN device" all of the previous point are managed transparent to me. A piece of technology added to my ucontroller dealing with these issues and bring me the possibility that my software only deal with the real problems and not uses 80% of the time to fix problems in the electrical unstable and noisy neighborhood.

If I need to send a message to other node I put in a buffer and not worry how I send. Obtain a result for success or failure and continue with other task. Which magic it´s behind the wiring are absolutely not my problem. In RS485 we need to specify, program and test in real world all these tasks. This would be an interesting academic work, or perhaps in some simplified cases when we need to reduce costs in millions of units  justify, but, almost in my case, I like to use a proven solution and implements the less code necessary to solve the situation. Not for reduce efforts, indeed less code, less future bugs to correct.

Re: uCAN: A protocol stack for microcontroller networking

Reply #37
Dear Tarloth I agree CANBus is excellent, as I have said I am no knocking it, love it for the way that it is as reliable message based system as it was designed. However what Nick is proposing is using more 'familiar abstractions' :

- Datagram based point-to-point or broadcast messaging
- Stream based point-to-point messaging
- RPCs

These do not sit well with CANBus's original design and flow, if you go with CANBus you have to go with it's way, with it's network abstractions.

I will also address some of your points:

[quote author="Tarloth"]Dear Folknology, I partially agree with you but the part that I not agree it´s really big.

I think that if we are trying to establish a "poor man ethernet" to send images, audio, content of a sdhc memory or something bigger than, for example, 256 bytes, then probably CAN protocol is the worst option. But RS485 too! For some reason millons of devices uses "expensive" ethernet with buffers and horsepower demanding processors and not a simple twisted pair with RS485 isn´t it?

But if we need a standard network protocol and physical media to communicate between different relative low power microcontroller, negotiating a very reasonable amount of data (90% of time less than 256 bytes, 99.9% of time a few bytes) then use a sub protocol of CAN would be a clever option, and not use RS485.

Why? Can was designed to fill a specific hole where Ethernet networks or some protocol mounted on RS485 not cover very well. It´s around this hole that we are talking. 
[/quote]

First of all CANBus was not 'designed to fill a specific hole where Ethernet networks or some protocol mounted on RS485 not cover very well' it had very specific abstractions and applications in mind, I think you are super imposing your own view of CAN This might  help explain the history of it's design better.

If we take your 256 byte example and try to transmit this over CANBus we would need 4 frames, for CANbus 2.0b we would in fact transmit more frame than data!! Remember that the max dataframe payload is 8 bytes for CANBus. so for sending messages of less than 8 bytes it is optimised, however expecting to use Datagrams, Streams and RPCs over a frame designed like this would be a mismatch of network packet design.

[quote author="Tarloth"]

The most important thing than I think that wee need to remember is that we dealing with microcontrollers with a limited amount of memory and it´s really an exception transmit a ""long"" message. Most of the 8 bit ucontrollers (that implement for years a full CAN network) has less total data memory than the data inside an ethernet packet.

RS485 has a long run in industry but the same industry recognizes a lot of failures or partial success histories when they try to use it in several scenarios. RS485 it´s only the first OSI layer and then barely specifies electrical signaling and a few and very rude and imprecise procedure (not protocol) to address packets of data, data collisions, manage failures, handshaking of a busy network, etc

[/quote]

RS485 continues to grow in application, just because CANBus was created (back in the 90s) it was not meant to replace RS485 they are different animals, as you point out RS485 is only OS1 and CANBus is OS1+2 so its like comparing apples and oranges. I can assure you that RS485 continues to grow and it has a plethora of different layers above it unlike CANBus's fixed OS2.

[quote author="Tarloth"]

If we decide to use CAN it´s for not reinvented the wheel.

[/quote]

But is it the right kind of wheel that fits Nick's 'familiar abstracts'? Or are we trying to build a bicycle on top of skateboard wheels!

[quote author="Tarloth"]

The electric specification of CAN and RS485 can be compared but It´s not the point. I think the important here it´s not only the electrical wiring and noise immunity of CAN. The protocol behind the wires it´s a big piece of clever design from people that know that they doing. Perfectible? Yes, allways, but it works between the walls that was imposed.

[/quote]

Of course thats because it is designed as OS layer 1 (RS485 also has good common mode rejection), that is the point, you get to choose what sits above it.

[quote author="Tarloth"]
I need when I connect some actors or nodes (sensors, actuators, text displays, keyboards, controllers, etc) to a network :
 
* Ensuring data consistency over all nodes.
* Addressing messages between nodes.
* Avoiding data collisions.
* Detect failures in the messages.
* Automatic repetition of corrupted data.

To obtain that ALL protocols establish rules, some more stricter than others. CAN specifies the structure of the message, with identifier, data and control bytes. To rule them in small ucontrollers they need to balance max message length among other restrictions.

When I use a ucontroler that have a "CAN device" all of the previous point are managed transparent to me. A piece of technology added to my ucontroller dealing with these issues and bring me the possibility that my software only deal with the real problems and not uses 80% of the time to fix problems in the electrical unstable and noisy neighborhood.

If I need to send a message to other node I put in a buffer and not worry how I send. Obtain a result for success or failure and continue with other task. Which magic it´s behind the wiring are absolutely not my problem. In RS485 we need to specify, program and test in real world all these tasks. This would be an interesting academic work, or perhaps in some simplified cases when we need to reduce costs in millions of units  justify, but, almost in my case, I like to use a proven solution and implements the less code necessary to solve the situation. Not for reduce efforts, indeed less code, less future bugs to correct.[/quote]

So what are you proposing to use above the OS1/2 layers that provides the magic that means we do not have to write software, is it CANOpen or one of the other competitors?

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #38
Quote
[quote author="Folknology"]Dear Tarloth I agree CANBus is excellent, as I have said I am no knocking it, love it for the way that it is as reliable message based system as it was designed. However what Nick is proposing is using more 'familiar abstractions' :

- Datagram based point-to-point or broadcast messaging
- Stream based point-to-point messaging
- RPCs

These do not sit well with CANBus's original design and flow, if you go with CANBus you have to go with it's way, with it's network abstractions.
[/quote]

I'm still not sure I agree with this. There's nothing fundamental about any of those abstractions that requires long messages, and CAN itself doesn't specify anything above sending a packet with a single address field and up to 8 bytes of data. I think you could implement any of those abstractions on top of it with relatively little overhead - but this is something that will need exploring.

CANopen is still a candidate for layer 2 - but 'raw' CANopen doesn't provide a particularly straightforward abstraction, and I think that will be critical for adoption.

Re: uCAN: A protocol stack for microcontroller networking

Reply #39
Sorry Nick, quick correction so we don't get mixed up on the layers :

[quote author="nickjohnson"]
CANopen is still a candidate for layer 2 - but 'raw' CANopen doesn't provide a particularly straightforward abstraction, and I think that will be critical for adoption.[/quote]

CANOpen is a layer3-7, CANBus itself is Layer 1+2

[quote author="nickjohnson"]I'm still not sure I agree with this. There's nothing fundamental about any of those abstractions that requires long messages, and CAN itself doesn't specify anything above sending a packet with a single address field and up to 8 bytes of data. I think you could implement any of those abstractions on top of it with relatively little overhead - but this is something that will need exploring.[/quote]

BTW way there are some basic network design rules about balancing the size of data to frames and we clearly seem to be breaking them with these 'familiar' types of expectations, datagrams are designed with variable length payloads for very good reason

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #40
Fundamentaly I believe CANBus has a layer 2 design that is optimised for the transmission of small (<=8 byte) fast deterministic messags delivery with integrity (Incl simplistic acknowledgement/error detect). After all it's primary design goals was to enable sensors to send small signal values to controllers which then send commands to actuators, this is CANBus meat and veg. The layer 2 design is optimised exactly for this type of operation.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #41
An analogy might be helpfull here:
A modern network with familiar abstractions (like RS485/Ethernet running UDP/TCP/IP or some other modern design) is like a road network, it supports different types of vehicles; Motorcycles, cars and trucks, this enables us to convey people and goods using the appropriate class of vehicle. CANBus however is like a courier network that only supports Motorcycles, thus if I need to deliver a crate of bricks I will require the Motorcycle to perform many trips to make the delivery(very inefficient compared to a truck). basically OSI layer II is where one often designs the basic vehicle specifications, for a modern network its good to support different types rather than just a single narrow class to avoid the multiple journey scenario and provide a more flexible efficient network.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #42
[quote author="Folknology"]Sorry Nick, quick correction so we don't get mixed up on the layers :

[quote author="nickjohnson"]
CANopen is still a candidate for layer 2 - but 'raw' CANopen doesn't provide a particularly straightforward abstraction, and I think that will be critical for adoption.[/quote]

CANOpen is a layer3-7, CANBus itself is Layer 1+2[/quote]

I blame early morning posting, sorry - though I don't think CANOpen can be reasonably described as providing layers 5 through 7.

Quote
[quote author="nickjohnson"]I'm still not sure I agree with this. There's nothing fundamental about any of those abstractions that requires long messages, and CAN itself doesn't specify anything above sending a packet with a single address field and up to 8 bytes of data. I think you could implement any of those abstractions on top of it with relatively little overhead - but this is something that will need exploring.

BTW way there are some basic network design rules about balancing the size of data to frames and we clearly seem to be breaking them with these 'familiar' types of expectations, datagrams are designed with variable length payloads for very good reason[/quote]

0-8 bytes is variable length. There's nothing about those abstractions that says they have to be used with large amounts of data.

Re: uCAN: A protocol stack for microcontroller networking

Reply #43
[quote author="nickjohnson"][quote author="Folknology"]Sorry Nick, quick correction so we don't get mixed up on the layers :

[quote author="nickjohnson"]
CANopen is still a candidate for layer 2 - but 'raw' CANopen doesn't provide a particularly straightforward abstraction, and I think that will be critical for adoption.[/quote]

CANOpen is a layer3-7, CANBus itself is Layer 1+2[/quote]

I blame early morning posting, sorry - though I don't think CANOpen can be reasonably described as providing layers 5 through 7.

Quote
[quote author="nickjohnson"]I'm still not sure I agree with this. There's nothing fundamental about any of those abstractions that requires long messages, and CAN itself doesn't specify anything above sending a packet with a single address field and up to 8 bytes of data. I think you could implement any of those abstractions on top of it with relatively little overhead - but this is something that will need exploring.

BTW way there are some basic network design rules about balancing the size of data to frames and we clearly seem to be breaking them with these 'familiar' types of expectations, datagrams are designed with variable length payloads for very good reason[/quote]

0-8 bytes is variable length. There's nothing about those abstractions that says they have to be used with large amounts of data.[/quote]


Agreed about the upper layers for CANOpen, I have now increased my caffeine intake in order to correct this mistake ;-)

As for the '0-8 Bytes is variable length' I agree it is, except in this case our desired familiar abstraction payloads do not fit the narrow layer II design of CANBus and its restrictions, hence my analogy above.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #44
To perhaps place the analogy more squarely back into networking consider this:

Ethernet has very generous frames which accommodate many classes of vehicles, it was purposely designed thus for modern networking requirements. This could be considered along with UDP/TCP/IP as being the 4 lane motorway (Freeway for our US folks)

CANBus however locks its layer 1 and 2 together in order to achieve a very efficient but rather narrow design abstraction of realtime messaging and control. In doing so it effectively creates the equivalent of a single track restricted entirely to motorcycles.

RS485/422 just provides layer 1 you can add whatever you wish above this layer designed to meet your modern familiar requirements. Although you are unlikely to create a Motorway you could create a single track capable of carrying motorcycles, cars or trucks (half duplex) or even a trunk road (full duplex).

All I am suggesting is that the latter may better represent the requirements than the former and as such should be suitably considered against the requirements..

regards
Al