How hard is CAN?

[peter-h]

I have no plans to get involved in CAN but my board (32F417) has a provision for it, with an L9616 interface chip optionally on the board.

My sole exposure to CAN is with stuff like VAG-COM and various ODB2/CAN cables, for doing useful mods to my VW. It is pretty obvious that VW publish almost nothing and people like VAG-COM have reverse engineered the bitfields, by changing bits and seeing what has changed on the car. So the whole system is proprietary.

I have also seen CAN used in avionics (Garmin mostly) and again it is totally proprietary, as is their ETH usage.

So it may be that just about all CAN applications are proprietary, and for the most part the only people who can interface to a product are those who made it... Everybody I have seen use CAN was using it purely for their own interconnects.

Is that really true?

The protocols also seem damn complicated, although nothing can be as horrible as ETH+LWIP etc.

Is the above a reasonable summary?

Many years ago, the electronics mags were full of CAN this and CAN that, and it was going to take over the world, kill off RS232, RS422, RS485, you name it. It ended up used almost entirely in automotive although it seems to have branched out a bit.

[uer166]

That's not a reasonable summary at all; you need maybe 100 lines of code total to make it work. They're relatively complicated peripherals but nothing like Ethernet or USB, much closer to the UART side.

CAN is only a physical layer and a low-level frame standard that's fully documented (not sure why you mention it's closed). What you actually send in the packets is up to you, so of course there is no inter-operability between stuff. It's used all over in automotive and industrial applications, and does have some advantages over RS485.

To save you some trouble: STM32 CAN FD peripherals are Bosch M_CAN IP I believe, so the documentation for that applies.

[ataradov]

CAN itself is easy, but meaning of the data is proprietary. Same thing applies to UART. Many systems have proprietary data sent over UART too.

CAN was not going to "kill" other interfaces and it was specifically designed for automotive use, so of course it found most of the uses in automotive environment.

And yes, a lot of devices on the market have the same exact IP. All Atmel/Microchip stuff is M_CAN too. Same driver code just works across all those devices. The relevant datasheet section is usually just a copy-paste of the Bosch datasheet. And in some cases vendors take some creative liberties with the text, so having original Bosch datasheet handy helps.

[uer166]

Ah, yes, the data is largely proprietary. In the same way you can't necessarily use a IP camera without their software, you probably can't connect to a car and get meaningful data without an ID/data/format database such as a DBC file.

[eutectique]

As was already said, CAN is the physical layer. On top of this sit a lot of more complex and expensive stuff.

UDS and J1939 -- used widely in automotive, agriculture, material handling. Can coexist on the same wire.

ISOBUS -- based on J1939, main use is agricultural machinery and implements. The main driving idea behind this protocol is to bring consent and consistency to the wild zoo of incompatible proprietary implementations. Say, an ISOBUS display installed in a CNH tractor can control an attached John Deere's manure dispenser. Generally speaking, any independent manufacturer of manure dispensers is welcome to the party, subject to ISOBUS certification.

Then comes CANopen -- used in industrial automation.

Your product would probably require some sort of certification (apart from the obligatory EMC/EMI), if you want it installed on a machine or a factory floor.

[Siwastaja]

CAN is really good, simple and easy to understand, but of course not the optimum solution for every job.

Compared to UART for example, you get:
* Multi-node bus
* Packaging of data with 8-byte payload PLUS a hardware level identifier which you can use to describe content / node id / whatever and which also doubles as a priority level.

CAN is optimum in cases where you flood relatively short data packets (but usually longer than 1 byte, so benefit from the packetization) from multiple sources and want to "subscribe" to them. There is no guarantee of getting packets through, and no usable form of acknowledgement, so most typically you just design the systems to have timeouts in case required data is not received in time. CAN itself is simple and low level, what you do with it and how is up to you.

Also CAN peripherals in microcontrollers are often very powerful, allowing built-in filtration (for example: ignore data not matching whatever ID) and whatnot, but the flip side is, there are quite a few registers to configure, and quite a few state charts to understand (e.g.: you have to enable configuration mode, then enable running mode, or whatever). For example, the CAN peripheral in STM32H7 series is quite complicated because it is so flexible, you have to configure the memory layout you want to use for it. It takes easily 1-2 full days to get started with it (compare to ½ hours of UART peripheral).

Luckily, you can see there are not too many CAN peripherals; not many MCU manufacturers did their own, but licensed something already made, so you can find the exact same CAN peripheral, with exact same documentation (maybe with different visual style) in MCUs of different companies.

[JPortici]

Is that really true?

basically

The protocols also seem damn complicated, although nothing can be as horrible as ETH+LWIP etc.

oh, you're in for some fun
https://support.ixiacom.com/sites/default/files/resources/whitepaper/ixia-automotive-ethernet-primer-whitepaper_1.pdf
nowadays most diagnostic and programming is done over ethernet. You can still do part of it over CAN, probably because legislation (OBD and such) and support for legacy tools

There are some standards like CANOpen or CiA and there are brands that adhere to those
There are protocols for networking over CAN/LIN/K-Line/whatever to implement multiframe messages and node-to-node communication which are mostly universal (though BWM like to have its own variation of the protocols)

but can itself is actually not that hard, i wouldn't think of anything else if i wanted to connect multiple nodes and have something that does arbitration on its own. you don't even need transceivers in some scenarios (short distances, same board)

[Berni]

CAN is just the physical layer protocol. Nobody is going to sue you for sending things the 'wrong things' over it, it's job is to get the bits across the wire, but what you put into those bits is up to you. Just like UART or RS485 or Etheret can carry any traffic you like.

There is a good reason there are multiple kinds of protocols, each one is designed for a specific kind of thing.
UART: Simple as can be 2 wires directly taking TTL signals, no chips needed
RS232: Same as UART but with level shifter chips that give it more voltage level and more resilience to damage.
RS485: Also UART but over differential so it can go really far over twisted pair.
RS422: Like RS485 but full duplex so don't have to wait for silence on the bus
CAN: Like RS485 but with built in arbitration that lets large numbers of devices talk on a bus but never collide (Tho this limits speeds and wire lengths)
BASE100 Ethernet: Like RS422 but way faster and with galvanic isolation to fix ground loop problems.
Single pair Ethernet: Like BASE100 but more like RS485 by needing just one pair.
10GBASE Ethernet: Like BASE100 but with twice the wires with 100x the speed, but only works over short cables.
USB 1.0: Like RS485 but at a standard 100Kbit or 12Mbit baudrate and extra standaridsed negotiation logic and standardised power connections. Short cables only.
USB 2.0 Like USB 1.0 but way faster.
...etc

All these interfaces can be used to connect two (or more) devices and carry data between them. Each has its own pros and cons, you just pick the one that fits the application best. Nobody said that you MUST use BASE100 Ethernet for TCP/IP. You can use it to send any proprietary data between two devices (It just won't work with off the shelf network switches), if you need a reliable way to send 100Mbit of data over 200m of twisted pair with galvanic isolation... there you go. And you do see protocols used in this way here and there. Just because TCP/IP is the most popular use of Ethernet doesn't make it the only use.

When it comes to CAN there is no distinct "most popular" use for it. What data is sent is fully dependent on what protocol you run in the next layer up. You could use it for SAE J1939 or SAE J2284 or NMEA2000 or CANOpen or CAN Aerospace or ISOBUS or DeviceNet...etc or you could say that none of these protocols cover your particular use case and create PeterCAN™®. In exactly the same way you will see all sorts of higher level protocols running on top of RS232 or RS485.

The only case you will get in trouble is if you used a standard and trademarked protocol, like say USB, place the trademarked USB logo on your device and then proceed to do something with the device that is forbidden by the USB specification. You can get sued for trademark infringement of the USB logo because you did not have the permission to use it, because getting permission requires your device to be certified to meet USB specification requirements.

[DiTBho]

Can is not a network device
Can is not a char dev device

That's the only problem with Linux

[mikeselectricstuff]

RS485: Also UART but over differential so it can go really far over twisted pair.

And can have multiple devices on one bus, though there is no intrinsic collision detection or arbitration

RS422: Like RS485 but full duplex so don't have to wait for silence on the bus

RS422 is like RS485 in terms of using differential signal levels, but more like RS232 in typical use cases, in that it is a full-duplex point-to-point link between 2 devices.

[tszaboo]

RS485: Also UART but over differential so it can go really far over twisted pair.

And can have multiple devices on one bus, though there is no intrinsic collision detection or arbitration

It's really my favorite go-to interface. I had as much as 32 devices on 2KM cable, or 64 devices on 4 backplanes going at 25 MBIT/s, while it is as easy to handle as UART.

[nctnico]

I have no plans to get involved in CAN but my board (32F417) has a provision for it, with an L9616 interface chip optionally on the board.

My sole exposure to CAN is with stuff like VAG-COM and various ODB2/CAN cables, for doing useful mods to my VW. It is pretty obvious that VW publish almost nothing and people like VAG-COM have reverse engineered the bitfields, by changing bits and seeing what has changed on the car. So the whole system is proprietary.

I have also seen CAN used in avionics (Garmin mostly) and again it is totally proprietary, as is their ETH usage.

So it may be that just about all CAN applications are proprietary, and for the most part the only people who can interface to a product are those who made it... Everybody I have seen use CAN was using it purely for their own interconnects.

Is that really true?

That sums it up nicely. From what I've seen CAN protocols are modified to meet the needs of the customer that is building the contraption that is going to use the CAN bus. In some cases equipment manufacturers simply specify their CAN message format so you can read it.

The protocols also seem damn complicated, although nothing can be as horrible as ETH+LWIP etc.

There is nothing complicated about CAN. Devices typically send status update packets with the status encoded in the payload data repeatedly. Basically a broadcast service. A device that listens to the messages, acknowledges reception of the message.

[uer166]

A device that listens to the messages, acknowledges reception of the message.

Just want to add that in practice that doesn't work, because when you have multiple receivers in a network (which is usually the case), they ACK the same message, and you don't know if the right ECU actually received it or not, you only know that one of them ACKed the frame. In practice you use timeouts and whatnot as was mentioned before. CAN is largely used for state-based comms where you just send the same state message every 10ms or whatever in a vehicle such as button states, headlight on or off, etc.

[nctnico]

Ofcourse you need some time-outs at the receiving side to prevent using a stale state. And at the transmitting side to take a message off the bus that never gets acknowledged.

[Berni]

Yes the acknowledgement only requires one receiving device to ACK the message, and quite often devices will acknowledge everything it sees on a bus.

However CAN devices can also NACK a message with a failed CRC or even force abort a message mid way trough if what they are receiving doesn't make sense. They do this by intentionally causing a bus collision, this makes the transmitting node stop and re transmit the message again. So that way it makes sure all nodes actually received the message. The before mentioned ACK/NACK bit also plays a role here because it requires the round trip delay to be within one bit timing, this makes CAN stop working as soon as you use too long cables. So this ensures that the cables are always short enough for the address arbitration at the start to work correctly (Rather than cause weird intermittent issues when the moon aligns and the wrong two devices try to arbitrate at just the right time).

These things are perhaps the biggest advantage CAN has over other interfaces. It can detect and fix problems as they happen without the upper application layers even knowing anything went wrong. Combined with differential signaling it makes the bus very very reliable even in noisy environments, exactly what you want in automotive. But at the same time this puts a hard limit on cable length due to the speed of light, hence why CAN is used on vehicles or machines and not in buildings (they are too big). It also has lot of overhead so 1Mbit CAN will only actually transfer up to about 500Kbit of useful payload data. The new CAN-FD standard attempts to mitigate this by doing arbitration at low speed and then data transfer of larger payloads at high speed, but not a lot of things use it so far. Car manufacturers are going single pair Ethernet these days because it is even faster.

[Siwastaja]

Can is not a network device
Can is not a char dev device

That's the only problem with Linux

There is no problem in Linux - there is socketcan, well standardized interface which Just Works across UNIX/POSIX systems.

With Windows, the problem is huge - you have to basically write a wrapper for every CAN adapter in existence, which is a total PITA.

For example, I have chosen to provide support for SocketCAN, KVASER and PCAN interfaces. Nearly 100% adapter coverage in linux, but tiny % on Windows, and there seems to be no way around it.

[Siwastaja]

A device that listens to the messages, acknowledges reception of the message.

A clarification though: any device that is "on", acknowledges any message. Basically, if any two devices are alive on an N-device bus, every packet gets an ACK, and you can't know which nodes actually received it. For this reason, CAN's acknowledge mechanism is basically useless (if you have found any use it, please share), and causes more confusion than it helps (also for this reason, CAN peripherals typically offer the feature to turn the auto-resend feature off, simplifying things by removing a useless feature).

As I stated earlier, CAN-based communications often use timeouts on important data. For example: just decide, by convention, that battery voltage is sent every 100ms. If the battery voltage is not received within 500ms, give an error / run some workaround procedure.

[Colt45]

SocketCAN is 10/10 A++++++ would buy again

[ataradov]

(if you have found any use it, please share)

It is useful to eliminate transmitting nodes that may not be able to receive. Those nodes would be stepping on other nodes otherwise.

Each NACK increments a counter and the controller must stop transmitting if the counter reached a set limit.

NAKs in CAN are indeed not for the application use as in other interfaces, but to maintain integrity of the bus overall. Application should basically ignore individual NAKs and just act on counter overflows.

[Berni]

A clarification though: any device that is "on", acknowledges any message. Basically, if any two devices are alive on an N-device bus, every packet gets an ACK, and you can't know which nodes actually received it. For this reason, CAN's acknowledge mechanism is basically useless (if you have found any use it, please share), and causes more confusion than it helps (also for this reason, CAN peripherals typically offer the feature to turn the auto-resend feature off, simplifying things by removing a useless feature).

As i explained above the ACK also serves to make the bus stop working as soon as you use too long cables. This makes sure all devices are close enough for the arbitration process to work correctly.

The auto-resend is useful because it also resends any messages that got corrupt during transmission or reception.

[peter-h]

Interesting input. Thank you all.

I didn't know most of it, though it is unsurprising. So to turn on headlights you send the ON message say every 100ms, for ever. That's why CAN is good for automotive

I've been doing serial comms for > 40 years so I am well familiar with RS232 422 485, and how people blow things up. The major issue with 422/485 is that the chips have a finite max common mode voltage (Vcm) of, generally, -7V to +12V. LT made some -20 to +20, IIRC, but like everything from LT you use it only if you are paid by the hour regardlerss of whether your employer is making money And everybody has read that just 2 wires are needed, and mostly it kind of works, because with floating device will "adjust" its ground to around the average of the A and B wires, so it works by sheer luck. I always tell customers to have a GND wire and this dramatically improves both comms reliability and how much stuff gets blown up. One can stop the blowing up with voltage clamping (VDRs etc); I buy ~100k a year of those. With CAN, you have the same issue AFAICT (L9616 Vcm -5V to +36V) but not in a metal car because there is a common ground.

CAN chips also draw a lot of current - tens of mA AFAICT.

Do mfgs use CAN for important things like the "fly by wire" accelerator pedal? My VW (2012) is CAN but the pedal has a pot on it.

[ataradov]

Do mfgs use CAN for important things like the "fly by wire" accelerator pedal?

A lot of modern systems would use CAN for everything. But there are typically multiple separate CAN networks. What you see on the OBD2 port may not carry safety-critical stuff. Or it may be relayed data for the diagnostics.

My VW (2012) is CAN but the pedal has a pot on it.

Where does the pot go? In new cars there is still some sort of encoder, but it connects to the bus as soon as practical.

Long wires and analog pots in a car does not sound like a good combo.

[Jeroen3]

CAN bus is great. it provides you with an Publish-subscribe pattern that is basically completely hardware.
It implements very easily, most CAN controllers have a number of mailboxes that are memory mapped ready for you to read. For example, Bosch CAN.
^{(not you STM32 bxCAN, you're weird)}
When you have a simple ms counter tick, you can keep track of the expiration of receiving mailboxes. It's actually very easy to use.

Most protocols just extend this model and split up the ID field into system specific flags.
The complicated stuff is when you need to transfer more than 8 bytes. You need some fragmenting, sequencing and all relevant higher level stuff to get a block transfer over CAN bus.
But it's not more complicated because of CAN, it's complicated because of reliable communication.

[Berni]

Some cars do have digital communication to the pedal, but it is not always practical to have all sensors directly on CAN.

Typically you have computer boxes scattered around the car that talk with CAN and then handle multiple sensors/loads from one box. So there might be a box in the back of the car that handles, rear lights, trailer hitch, rear window defogger, fuel tank float etc.. In a similar way a lot of engine specific sensors might go directly to the ECU over a analog wire like the MAF, coolant temp, oil pressure..etc and then the ECU makes them available over CAN by sending them out periodically. So if the throttle is analog then it might be directly connected to the ECU or some other module that is conveniently close to the actual pedal. But if it is analog it will pretty much always have some form of redundant signaling so that shorting out a wire from the gas pedal doesn't make it go full throttle (well until Toyota screws up the software and makes it happen anyway).

[JPortici]

Do mfgs use CAN for important things like the "fly by wire" accelerator pedal? My VW (2012) is CAN but the pedal has a pot on it.

i don't remember what the pot is for.. .or you mean the throttle sensor? that is usually a lever moving a magnet on a shaped piece of metal or viceversa, read position with a hall sensor, convert to signal according to whatever scheme.

accelerator is connected to one ecu, it may be analog signals with a certain relationship for verification / combination of analog-digital (one wire analog 0-5V one wire square wave with corresponding duty cycle) / digital signal using SENT / older and abandoned current loop
if the ECU is not the engine ECU the accelerator position will be sent over canbus. It will probably be sent over canbus anyway as it may be needed to other systems as well (kick down to the transmission ECU)
other critical systems, some old models of fuel pump used to be controlled via canbus, in some electric cars the inverter output power is set via canbus