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

Re: uCAN: A protocol stack for microcontroller networking

Reply #135
Also, the first PCBs came in a few days ago. I've put together an Arduino shield and a power injector so far:





Powering the board works fine, but I haven't had a chance yet to test communications, since I'm missing a header I need for both Arduino and RPi boards.

I'm going to be putting together a few of these and sending out sets - power injector, Arduino shield, and either RPi or Beaglebone board, to interested people in the next week or so. Please post here if you're keen, along with what you'd like to do with it.

Bear in mind that this is still very early - we haven't even started to define a concrete software stack or APIs yet - so this is strictly hackers-only. Priority will be given to anyone who expresses interest in working on the software stack (in the open, of course)!

Re: uCAN: A protocol stack for microcontroller networking

Reply #136
I've also just finished reviewing all the CAN-based protocols I could find, and the results are a bit depressing. CANOpen isn't - you have to fill out a copyright agreement to even see the specs. None of the alternatives are any better, except VSCP, which is at least an open specification - but as previously detailed, is really pretty complicated.

I'm thinking that designing our own may still be the best option. One decision that will have to be made as a result is how far up the OSI stack we want to go: do we define purely up to the transport layer, and let applications define the rest themselves? Or do we take the approach most other CAN based protocols have, and attempt to define everything?

Re: uCAN: A protocol stack for microcontroller networking

Reply #137
[quote author="nickjohnson"]I'm thinking that designing our own may still be the best option. One decision that will have to be made as a result is how far up the OSI stack we want to go: do we define purely up to the transport layer, and let applications define the rest themselves? Or do we take the approach most other CAN based protocols have, and attempt to define everything?[/quote]
Well, if the existing alternatives are big and complicated, and they're no good, then it seems like a good first step that a new one should be as small and simple as possible, right?  Also, "hobbyist projects, art installations, interactive exhibits, hackspaces, etc" doesn't sound like things that are going to be compatible with big standards documents or much protocol overhead.

Throwing out some ideas: I guess one would at least want to agree on some broad priority levels if different hardware is to work together (say, time critical, important, not important, bulk).  A few reserved IDs in each class, maybe a small multicast range for routed networks ("fire alarm", "shutdown", or "all lights off").  Perhaps some way to extend the adressing space ("id 0xfoo means that the sub-id is in the first data byte") if you have many nodes of the same type, and one might want a standard way to send and reassemble long data packets...

It can't be something that requires a lot of code though, anything fancy has to be optional IMHO.

Re: uCAN: A protocol stack for microcontroller networking

Reply #138
Some thoughts on the whole power thing.

Assumptions: For the places this is likely to be going (homes, hackerspaces, events, etc), I'm assuming that there's a good chance there will be some Ethernet cabling already in place, and equipment using it.  I'm also assuming there's unlikely there will be any CAN-on-Cat5 equipment. (based only on how I've never heard of it before this thread, but YMMV...)

Given those assumptions, it seems that there would be some benefit to sticking to the standard CAN on RJ45 pinout, but not necessarily a huge one.  It also seems that being able to run alongside regular Ethernet (although at 100Mbit only) could potentially be useful, and that being able to at least coexist with Power over Ethernet would be important.


With the proposed / standard pinout, bad stuff might happen if, for example, there is a misunderstanding and someone plugs in a regular consumer PoE adapter, since it would short out the uCAN power lines.  I think accidentally plugging in the powered uCAN cable instead of the network cable into ones laptop (and this will happen) might also have some expensive side effects.

So, for interoperability, I suggest either doing what PoE mode A is doing and transporting data over the same pairs as power (cool!), or doing what PoE mode B is doing and using the same spare pairs in the same way (boring, and limits using existing cabling - but would allow using regular consumer PoE equipment), or dropping the power bit entirely.


I've been arguing for the first option, I'm hoping that we could duplicate what is done with Ethernet and don't really see the need for physical compatibility with other Hi-speed CAN networks, but I'm not sure how this would work on a bus with many nodes.

Not sure how power would work on a bus with many nodes either, for that matter.  Is it going to be used beyond just point-to-point connections, like most PoE things seem to be?

Re: uCAN: A protocol stack for microcontroller networking

Reply #139
[quote author="magetoo"]Some thoughts on the whole power thing.

Assumptions: For the places this is likely to be going (homes, hackerspaces, events, etc), I'm assuming that there's a good chance there will be some Ethernet cabling already in place, and equipment using it.  I'm also assuming there's unlikely there will be any CAN-on-Cat5 equipment. (based only on how I've never heard of it before this thread, but YMMV...)

Given those assumptions, it seems that there would be some benefit to sticking to the standard CAN on RJ45 pinout, but not necessarily a huge one.  It also seems that being able to run alongside regular Ethernet (although at 100Mbit only) could potentially be useful, and that being able to at least coexist with Power over Ethernet would be important.


With the proposed / standard pinout, bad stuff might happen if, for example, there is a misunderstanding and someone plugs in a regular consumer PoE adapter, since it would short out the uCAN power lines.  I think accidentally plugging in the powered uCAN cable instead of the network cable into ones laptop (and this will happen) might also have some expensive side effects.

So, for interoperability, I suggest either doing what PoE mode A is doing and transporting data over the same pairs as power (cool!), or doing what PoE mode B is doing and using the same spare pairs in the same way (boring, and limits using existing cabling - but would allow using regular consumer PoE equipment), or dropping the power bit entirely.[/quote]

Well argued. Annoying to have to break my existing prototypes, but probably justified. I don't think dropping power full stop is an option, though, so I'll look into PoE mode B, and ways to avoid Ethernet conflicts.

Quote
I've been arguing for the first option, I'm hoping that we could duplicate what is done with Ethernet and don't really see the need for physical compatibility with other Hi-speed CAN networks, but I'm not sure how this would work on a bus with many nodes.

I'm still open to this - I just don't see how you can carry power on CAN pairs.

Quote
Not sure how power would work on a bus with many nodes either, for that matter.  Is it going to be used beyond just point-to-point connections, like most PoE things seem to be?

For multiple low-current devices, 0.5A - 1A @ 24V ought to be sufficient. For higher powered stuff, there's the CAN HUB.

Re: uCAN: A protocol stack for microcontroller networking

Reply #140
Okay, so switching to a PoE-compatible pinout it is. Here's what I'm proposing:

Pin 1: CAN_H (unchanged)
Pin 2: CAN_L (unchanged)
Pin 3: Unused (was GND)
Pins 4&5: DC+
Pin 6: Unused (unchanged)
Pins 7&8: DC- (was DC+ and DC-)

I'm undecided if I should throw out my already-manufactured PCBs and get a new set, or continue using the old pinout for now, and only switch over when making a second round of prototypes or a production run.

Regarding the protocol, for simplicity I'm thinking that sticking with the OSI model works best. Here's a brief thought:

Using 29 bit extended IDs only, the ID field is broken up into subfields:

High priority: 1 bit
Protocol ID: 4 bits
Sender node ID: 8 bits
Protocol-specific: 16 bits

The high priority bit is set only on urgent messages, and overrides the normal protocol based priority scheme. Protocol IDs specify the format of the message and of the 16 bit protocol-specific part of the CAN address. A sender node ID is 8 bits, with 255 being reserved for 'no ID'.

Suggested sub-protocols:

Protocol 0: DHCP/ICMP(-esque): Allows assignment of a node ID using a similar scheme to VSCP, with either a centralised allocator managing IDs, or discovery probing. Also handles basic network management issues like ping/pong. This is the only mandatory protocol.

UDP(-esque): 8-byte datagrams. The protocol specific field is divided up into recipient ID (255=broadcast) and port number

Register access: Read and write an array of registers on a host. The protocol specific field is divided up into recipient ID and command fields. A standard set of registers are defined for things such as manufacturer and device info, with the remainder being user-defined.

Event broadcast: For sending event based information to all recipients. Protocol specific field denotes event class, which defines data format, and event type.

Re: uCAN: A protocol stack for microcontroller networking

Reply #141
I´m reading VCSP now, but I have a lot of work at this days. We are going to analyse the option of use VCSP as is?

Re: uCAN: A protocol stack for microcontroller networking

Reply #142
[quote author="Tarloth"]I´m reading VCSP now, but I have a lot of work at this days. We are going to analyse the option of use VCSP as is?[/quote]

I read through it and concluded it was too complicated: the minimum requirement set is too large, and the event protocol is poorly organised, with little provision for a simple API with message reuse.

I'm open to second opinions, though!

Re: uCAN: A protocol stack for microcontroller networking

Reply #143
[quote author="magetoo"]
.....Perhaps some way to extend the adressing space ("id 0xfoo means that the sub-id is in the first data byte") if you have many nodes of the same type, and one might want a standard way to send and reassemble long data packets...[/quote]

Don't forget the DLC field is 4bits (0-15) and the frame payload has a max byte width of only 8, that could leave room to indicate extra frames coming. For example the second range beyond 8 could indicate number of full (8 byte) frames to follow

However we should be careful about encouraging too much data on the network, such frames would need to be transmitted at a low priority

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #144
[quote author="nickjohnson"]
Using 29 bit extended IDs only, the ID field is broken up into subfields:

High priority: 1 bit
Protocol ID: 4 bits
Sender node ID: 8 bits
Protocol-specific: 16 bits

The high priority bit is set only on urgent messages, and overrides the normal protocol based priority scheme. Protocol IDs specify the format of the message and of the 16 bit protocol-specific part of the CAN address. A sender node ID is 8 bits, with 255 being reserved for 'no ID'.
[/quote]

CANBus uses a 'Hard' prioritisation arbitration scheme involving the first 11bits so those will always control priority, I don't think those can be changed? You can however mess with the extended 18bits AFAIK.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #145
[quote author="Folknology"][quote author="magetoo"]
.....Perhaps some way to extend the adressing space ("id 0xfoo means that the sub-id is in the first data byte") if you have many nodes of the same type, and one might want a standard way to send and reassemble long data packets...[/quote]

Don't forget the DLC field is 4bits (0-15) and the frame payload has a max byte width of only 8, that could leave room to indicate extra frames coming. For example the second range beyond 8 could indicate number of full (8 byte) frames to follow

However we should be careful about encouraging too much data on the network, such frames would need to be transmitted at a low priority[/quote]

I just checked, and MCP2515 permits sending DLCs >8; it's unclear, however, if it will faithfully report received codes >8 or not. Using the field like this may not be a good idea.

Quote
CANBus uses a 'Hard' prioritisation arbitration scheme involving the first 11bits so those will always control priority, I don't think those can be changed?

Extended frames use a 29 bit ID, all of which can be used for arbitration. What I was proposing above is one way to subdivide this field for the protocol. On further discussion, though, I think putting the protocol specific part of the ID earlier makes more sense:

Priority:1
Protocol:4
Protodata:16
Sender:8

Re: uCAN: A protocol stack for microcontroller networking

Reply #146
The 29 bits don't come in a continuous stream they have SRR+IDE bits in between the 11 and 18 bits.

Re: uCAN: A protocol stack for microcontroller networking

Reply #147
[quote author="Folknology"]The 29 bits don't come in a continuous stream they have SRR+IDE bits in between the 11 and 18 bits.[/quote]

They do, but this doesn't matter - if the only CAN messages on the bus have extended IDs, those bits will always be recessive, and so will never affect arbitration.

 

Re: uCAN: A protocol stack for microcontroller networking

Reply #148
Quote
I read through it and concluded it was too complicated: the minimum requirement set is too large, and the event protocol is poorly organised, with little provision for a simple API with message reuse.

I'm open to second opinions, though!

Actually I respect  the work of others and think that in general they took some decision in base to constraints. I´m not read the entire protocol and see that it´s not wide extending but I haven´t any reason to think that we can do something better working from the scratch if we not discuss first EXACTLY what are the use and boundary of our sub-protocol.

You propose a series of datagrams species, but what is the scenario? Which are the limits to our design? Which is the general philosophy? What are the physical problems that we need to solve in practice? Connectors, wiring and pin out is only a small part of real word problematic.

To this point, reading the previous post I think that we are plan to working in a multi-master, long wire (more than 20 meters), event based protocol that must minimize the controller software footprint (please, correct me if this is not accurate).

In resume, the same that I ask from the beginning, exactly what kind of data we are moving in this protocol and which are their clear limits? It´s impossible to plan a protocol that works in every scenario with every data type and serves all the purposes. I think that I share in thick line the objectives with folknology, but what about the others?

Re: uCAN: A protocol stack for microcontroller networking

Reply #149
[quote author="nickjohnson"]
They do, but this doesn't matter - if the only CAN messages on the bus have extended IDs, those bits will always be recessive, and so will never affect arbitration.[/quote]
Does all of this mean no RTRs?