1
\$\begingroup\$

I am studying CAN interface hardware for the design of an automotive scanner. So far, I have identified the following types of CAN:

  • CAN 2.0 High-Speed: bit rate up to 1Mbps
  • CAN 2.0 Low Speed: bit rate above 40Kbps up to 125Kbps
  • CAN-FD: bit rates higher than 1 Mbit / s

From what I studied, the difference between High Speed ​​and Low Speed ​​is in the physical layer only, while CAN-FD is also different in the upper layers, mainly because it allows payloads larger than 8 bytes.

However, I still have some doubts regarding CAN-FD and CAN non-FD (CAN 2.0).

About CAN not FD (CAN2.0): I checked out the discussion at Controller Area Network (CAN), high speed and low speed and in the in the chosen answer is said that High Speed ​​CAN and Low Speed CAN has difference in Phyical Layer implementation. So, I have the following question:

  1. Since I have the 120 Ohm resistor required for High Speed ​​communications, and the data rate is configurable, then, if the CI I choose for my scanner allows up to 1Mbps, I could use it to communicate with different vehicles with different data rates like 125Kbps, 250Kbps, 500kbps and 1Mbps ?

About CAN-FD

  1. Assuming that my hardware is compatible with CAN-FD, that is, it has a controller and transceiver that support CAN-FD. Could I use this same hardware to communicate with vehicles that have CAN 2.0 High Speed ​​or Low Speed? I verified at Can you use a CAN FD transceiver for low speed (fault tolerant) CAN? that it is not recommended, however I found in CAN FD – The Next Big (Fast) Thing and other web sites, that CAN FD is reverse-compatible with existing CAN 2.0 networks.
\$\endgroup\$
1
\$\begingroup\$
  1. The referenced accepted answer has some huge issues.

First, it mixes baud rates with physical layers. The correct answer would be that both high and low speed controllers can be programmed to different baud rates, the difference is in maximum baud rate supported by them. So, yes, if you have high speed controller you can run it at the baud rate of low speed bus.

Second, the answer suggests that transceivers can be "programmed" to high or low speed bus and then again mixes baud rate into picture. I am not aware of any transceiver that can work on both high and low buses. AFAIK they a) are designed specifically for one or the other and b) have only maximum supported baud rate specified, the actual baud rate will be defined by the controller.

Third, the answer suggests that adding high-speed termination resistor to low-speed bus somehow makes high-speed transceivers work on low-speed bus. This is not true. They have completely different signalling levels and both depend on specific placement of the termination resistors on the bus.

In the end, while you can run high-speed node at the low-speed baud rate it will not make it compatible with low-speed bus.

  1. CAN FD is backward-compatible with high speed (or "classic") CAN.

This means that CAN FD controller + transceiver can be connected to CAN 2.0 bus and will be able to send and receive standard CAN frames. Of course, on CAN FD bus it will be able to send and receive CAN FD frames.

However if CAN FD controller tries to send CAN FD message on classic CAN bus it will be treated as an error and will force standard nodes to reply with error frame, destroying FD frame in the process. This, by the way is explained in the second article you've referenced.

If you put these together, CAN FD being backward-compatible with high-speed CAN automatically means that it is not compatible with low-speed CAN.

  1. This was not your question, but my guess is that this is your goal - to be able to connect to all three versions of CAN bus from one device.

To do that first you have to understand that the difference between Low and High speed is on physical level. The termination resistors on High speed bus are fixed 120 Ohm at the ends of the bus. The termination resistors on the Low speed bus depend on the number of nodes and placed in pairs at each node. Furthermore, the High-speed resistors pull CANH and CANL lines together while Low-speed resistors pull lines apart (CANH to ground, CANL to Vcc).

As such, they use different transceivers.

The difference between CAN FD and Classic CAN (both High and Low speed) are on protocol level, so CAN FD frames are not recognized by Classic CAN nodes.

As such, they use different controllers.

However, since CAN FD controllers are backwards compatible, the combination of CAN FD controller and CAN Low-speed transceiver can (theoretically) work on Low-speed bus. Consequently, the hypothetical device with CAN FD controller and two transceivers (High and Low speed) should be able to connect to all three types, not at the same time, of course.

You just have to find CAN FD controller that can work at that low baud rate. I know that there are classic controllers that can do that, e.g. SJA1000 controller is often used with either TJA1041 or TJA1054A transceivers.

| improve this answer | |
\$\endgroup\$
1
\$\begingroup\$
  1. Since I have the 120 Ohm resistor required for High Speed ​​communications, and the data rate is configurable, then, if the CI I choose for my scanner allows up to 1Mbps, I could use it to communicate with different vehicles with different data rates like 125Kbps, 250Kbps, 500kbps and 1Mbps ?

Yes. Though not at the same time on the same bus, obviously.

Details: your CAN controller prescaler clock must be able to accurately divide the incoming clock for the given baudrate. Depending on clock choice, you might not be able to support all of the standard baudrates.

  1. Assuming that my hardware is compatible with CAN-FD, that is, it has a controller and transceiver that support CAN-FD. Could I use this same hardware to communicate with vehicles that have CAN 2.0 High Speed ​​or Low Speed?

You can use it to communicate with "high speed" since it uses the same signal levels and is backwards compatible. It can't be used to communicate with "low speed" unless you switch the transceiver. But "low speed"/fault tolerant CAN is an obsolete technology and not something you need to worry about unless you specifically know that you need to communicate with such a network.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.