Ah, the CAN bus. It’s become a communication standard in the automotive world, found in a huge swathe of cars built from the mid-1990s onwards. You’ll also find it in aircraft, ships, and the vast majority of modern tractors and associated farm machines, too.
As far as [Randy Glenn] is concerned, though, the CAN bus doesn’t have to be limited to these contexts. It can be useful far beyond its traditional applications with just about any hardware platform you care to use! He came down to tell us all about it at the 2024 Hackaday Supercon.
[Randy]’s talk was titled “Yes, You CAN: Use The Controller Area Network Outside Of Cars.” We have to assume the pun was intended. In any case, the CAN bus came to us from Bosch, which began developing the standard in 1983. The company officially released it at the Society of Automotive Engineers conference in 1986, with compatible chips first hitting the market a year later. It took a little while longer for the standard to find traction, with Mercedes-Benz being the first to implement it in a production vehicle in 1991. It soon caught on with the wider industry as a robust and reliable way to let a vehicle’s various control units communicate with all the important sensors that were proliferating on modern automobiles. CAN got its big break when it was mandated as part of the OBD-II standard in North America, which defacto put it into virtually every car sold in that market from 1996 onwards.
Since then, CAN has proliferated well beyond the automotive space, into marine and aerospace contexts as well. As [Randy] explains, beyond transportation, you’ll also find it in everything from robots to pinball machines and even elevators. Basically, wherever it’s important to have robust local communication between distributed embedded systems, CAN is a great candidate for the job.
Since it’s so widespread, it’s easy to find hardware and software that’s CAN-ready out of the box. The vast majority of microcontroller manufacturers include some sort of CAN compatibility; for example, Espressif’s ESP32 has the “Two Wire Automotive Interface” which is built for this purpose. Linux is more than happy to talk CAN, too, and most programming languages have some sort of library available, too. Whether you’re working with Arduino, MicroPython, or CircuitPython, you can certainly find what you need. Even if you have a device without CAN built in—like a Raspberry Pi—SPI-ready CAN controllers can be had for cheap from vendors like Microchip.
There are specific reasons why you might consider CAN for your embedded communication needs. It uses a differential bus, which gives it an inherent ability to resist disruption from electrical noise. Addressing, error-checking, and retransmission functionality are also baked in to CAN controllers, so you don’t have to handle it yourself. You can also find tons of CAN compatible hardware on the market to do whatever you’re trying to do, and a lot of it is pretty cheap because manufacturers are churning it out by the millions.
Of course, there are some limits. Traditionally, you’re stuck with only 32 devices on a bus, though there are some ways to work around it at lower data rates. Peak data rate is 1 megabit per second on a traditional CAN bus operating at the high data rate; this limits you to a total bus length of 25 meters. You can up this to 250 meters if you drop to 250 kbit/s instead. Packets are also limited to 8 bytes in size.
Beyond the basic performance specs, [Randy] also explains how you might go about typical implementations with different hardware. For example, if you’ve got a microcontroller with no CAN capability baked in, you might hook it up with a CAN controller and transceiver over SPI. Alternatively, you might choose to work with a more advanced microcontroller that has all the CAN communication hardware built into the chip, simplifying your build. For parts like the ESP32 and some STM32s, you might find you’ve got a CAN controller on board, but you’re lacking the hardware to do the fancy differential signalling—in that case, you just need to hook up a CAN transceiver to get your hardware on the bus. [Randy] also highlights the usual conventions, such as terminology and wire colors, while explaining that these aren’t always rigidly adhered to in the field.
On the communication level, the CAN bus standard mandates that nodes transmit frames, with each each frame containing up to 8 bytes of data. [Randy] explains how messages are formatted and addressed to ensure the right nodes get the right data they’re looking for. There are standard message frames, as well as Remote Transmission Request (RTR) frames—where one node requests data from another. A typical example is a controller asking a sensor to report a value. There are also special Error and Control Frames, which [Randy] notes are complicated and beyond the scope of his Supercon talk. However, he recommends resources that exist to explain them in great detail.
Much of [Randy’s] talk explains how CAN works. But, as promised, he also takes the time to explain possible non-automotive applications for this technology. He steps through an amusing Halloween build, where a CAN bus is used to trigger scary lightning and sound effects when people press a doorbell.
If you’ve ever wanted a good CAN primer, [Randy]’s talk is just what you need. As far as robust embedded communication standards go, it’s one of the most popular and long-lived out there. It might just pay dividends to put the CAN bus in your own toolbox for future use!
FWIW there are also level-shifting CAN transceivers, if you need to have the CAN bus a different voltage than some of the nodes, which is very convenient. Some CAN transceivers can use arbitrary voltages on both sides if you provide reference voltages.
The Duet line of 3D printer controller boards can use CAN to talk between the main board and tool boards.
It’s pretty well designed and supported.
https://docs.duet3d.com/User_manual/Machine_configuration/CAN_connection
A Hackerspace I visited in 2005 had two 125 kBit/s 24V CAN buses (one for high priority traffic, the other for best effort) going through the whole building, with multiple re-purposed RJ45 plugs in every room. They had a lot of home automation attached and you could plug in your own devices.
Using repurposed RJ45 plugs as connectors for the CAN buses is also an inventive approach, given that RJ45 is more commonly associated with Ethernet networking. This choice might have been driven by the availability and cost-effectiveness of RJ45 connectors and infrastructure, as well as the ease of adapting them for CAN bus use.
The fact that visitors could plug in their own devices suggests that the hackerspace was encouraging experimentation and collaboration among its members. This open approach to networking and device integration could have facilitated a wide range of projects and innovations, from simple automation tasks to more complex IoT (Internet of Things) applications.
What? Is that a bot comment or did you use to much chatGPT? XD
Or maybe people are starting to write like they learned from ChatGPT!
Pasted Johannes’ comment into Claude, here’s a very similar reply:
“That sounds like quite an innovative setup for 2005! Using CAN buses for home automation was definitely ahead of its time. The Controller Area Network (CAN) protocol is robust and reliable, which makes it perfect for a hackerspace environment where multiple devices need to communicate.
Having dual buses – one for high priority traffic and another for best effort – was a smart design choice. This would ensure critical systems remained responsive even when the network was busy with less important traffic.
Repurposing RJ45 connectors was also practical, since they’re readily available, inexpensive, and have enough conductors for CAN plus power. The 24V power delivery alongside the data lines would have made it convenient to power small devices directly from the network.
Were you able to connect any of your own devices to this system? I’m curious what kinds of automation they had implemented throughout the building.”
If you don’t need the fancy networking, I’ve used CAN transceivers to move UART signals around. For whatever reason I’ve found it to be a bit more foolproof than RS-485, at least for fools like me.
its more common than you think, especially in automotive. its usually not on the main network but its very common to use between boards, IE you have a controller board with a micro that’s on the main bus but its daughter boards are using uart over can so the controller can manage whatever drivers and devices are out there.
Does the CAN bus specification specify a limit on nodes within a system? I didn’t think it did. I am just confused about what the “stuck with only 32 devices on a bus” statement refers to.
The history lesson is a little off. While 1996 was the start of the OBD2 standard, There were multiple acceptable protocols at the onset. CAN wasn’t widely used by all the OEMs until the 2000s. Ford hung onto PWM J1850 until 03 with the 6LPSD and then pretty much whole-fleet by several years later. GM used J1850 VPW until the 2005 Vette and gradually switched to CAN by 2010. Honda used ISO KLine until 2005 and was CAN fleet wide by 09. I’m not quite as familiar with BMW, Merc, VAG and the koreans.
bmw/mercedes/vag were using canbus for important stuff by the 2000’s and k-line for minor stuff like window syncronisation on a convertible and other minor body functions. nowadays klines still used but its mostly canbus, however vehicles are starting to feature ethernet bridges , along with recent security measures its blurring the lines significantly. theres still canbus under the skirt as it were but its not now like it was.
In my workplace we use plenty of CAN (and CAN over EtherCAT). Both are very common for connecting the electric motor drives we use in our robots.
“with each each frame”.
Not a chat bot, definitely!
Are we surprised about the use of CAN outside of automotive? CiA wants a word! No, not the intelligence agency, but “CAN in Automation”, the consortium from 1992 governing CANopen.
I will skip the almost obligatory “CanOpener” joke
CAN is just a terrible bus. Clever in 1986, but today, use Ethernet. Please. CAN sends data TO a particular address; where does it come from? nobody knows! Well, actually… you have to maintain a separate document showing that some node X receives a message, it must have come from sender Y because that’s who’s supposed to send to X. You have constraints on addresses, because addresses encode priority (!). Your payload is 8 bytes, max. How do you know how long your message is? See the extra table you have to maintain externally. Oh, you want to have a sensor repeat a value every millisecond — better put that in your table, too, and make sure you don’t overload the bus! RS-485 will run > 10 Mb/s over 40 feet — you can run 1 Mb/s over longer than a football field!
In 2025, CAN should be CANned. Kaput. Done. Over. Bad Idea that just won’t die.
And there is a significant push towards Ethernet, to be sure. But objectively terrible? I disagree. It might be terrible at the specific application that you envisioned in your mind, but it’s definitely got some merit.
First, what you’re describing is pub-sub, and that can also be done on any other physical layer. Max payload is not 8 bytes anymore, modern CAN, CAN FD or CAN XL allows for more bytes – 64 for FD and 2048 for XL.
Also, comparing CAN and ETH is not comparing apples to apples, it’s at best comparing apples to… fruit. But anyway, modern ethernet requires a switch at each node, CAN allows all nodes to share the same collision medium. Yes, there is bigger risk of congestion, but each end device is much simpler and cheaper than if you wanted a typical modern ethernet interface. Also, except for the most modern 10BASE-T1L/-S you’re looking at more wires to achieve the proper bandwidth. Naturally these are also where the industrial segment is really pushing these days. With APL/T1L with support for Ex ia and 10Mb over 1km trunk line and robust cable support. But stil you’re looking at a more complex and more expensive communications stack, (hardware and software) which might not necessarily be cost effective for simpler equipment.
Bear in mind, LIN bus is also still used in automotive – with only 16 nodes and 19.2Kb data rate. That will almost certainly never be replaced by ETH directly.
BTW; I don’t know what your reference to RS485 was supposed to prove, but CAN physical layer is /pretty close/ to RS485
Just to confirm: the pun was intended. Couldn’t think of anything witty, so I went with lower-effort humour.
Allen Bradley (Rockwell) use CAN, morr or less, branded as DrviceNet.
Though why you would today, with the abundance of cheap Ethernet options, I just don’t know.
I am also surprised automotive has not moved towards Ethernet solutions.