How hard is CAN?

[Siwastaja]

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

Problem is, it doesn't guarantee every node successfully received the message, so you need to implement something by yourself anyway - usually just periodic flooding and timeouts, or separate acknowledgement messages (as specified by yourself).

What ataradov mentioned, as far as I remember, the error counters are required by the CAN standard itself and thus at least usually implemented by the MCU CAN peripheral. Therein lies a danger, it might still need some software action like the peripheral going automatically to bus off state, but programmer having to manually poll a flag or get an interrupt and try enabling it again.

[Siwastaja]

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.

Yeah, on physical level CAN is very similar to RS485 - no wonder because CAN design is originally motivated by RS485 - but thanks to being newer, it fixes the brainfarts of RS485, namely someone messing up the A/B signal naming at some point so the only way to know which is which is to try. CANH and CANL instead are well defined and everyone follows the standard. Another is the weird tradition of even professional designers not understanding the necessity of GND in RS485 system. Third is the stupid biasing mess of RS485 caused by the poorly thought out idle levels and receiver hysteresis, where newer transceiver chips kinda-sorta fixes the issue, but if communicating with existing devices, you can't know which transceiver they used, so have to really go for that biasing network analysis.

CAN fixes all that, just add a 120 Ohm termination resistor between CANH and CANL, connect CANH, CANL and GND respectively to the bus, and everything Just Works.

[peter-h]

OK. Yes, I recognise the issues, which you point out completely correctly!

That 120R resistor does draw a lot of current though

I am also trying to work out what kind of driver support I would need to get CAN to do something useful. With ETH, you have LWIP, and you have to write the low level input/output code (actually you get it from ST, sort of working). With USB, you get a big mess from ST but eventually it works (I have a block device and a VCP running).

[Siwastaja]

That 120R resistor does draw a lot of current though

Well, only when someone's sending, and it's not that much. Dominant differential voltage is around 1.5V-2.0V or so, and if half of the bits are dominant, and half of the total bus bandwidth is being used, that will be 0.5 * 0.5 * 2.0V/60 ohms = 8mA (4mA on each terminator resistor).

But you need to choose a resistor with proper power dissipation ratings so that you won't blow it up if CANH/CANL accidentally touches GND or +5V or, worse, 12V. Transceivers are typically designed to survive that.

But sure, CAN is not low power.

[Berni]

Problem is, it doesn't guarantee every node successfully received the message, so you need to implement something by yourself anyway - usually just periodic flooding and timeouts, or separate acknowledgement messages (as specified by yourself).

What ataradov mentioned, as far as I remember, the error counters are required by the CAN standard itself and thus at least usually implemented by the MCU CAN peripheral. Therein lies a danger, it might still need some software action like the peripheral going automatically to bus off state, but programmer having to manually poll a flag or get an interrupt and try enabling it again.

Yes if you are looking for the CAN controller to tell you "This message has for sure successfully reached all recipients that want the message" then you indeed can't get that. Implement a separate ACK message in your application layer if you need that. In most cases you don't care if your message got to everyone, what is a cars body control module supposed to do if the fuel tank level sensor reading was not received? It could try to retransmit, but if nobody raised a error on the bus during that failed transmission then likely nobody is even listening so retransmiting won't get the message trough anyway.

What the ACK mechanism actually does is that it makes sure every device that is actively participating on the bus has received the message with no errors. If just one CAN device finds the CRC calculation wrong it can intentionally break the ACK section of the message and so force the sender to re transmit it again in hopes of the message making it trough without corruption this time. This does mean that devices that did successfully get the message the first time around will get it twice, but this is usually better than simply not getting anything. All this happens inside the CAN controller, so you can be actively talking on a bus during a thunderstorm storm (that potentially kicks huge transients on the bus every so often), yet no messages get lost and never does a message contain corrupt data. The application layer doesn't need to worry about this, it just works.

Yes you can get into bus off conditions and all that, but the driver should know how to deal with it. This is why i test firmware drivers by shorting out stuff randomly as its running. If it locks up for an extended period of time then the driver is shit and needs to be fixed. The I2C controllers on STMs i found are particularly easy to permanently lock up if you as much as look at them the wrong way.

OK. Yes, I recognise the issues, which you point out completely correctly!

That 120R resistor does draw a lot of current though

I am also trying to work out what kind of driver support I would need to get CAN to do something useful. With ETH, you have LWIP, and you have to write the low level input/output code (actually you get it from ST, sort of working). With USB, you get a big mess from ST but eventually it works (I have a block device and a VCP running).

The CAN bus is at 0V differential when idle so no current trough the termination. All the current draw is just the idle current of CAN transceivers just listening on the bus. Even when it does transmit it will be pulsing about 1 to 4V onto those 120Ohm and so not a lot of current. This is required to get good speeds over long twisted pairs. Having higher differential impedance required higher impedance cables, but even going to telegraph pole line spacing only gets you to 600 Ohm impedance.

RS485 is worse here because it typically requires a biased termination that always draws power in order to keep the bus in the logic high idle state.(But modern transceivers have a zero offset built in to not need that). But is is also a simpler protocol than CAN. So if none of the high reliability bells and whistles that CAN provides are useful for your application then you might as well just use RS485.

You don't need LWIP to get Ethernet working. You can send raw Ethernet frames into the PHY and they will get sent out. Connect another MCU to it using a cross Ethernet cable and that frame will be received on the other end. Much the same like you would use CAN. If you use a ethernet hub you could even have more than 2 devices on the bus. You only actually need LWIP once you want to not only conform to the Ethernet physical layer standard but also want to conform to IPv4 so that your device can take part in modern LAN networks (just because IPv4 is the language that switches and routers speak). Yes it brings extra complexity but it also means your device can send a few megabyte sized messages to the other side of the world in less than a second.

[uer166]

What the ACK mechanism actually does is that it makes sure every device that is actively participating on the bus has received the message with no errors. If just one CAN device finds the CRC calculation wrong it can intentionally break the ACK section of the message and so force the sender to re transmit it again in hopes of the message making it trough without corruption this time.

AFAIK (and I could be wrong), it's the opposite, if even one device receives the message successfully, it'll get ACKed via a dominant bit. The other nodes where the message may have been corrupted can't force a recessive bit, so the sender has no clue that all but one nodes didn't receive the message.

This is a limitation of the dominant/recessive implementation and unless you have one sender and one receiver, the ACK mechanism is not really useful in the real world.

[woofy]

What the ACK mechanism actually does is that it makes sure every device that is actively participating on the bus has received the message with no errors. If just one CAN device finds the CRC calculation wrong it can intentionally break the ACK section of the message and so force the sender to re transmit it again

As I understand it, the ACK bit is dominant and a NACK recessive. I don't see how a node with a CRC error can scrub the ACK bit. It can only assert an ACK. Depending on how the node failed in the frame it might not even know where the ACK bit is as far as timing is concerned. All it can do is ignore the message.

[peter-h]

You don't need LWIP to get Ethernet working

You don't need TCP/IP to use ETH but unless you are using ETH as some sort of private interconnect system, you do need it to produce something usable. I guess there are such private LANs in one-company product domains, especially if you want deterministic timing etc, but this is not common. And in many situations you can build a "private LAN" for a lot less money and complexity than ETH, using e.g. RS485 (which needs a Master, but often that is fine).

Which I suppose is where CAN comes in. It is for where galvanic isolation isn't needed, which is only a subset of "private LANs". Often you want or need isolation just going between two buildings, because the ground potential difference can be pretty big. Especially where mains earth is obtained by connecting to the Neutral wire, and when N is carrying say 10000A spikes, and the two buildings are on different phases... you get the idea. I've been building and selling isolated interface products for decades, and the difference in how many get blown up varies dramatically according to whether isolated or not.

Is CAN intended to be multi-master? I know it won't blow up, or even take the chips out of spec (as would be the case with RS485) but is that normal usage?

Many years ago I designed a private LAN using a token-passing mechanism, and MIL-1553 transformers on the physical layer. It did ~1mbit/sec app to app. Today you would use ETH for that, but only because of the integration available today. Another private LAN I interfaced to, many years ago, was a 64kbps one used in huge Hitachi heavy-industry PLCs, which used very high power (watts) to give it immense noise immunity. Big ferrite transformers for isolation. I built an interface to it using a Xilinx 3064 FPGA to construct a 64 bit UART, enabling my customer to interface to it via RS422, from PCs running unix.

[Siwastaja]

Is CAN intended to be multi-master? I know it won't blow up, or even take the chips out of spec (as would be the case with RS485) but is that normal usage?

There is no concept of masters or slaves at all.

It's just "shout to the common bus, subscribe to things of interest", that's it. You can use it for whatever you want; for some things, such strategy works fundamentally better than for others.

[hans]

Indeed, there is no master. The message ID is transmitted at the start of the frame. Since  a "0" on the bus is dominant, it means that lower bus messages are prioritized. Each transceiver will monitor the bus value and abort transmission if there is a collision as the losing node will see a mismatch on the bus versus it's own data.

You could look at it as an open-drain circuit. For example, in I2c clock stretching, the slave can also pull a clock line down for a while till it's done processing. By reading the voltage level of SCL, the master can then wait till the stretch is complete.

Pretty much everything on the CAN bus is a broadcast. You have certain data packets transmitted on particular IDs. In theory you could create a 'connection' structure within the 8 bytes of payload, or use like a "server" on a particular message ID which then handouts connections on separate message IDs for the data phase. I don't know, probably someone has done it, but since CAN complexity is all in the proprietary protocol stacks.. it's hard to figure out what's going on unless you have lots of detailed CAN logs and/or a live test system that you can retrigger, modify or replay messages on. But given that 8 bytes of payload is all you got, most systems will need some magic in the protocol stack to retain state across multiple packets (e.g. to implement command and memory packets for a bootloader)

[nctnico]

I don't know, probably someone has done it, but since CAN complexity is all in the proprietary protocol stacks.. it's hard to figure out what's going on unless you have lots of detailed CAN logs and/or a live test system that you can retrigger, modify or replay messages on. But given that 8 bytes of payload is all you got, most systems will need some magic in the protocol stack to retain state across multiple packets (e.g. to implement command and memory packets for a bootloader)

Actually I'm working on a project that 'streams' data over the CAN bus using multiple CAN messages of necessary. Since the data integrity is well covered by CAN, the main concern is to check whether the length of what has been send it equal to the length and whether the CAN messages are received in the right order.

[langwadt]

I don't know, probably someone has done it, but since CAN complexity is all in the proprietary protocol stacks.. it's hard to figure out what's going on unless you have lots of detailed CAN logs and/or a live test system that you can retrigger, modify or replay messages on. But given that 8 bytes of payload is all you got, most systems will need some magic in the protocol stack to retain state across multiple packets (e.g. to implement command and memory packets for a bootloader)

Actually I'm working on a project that 'streams' data over the CAN bus using multiple CAN messages of necessary. Since the data integrity is well covered by CAN, the main concern is to check whether the length of what has been send it equal to the length and whether the CAN messages are received in the right order.

I adapted this: https://en.wikipedia.org/wiki/ISO_15765-2 skipping the Flow control frames

[SiliconWizard]

I don't know, probably someone has done it, but since CAN complexity is all in the proprietary protocol stacks.. it's hard to figure out what's going on unless you have lots of detailed CAN logs and/or a live test system that you can retrigger, modify or replay messages on. But given that 8 bytes of payload is all you got, most systems will need some magic in the protocol stack to retain state across multiple packets (e.g. to implement command and memory packets for a bootloader)

Actually I'm working on a project that 'streams' data over the CAN bus using multiple CAN messages of necessary. Since the data integrity is well covered by CAN, the main concern is to check whether the length of what has been send it equal to the length and whether the CAN messages are received in the right order.

I've never used CAN on a project as of yet. How is data integrity handled? Does it automatically compute and transmit CRCs? Or what other means does it use?

[nctnico]

I don't know, probably someone has done it, but since CAN complexity is all in the proprietary protocol stacks.. it's hard to figure out what's going on unless you have lots of detailed CAN logs and/or a live test system that you can retrigger, modify or replay messages on. But given that 8 bytes of payload is all you got, most systems will need some magic in the protocol stack to retain state across multiple packets (e.g. to implement command and memory packets for a bootloader)

Actually I'm working on a project that 'streams' data over the CAN bus using multiple CAN messages of necessary. Since the data integrity is well covered by CAN, the main concern is to check whether the length of what has been send it equal to the length and whether the CAN messages are received in the right order.

I've never used CAN on a project as of yet. How is data integrity handled? Does it automatically compute and transmit CRCs? Or what other means does it use?

Every CAN message has a CRC which is handled by the hardware. If you receive a CAN message from the driver layer, you can be very sure the message has been transported over the CAN network correctly.

[peter-h]

So you need to serialise the packets, because not getting an ACK does not mean the far end didn't get the message, etc, etc. But presumably you aren't sending data over a large-latency channel (which would need a large reassembly window). With CAN delivery (or non delivery) is probably "instant".

What made them choose 8 bytes?

[ataradov]

What made them choose 8 bytes?

They did not want one device to occupy the bus for too long.

CAN FD extended that to 64 bytes. But they also made possible to increase the baudrate in the data phase, so overall duration is still short.

[nctnico]

So you need to serialise the packets, because not getting an ACK does not mean the far end didn't get the message, etc, etc. But presumably you aren't sending data over a large-latency channel (which would need a large reassembly window). With CAN delivery (or non delivery) is probably "instant".

I'm not reassembling anything. If a CAN packet gets lost, the entire message needs to be send again as CAN has no way to retransmit messages and I don't want to create the overhead tcp/ip has (for example) where each piece of data also has a two way handshake, sequence numbers, etc. The message that I need to send over CAN are typically small anyway (a few CAN packets at most) so re-sending the entire message is not much overhead. With a high enough bitrate, message transfer is almost instant.

[uer166]

If a CAN packet gets lost, the entire message needs to be send again

This is the way, don't overthink it. You can do an entire firmware update this way, and if it keeps failing repeatedly, the network is way too marginal to be useful.

[JPortici]

Is CAN intended to be multi-master?

There are no masters, there are no slaves. There are nodes. Each node broadcast messages in the network, each message will have its ID. Another node that want to read that message will have its filters set up to accept the ID

[Berni]

Here is what a CAN message looks like on a bus:


As you can see there is a CRC section and the ACK is actually 2 bits long. It needs to have a dominant bit followed by a recessive bit in order for it to be successful ACK.

So the way it works is that all devices calculate the CRC as they are getting it and will ACK when the CRC matches successfully, however if the CRC is wrong it the device can break the ACK section by transmitting back a dominant bit in the area where the ACK should be recessive. This intentionally breaks the message with the intent of causing it to be resent. Even if just ONE device on the whole bus fails a CRC check it will make it fail the ACK. All this happens auto-magicaly inside the CAN controller.

Also notice how the dominant ACK bit is surrounded by by recessive bits. This is the mechanism that breaks the bus when you use too long cables. The address arbitration in the beginning requires the wires to be short enough for a 1 bit to make a full round trip to all devices.

EDIT:
Also at any point can a CAN device respond using a error frame that is 6 dominant bits in a row.
This is the equivalent of nuking anything on the bus since a message is not allowed to have 6 consecutive dominant bits anywhere in it. So it destroys the message and forces a reset of state on all devices in order to give the bus the best chance of recovering.
This means that if ANY device on the bus sees something on the bus that looks very wrong it can hit the nuke button. This is why messages rarely go missing with no ack or error.

[ataradov]

The node technically should never override ACK Delimiter on its own. It should always be recessive. It may be overridden as a part of the 6-bit error transmission:

A station detecting an error condition signals this by transmitting an ERROR FLAG. ..... Whenever a BIT ERROR, a STUFF ERROR, a FORM ERROR or an ACKNOWLEDGMENT ERROR is detected by any station, transmission of an ERROR FLAG is started at the respective station at the next bit.

And for some reason for CRC errors the error is indicated only after the delimieter:

Whenever a CRC ERROR is detected, transmission of an ERROR FLAG starts at the bit following the ACK DELIMITER, unless an ERROR FLAG for another condition has already been started.

So, CRC errors and corresponding error flag would be disjointed, making it very hard to use for real error detection. For frames with a CRC error both bits of the ACK field would be correct.

This will work fine if you use it as intended - broadcast and forget. Treat error flags as asynchronous resets not tied to any specific transmission.

[Berni]

Ah sorry i was assuming that the CRC error frame is sent instantly much like the other errors are, so that it would break the ACK.

[Rudolph Riedel]

And yes, a lot of devices on the market have the same exact IP.
All Atmel/Microchip stuff is M_CAN too.

This is not correct, at least their dsPIC33CK, PIC32MK and PIC18 use something else and from the looks of it not compatible to each other. The ATSAMC21, ATSAME51 and ATSAME70/ATSAMV70 all use the Bosch M_CAN IP though.

And I just found that they have a PIC32CM variant with CAN-FD now: PIC32CM2532JH01 / PIC32CM5164JH01
I knew about PIC32CM, but so far I only found the variant without CAN.
These are as far as I can tell a rebranded copy-paste job from the ATSAMC2x, only the memory options differ.
Oh, there also is a PIC32CM with Cortex M23, Microchip does a bad job at naming controllers.
But well, the CAN-FD variants are not in stock anyways.

And regarding the STM32 from the OP, a few have CAN-FD now and actually use Bosch M_CAN, like STM32G4 or STM32H7 series.
But STM changed it, they use dedicated SRAM and come pre-configured so the functionality is reduced.
STM32G4 only have a subset with tiny FIFOs and while the STM32H7 allows for broader configuration it only has 10kiB of dedicated SRAM for two modules combined.
So mostly the same but not really.

[Siwastaja]

it only has 10kiB of dedicated SRAM for two modules combined. So mostly the same but not really.

IMHO, 10KB is a lot for such low-speed interface (CAN FD around ~5Mbps max), even if part of it is "wasted" on filter configuration and not actual FIFOs. At some point, you have to process the data anyway. The flexibility in H7 is great because you can exactly decide how many (1 or 2) and large FIFOs and fixed mailboxes, if any, are used, so nothing of that 10KB is wasted.

[ataradov]

This is not correct, at least their dsPIC33CK, PIC32MK and PIC18 use something else and from the looks of it not compatible to each other.

Well, yes. I mostly speaking about ARM devices. I just don't care about other stuff, and 8-bit specifically.

Microchip does a bad job at naming controllers.

LOL, yes.