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

uCAN: A protocol stack for microcontroller networking

I'm working on an idea that I've been pondering over for a while: a simple, low cost option for networking low power microcontrollers for hobbyist projects, art installations, interactive exhibits, hackspaces, etc etc. There are a few options around, but nobody's specified something to build an ecosystem around; radio is widely varied and problematic in many installations, and Ethernet is too expensive and high-overhead for small embedded projects.

Rather than reinvent the wheel, the plan is to use existing standards to specify a stack - physical, electrical, protocol and API - that multiple makers can produce compatible products for. Goals are:

 - Low cost and low overhead
 - Reuse existing standards and implementations as much as possible
 - Reuse existing cabling and infrastructure as much as possible
 - Support varied devices (architecture, capabilities etc)
 - Support cable lengths from a couple of meters up to entire building installations
 - Easy to use for people with limited electronics and wiring experience - plug, program, and play.

With that in mind, the current protocol stack looks like this:

 - UTP cables with RJ45 connectors, allowing reuse of standard Ethernet cables and wiring installations
 - Power carried over a spare pair at 9-24V DC
 - CAN bus physical and transport level protocol
 - CANopen application level protocol
 - Standardized, simplified APIs for carrying out common messaging and automation tasks (still to be defined)

I'd really like this to become a community project, with multiple people directing the evolution and standardization of the stack, and designing boards around it.

Tentatively planned initial implementations include:

 - A Raspberry Pi expansion board
 - An Arduino shield
 - A power injector (DC barrel jack -> RJ45)
 - An Arduino clone with onboard uCAN
 - A development board based on the LPC11C24 (built in CAN transceiver, so cheap and simple)
 - A CAN bus hub

I'd love to hear feedback and opinions on the project, especially if you're interested in pitching in to the standardization and design effort yourself.

RPi expansion

Reply #1
Here's one of the first PCBs: a Raspberry Pi expansion board.





The board uses the MCP2515 CAN interface and MCP2551 transceiver. There's a linux kernel module for the 2515, so support is fairly straightforward, and it can be brought up as a network interface.

The board also includes a 5V 1A switching converter, which powers the RPi from the CAN bus.

Arduino shield

Reply #2
Another of the initial designs: An Arduino uCAN shield.





As with the RPi shield, the MCP2515 and MCP2551 are used, along with a 5V 1A switching regulator to supply the Arduino and any attached shields with power.

This board should function at 5v and 3.3v (autoselected where an IOREF pin is available), on a Duemilanove, Uno, Uno R3, Due and Leonardo, and clones.

Re: uCAN: A protocol stack for microcontroller networking

Reply #3
I think it´s perfect! I´m going to develop something similar in ST ARM ucontrollers to connect several greenhouses and use LIN to connect to sensors and I´d think that nobody´s it´s interested in do something like this. I can collaborate in this great idea if you like!

Thanks

Re: uCAN: A protocol stack for microcontroller networking

Reply #4
The Ohio State University Formula Car Team used MCP2551 CAN transceivers all last year, and we've had a lot problems with them.  I know you're probably not going to use these in an automotive setting like we did, but we found they are extremely sensitive to small transients.  We probably went through 20 chips last year, spent many hours on the phone with Microchip, and reached the conclusion that they are just very sensitive ICs.  Microchip, however said that they were coming out with a new IC mid-2013 to replace the MCP2551, the MCP2561/2.  I HIGHLY recommend you get yourself a MCP2562 instead of the MCP2551, because a good chunk of my life for the past year has been wasted due to grief from the sensitive MCP2551.

Re: uCAN: A protocol stack for microcontroller networking

Reply #5
[quote author="Destate9"]The Ohio State University Formula Car Team used MCP2551 CAN transceivers all last year, and we've had a lot problems with them.  I know you're probably not going to use these in an automotive setting like we did, but we found they are extremely sensitive to small transients.  We probably went through 20 chips last year, spent many hours on the phone with Microchip, and reached the conclusion that they are just very sensitive ICs.  Microchip, however said that they were coming out with a new IC mid-2013 to replace the MCP2551, the MCP2561/2.  I HIGHLY recommend you get yourself a MCP2562 instead of the MCP2551, because a good chunk of my life for the past year has been wasted due to grief from the sensitive MCP2551.[/quote]

Excellent point, and thanks for the feedback! Someone at Microchip already pointed this out, and I've modified the designs to use the MCP2562 - which even has a level shifter built in, so let me ditch the resistor divider.

Re: uCAN: A protocol stack for microcontroller networking

Reply #6
I heard about Microchip CAN problems but nobody told exactly ""when"" until now. I use TJA1051T and SN65HVD233 without problems. Most of transceivers that I see have the same pinout or are very close to NXP parts.

Re: uCAN: A protocol stack for microcontroller networking

Reply #7
I have used the MCP2551 in various automotive test tools since it was released about 10 years ago. So far only one circuit out of 200 has been replaced, which is acceptable as most of the cars the units are used in are early prototypes. However, there is one big difference between my schematics and the one posted for this shield and that is the filtering section.

Low capacitance transient suppressors were not available back in 2004 so I used anti-parallelled diodes, BAV199, in series with varistors (11 Vrms SIOV in 0603 package). One diode+varistor combination each on CANL and CANH to GND. The SIOVs seems to be discontinued now but they can be replaced with some low capacitance TVS.

Between the over voltage filter and the MCP2551 a common mode choke and Y-capacitors (22pF, >= 100 V, C0G/NP0) are fitted. One cap one each side of the choke and down to GND, configured just like a standard line filter for 115V or 230 V mains. The choke is made for CAN bus filtering and must be able to handle some current, 200-300 mA or so. Try not to use vias between the connectors and the CAN tranceiver. If you must, then use at least two to handle the current.

Bus termination was often done with a 120 ohms resistor between CANL and CANH, just as in the posted schematics. In many newer designs you will find two resistors in series with a capacitor decoupling from the midpoint down to GND. Sometimes you can not use 120 ohms when the unit is placed on a stub and not on the end. 2x1k in 1206 packages and 4.7 nF was on a board I checked some time ago. The higher resistance will not affect the main termination resistance much but still give some effect. The capacitor will drain high frequency noise.

Edit: I tried to add a few links to app notes about filtering but that failed as I am a new user. Google "can bus common mode filter" (TI slla271.pdf and Microchip en528477.pdf) and "can bus common mode filter nxp" (AH1014, section 8 about EMC)

Re: uCAN: A protocol stack for microcontroller networking

Reply #8
Yes, I not check the diagrams because I only interested in the software because I have the hardware developed. I use a similar circuit that you describe but instead of antiparallel diodes I use PESD1CAN and no choke, maybe would be good that I add it in next board!. THANKS

Re: uCAN: A protocol stack for microcontroller networking

Reply #9
My 2c:

* What baud rate will be used, and does CANopen allow for automatic baud rate identification?
I'm familiar with CAN, but not CANopen. In the past, with other application layers, I have found that the fact that CAN frames are limited to 8 bytes of data means that your net throughput will be very low, even at 500kb/s. It all depends on what type of data you want to send, but worth bearing in mind.

* Termination is critical. I'm guessing from your schematic that you intend for the user to add a jumper to the two nodes on the end of the 'bus', and remove the jumpers on all the nodes that are on 'stubs'? My experience was with J1939, not CANopen. In J1939, there are several possible physical layers, but they all trade-off baud-rate, bus length, stub length, and maximum number of nodes.

* I've never heard of "sensitive" CAN transceivers. Quite the opposite. A well-designed CAN physical layer should be practically bullet-proof.

* Have you looked at SocketCAN?

In summary, for applications requiring a rock-solid but slow network with a little manual intervention required, I think CAN is a great choice.

Re: uCAN: A protocol stack for microcontroller networking

Reply #10
The PESD1CAN is probably a good choice as a replacement for the antiparallel diodes in series with varistors. Common mode chokes are found in a majority of the ECUs in cars. In small volumes, their price might scare of many hobbyists but for robust applications they are a must. You can also add a buffering cap with a couple of uFs close to the transceiver in the next revision of the board.

Other important things are:
- A stable crystal oscillator to get the bit timing correct
- Proper setup in the CAN controller of the different bit timing parts

Re: uCAN: A protocol stack for microcontroller networking

Reply #11
Niklas, yes I have no problem because I use out of an automotive environment, in a relative noissless space, but I follow your recommendation for a better PCB. Thanks!

Re: uCAN: A protocol stack for microcontroller networking

Reply #12
Some screenshots from a prototype ECM as a reference. The transceiver is not the MCP2551 but a 3V pin compatible part from TI. The termination resistors were changed to 1k instead of 60 ohms.

Re: uCAN: A protocol stack for microcontroller networking

Reply #13
Thanks for all the feedback! I've changed the termination to split termination enabled or disabled with an SMT switch, and thickened up the power traces on both boards. I'll look into using a TVS as well - improving robustness never hurts.

Re: uCAN: A protocol stack for microcontroller networking

Reply #14
[quote author="banjaxed"]My 2c:

* What baud rate will be used, and does CANopen allow for automatic baud rate identification?
I'm familiar with CAN, but not CANopen. In the past, with other application layers, I have found that the fact that CAN frames are limited to 8 bytes of data means that your net throughput will be very low, even at 500kb/s. It all depends on what type of data you want to send, but worth bearing in mind.[/quote]

This is a good point. CAN is indeed limited to 8 bytes. I'm not that familiar with CANOpen yet; it simply seemed like a reasonable higher-level protocol choice, as I'm not keen to reinvent the wheel. I do know that it doesn't specify lower level details, so no autobaud - a default baud rate will need to be specified as part of the stack.

Quote
* Termination is critical. I'm guessing from your schematic that you intend for the user to add a jumper to the two nodes on the end of the 'bus', and remove the jumpers on all the nodes that are on 'stubs'? My experience was with J1939, not CANopen. In J1939, there are several possible physical layers, but they all trade-off baud-rate, bus length, stub length, and maximum number of nodes.

That's the plan, yes. I've just switched to split termination with a switch, but people will still have to daisy chain and set termination where appropriate.

Quote
* Have you looked at SocketCAN?

In summary, for applications requiring a rock-solid but slow network with a little manual intervention required, I think CAN is a great choice.

I have, and that's the plan for the RPi shield.