Using Can Bus

In my research, I found that the Teensy 4.0 has 3 CAN buses integrated. That's the best deal I can find given that it's only $20 US. Most other solutions I've seen are more for the board that can understand CAN info and the board that can transmit it.

I see there is a CAN bus breakout board for the Teensy 4  - http://skpang.co.uk/catalog/teensy-40-triple-can-board-with-teensy-40-and-28-lcd-p-1576.html - Its a bit expensive so I await a hoped for DroneBot article on the CAN bus before committing my funds.

I was personally struggling a lot to find some info about the CAN Bus... I was especially searching for some videos as I prefer to watch it instead of read it, but at least I find one article that pretty much gave me most of the info I was looking for. This is the link: https://www.autopi.io/blog/can-bus-explained/

@gallesio  Are you stuck on using CAN?  Modbus or TCP/IP might have more docs, samples, & users to lean on.

Hi all,

A few random comments. I did a short experimental trial of CAN when it was the 'new kid on the block' .. circa 25 years ago! I confess I haven't done any bench work on it since then, but it continues to be a very useful and ubiquitous tool around the world.

For a circuit board designer, many microcontrollers provide CAN concontrollers as part of the package, with each controller only requiring two pins for duplex traffic. Note, generally the microcontrollers do not include the bus driver chips ... these are typically 8-pin devices available from TI and others,that connect directly to the pair of pins on the microcontroller.

From memory, it was fairly easy to get working. To get started a pair of wires about a metre long with a terminator resistor at each end, and a node near  each of the ends of the wires,  was the mark 1 test bed. I think it took about a couple of hours to 'get it working' from first power up attempt.

You may need an oscilloscope if it doesn't play nicely first time, since a single transmission requires at least one receiving node to acknowledge a good packet, and until you get that right, it goes into auto retransmits etc. which are difficult to untangle blindly .. sorting this took the 2 or so hours!

There are a number of sub-bit timing parameters which look a bit scary. From memory, I think we found some published 'get started' defaults, which should be fine on a short test bed network with 'text book' waveforms. Most of the tweaks are about maximising the reliability when the network is larger and the waveforms are distorted with reflections, etc.

The max speed of CAN (excepting CAN FD which I would leave implementing until later .. CAN FD is basically a go faster stripes add on. You should be OK with a CAN FD node used in non-FD mode) is 1Mbits/sec, and can be much slower, so a modest speed scope should be ok. More importantly, you need to be able to look along the whole packet, as the acknowledge bit is one of the last ones! Later on, you may wish to look at the data bits as well.

However, once you get it right, it is a very robust and reliable system. 

CAN bus is NOT compatible with I2C, SPI or any other bus I have come across. Of course I2C and SPI are usually 'inside a box' wire lengths.

CAN is intended for between boxes ... in fact strictly there is a minimum distance between nodes, but I think it is often possible to 'bend' this recommendation, at your own risk of course.

Within reason, (based on bus loading, etc,) you can hang as many nodes as you wish on the same pair of wires - you do not need router boxes, etc.

Each controller can initiate sending out a packet of data - it just waits for a quiet moment on the bus - and there is a clever mechanism which arbitrates if two nodes set off at the same time, with the one with the higher priority address able to continue uninterrupted.

Each packet is sent with an address, which is not like an IP address. Instead it is more of a label to indicate the nature of the data. All nodes on the bus can read the packet, but typically the system designer will allocate the addresses so each node can have a filter so it only receives the packets of interest. This filtering is part of the CAN controller subsystem within the microcontroller, so it doesn't require any software intervention beyond setting up the filters as part of power up (or whenever).

The basic CAN standards are simply definitions of bits for address, status and data. They do not define the 'meanings' or interpretations beyond that needed for the physical comms to work. Hence many industries have published protocols, and you may come across these with their respective names.

As I mentioned before, to a board designer, adding CAN comms to an embedded product design can be very cheap and easy ... oversimplifying it is:

1. pick a version of your preferred microcontroller family with 1 or more CAN controllers, as required
2. add on a pretty cheap 8-pin bus driver chip for each CAN bus (about £1 each in quantity?)
3. route the connections out to a socket
4. .. job done! ... unless you also have to write the software!

Sorry, I don't know how that translates to folks looking to buy pre-built boards. If the microcontroller board you are looking at includes CAN controller, and the Tx/Rx pins are available and accessible, then adding the 8 pin bus driver chip shouldn't be difficult. Note there are a number of bus driver chip variants, so it is worth comparing them and picking the most convenient for your situation.

So if you have a project that needs a simple wired network, whose length is metres to tens of metres (at least - further at reduced speed), to allow microcontrollers to chat to each other, then CAN bus is worth a look.

In the 'early days', there were also 'slave' chips that combined the bus driver with a simple controller function, which were intended to interface something simple like a sensor switch or light. I suspect these were quietly forgotten, but they may still be supported. I haven't seen them for a long time (or ever used them) but I haven't had a need to look for them. There may be microcontrollers with CAN bus driver built in, but again I haven't looked.

I hope this is useful.

(If it looks interesting, please check I haven't made any errors before committing yourself ... as I said it was a long time ago...)

Hi @dankramer and @byron,

As a post comment to my diatribe above, I had a quick glance at Teensy 4.0/4.1

The  PJRC website for Teesy 4.1  says: CAN   3 ports for CAN bus allow connecting to automotive & industrial control systems which use CAN communication. A CAN transceiver chip must be added to complete the electrical interface between Teensy 4.1 and the CAN bus.

Unhelpfully, it doesn't seem to show which pins, but this is the usual hazard of each pin having umpteen different possible functions. I presume they are included in breakout around the board.

So far as I can see, the Teensy processor is 3.3V, whilst CAN is 5V. Hence, need to choose bus driver chip that can oblige.

Whilst it will clearly require some soldering, and possibly a PCB, it maybe financially advantageous. It needs a bus driver chip for each CAN bus port. As a possible candidate for consideration, the picture below was taken from the Microchip website.

According to the Microchip website, they are priced at about 3 for $1 in small quantities, but you might have to wait a while ....

This chip claims to be FD ready, which would give the possibility of using that facility.

I vaguely remember finding at least one device that provided electrical isolation .. maybe from TI? .. which might be worth thinking about if the network is lengthy. (May not support FD?)

Hope this is food for thought.

Posted by: @davee

Hope this is food for thought.

It is good information on the CAN bus you give and I see from my posts resurrected from a year and a half back that I had bought a couple of CAN bus boards, I wonder where I put them 🤔 

I got them to understand the CAN bus and have a play as I was thinking using the CAN bus might be a better inter microprocessor communication method than i2c for boards that were not in close proximity.  I vaguely remember @dronebot-workshop having problems with using i2c with i2c booster boards on the DB1 robot that was started many moons ago and thought the CAN bus might be a better bet.  

Both DB1 and my bot have been languishing in the projects to get back to sometime (well I speak for my bot anyway) and I hope to get going again sometime after the summer.  In the meanwhile I do some sporadic planning when I find some spare time.  My current design thoughts for my bot does include multiple microprocessor boards, but they will be in close proximity so probably I will not be doing much relating to the CAN bus. (I also envision bot to 'telemetry station' comms via wifi).

However sometime after actually getting a working autonomous bot properly up and running I will find those CAN bus boards and have a play so I have read your post with interest. 👍   

@gallesio You might enjoy this file.

Excellent details and observations.

Link should be open access

https://www.mdpi.com/1424-8220/20/8/2364