|
|
[Article is under construction]
|
|
|
**Table of Contents**
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
# Overview
|
|
|
CAN BUS (Controller Area Network) is a very deterministic BUS heavily used in the automotive industry. It is a half-duplex BUS, that operates using a pair of differential signals. Typically, the speed standards are 100K, 250K, 500K or 1Mbit.
|
|
|
|
|
|
CAN BUS may have several tens of controllers on the same BUS and you can typically go relatively long distances such as 10 meters without compromising the speed or reliability. The message id of each message can address other nodes on a CAN BUS (more on this later).
|
|
|
|
|
|
## CAN FD
|
|
|
|
|
|
|
|
|
----
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
----
|
|
|
|
|
|
# CAN FD
|
|
|
|
|
|
<BR/>
|
|
|
|
|
|
## Hardware
|
|
|
# Hardware
|
|
|
<todo>
|
|
|
|
|
|
### Termination Resistors
|
|
|
## Termination Resistors
|
|
|
There are two main reason why termination is required. First, it improves signal quality by removing reflections( oscillations) on the bit edges and prevents communication failure. When signal reaches at the end of the cable the reflections become strong, This is the reason why the termination resistors are kept at the ends. Second reason being, to achieve recessive level (defining a logic 1) in the communication.
|
|
|
|
|
|
CAN bus is a serial bus which transmits binary (0(dominant) or 1(recessive)) signals. When CAN Driver at CAN-node transmits recessive bit, it becomes completely passive. A passive component(i.e. resistor) is required as a 'pull-up' or 'pull-down' or both to a certain voltage level to achieve a required signal level during recessive bit transmission.
|
... | ... | @@ -38,7 +33,7 @@ The termination resistor shall comply with the limits specified in below table: |
|
|
|
|
|
[Termination Resistor Figure]
|
|
|
|
|
|
### Transceiver
|
|
|
## Transceiver
|
|
|
CAN transceivers is an interface between the CAN protocol controller and the physical wires of the CAN bus lines.
|
|
|
It does mainly two tasks:
|
|
|
|
... | ... | @@ -47,10 +42,10 @@ It does mainly two tasks: |
|
|
|
|
|
![Transceiver](uploads/e57d9cf1c22c23d5bf7bf5c4a70c7f05/Transceiver.png)
|
|
|
|
|
|
### Speed and Differential Signals
|
|
|
## Speed and Differential Signals
|
|
|
<todo>
|
|
|
|
|
|
### Bit Stuffing
|
|
|
## Bit Stuffing
|
|
|
Bit stuffing is technique of adding extra bits to communication packet which does not carry any information but assists in management of communication. It is used to ensure synchronization of all nodes.
|
|
|
|
|
|
During the transmission of a message, a maximum of five consecutive bits may have the same polarity. the transmitter will add an additional bit of opposite polarity in to the bit stream before transmitting new bits.
|
... | ... | @@ -64,13 +59,13 @@ This technique is introduced in CAN because of Non Return to Zero(NRZ) coding sc |
|
|
Any node receiving a message that breaks the bit stuffing rules (more than five consecutive recessive or dominant bits in a sequence that should be bit stuffed) will detect this as a receive error and take action dependant on the node state (for example, transmit an active or passive error frame).
|
|
|
<BR/>
|
|
|
|
|
|
## Frame
|
|
|
# Frame
|
|
|
<todo>
|
|
|
|
|
|
### ACK bit
|
|
|
## ACK bit
|
|
|
The ACK bit is located between the CRC delimiter and the ACK delimiter in the CAN frame. The ACK bit is used by any nodes that receive a frame to indicate to the transmitter that it has been received successfully. When transmitting the frame the transmitter transmits a recessive signal (1) in the ACK bit, once a node successfully receives the data it transmits a dominant signal (0) at the ACK bit which overrides the transmitters recessive signal. This signals to the transmitter that the frame was received by at least one node. If you have multiple nodes the dominant signal will always override the recessive signal i.e. If you have two nodes and one signals a dominant ACK bit and the other a recessive ACK bit the dominant value will override the recessive. Thus, the transmitter has no way of knowing that all of the nodes have successfully received the frame. The transmitter will only know that at least 1 has or none of them have.
|
|
|
|
|
|
### Message ID based Arbitration
|
|
|
## Message ID based Arbitration
|
|
|
The message ID for a given can frame is also used as the priority of the message being sent. **A lower message ID has a higher priority**
|
|
|
because a logical `0` is a dominant signal and will override a logical `1`, which is recessive. When a device starts sending out a message it does so by transmitting one bit and then observing the bus to see if the same bit is being sent. If it observes that a different bit is sent it knows that a higher priority message won the arbitration process and it stops transmitting. For example, lets say two devices begin transmitting at the same time. Device 1 is sending a message with id: `0b11000101101` and device 2 is sending a message with id:
|
|
|
`0b11000001101`. The following transmission sequence will occur:
|
... | ... | @@ -84,7 +79,7 @@ because a logical `0` is a dominant signal and will override a logical `1`, whic |
|
|
|
|
|
As you can see above, device 2 won the arbitration process as it's message id is lower than the message id of device 1. Once device 1 did not see the bit that it sent on the bus it knew that it had lost the arbitration process and stopped sending bits altogether after sending bit 5.
|
|
|
|
|
|
### RTR
|
|
|
## RTR
|
|
|
Typically, messages are sent periodically, and asynchronously by the transmitters. In some cases however, a node might want to request data from the transmitter instead of the data being sent periodically. The node can do this by sending a remote frame to the transmitter which triggers the transmitter to send a data frame.
|
|
|
|
|
|
The remote frame and data frame differ in two ways:
|
... | ... | @@ -96,23 +91,23 @@ If a data frame and a remote frame are sent with the same message ID then the da |
|
|
|
|
|
<BR/>
|
|
|
|
|
|
## Errors
|
|
|
# Errors
|
|
|
|
|
|
CAN bus is fault tolerant and maintains a number of error counters for robust operation.
|
|
|
|
|
|
### Transmit Error Counters
|
|
|
## Transmit Error Counters
|
|
|
<todo>
|
|
|
|
|
|
### Receive Error Counters
|
|
|
## Receive Error Counters
|
|
|
<todo>
|
|
|
|
|
|
### Bus Off Conditions
|
|
|
## Bus Off Conditions
|
|
|
<todo>
|
|
|
|
|
|
|
|
|
<BR/>
|
|
|
|
|
|
## Applications
|
|
|
# Applications
|
|
|
* Automotive
|
|
|
* Trucking - J1939
|
|
|
* Industrial
|
... | ... | @@ -122,12 +117,12 @@ CAN bus is fault tolerant and maintains a number of error counters for robust op |
|
|
|
|
|
<BR/>
|
|
|
|
|
|
## DBC
|
|
|
# DBC
|
|
|
DBC file is a proprietary format that describes the data over a CAN bus. It is still less proprietary than developing your own standard hence is a good path for CAN applications. Furthermore, manufacturer's of sensors may just provide you the hardware and the DBC file to interface so it is a good format to use.
|
|
|
|
|
|
We will demonstrate the basic syntax of a DBC file that defines up to 8 bytes of CAN message data. A lot of CAN bus related tools can read the DBC file and display values next to each "signal" that you define in the DBC file.
|
|
|
|
|
|
### Message Format
|
|
|
## Message Format
|
|
|
DBC file must contain a Message ID (MID), and at least one signal. Let's demonstrate by showing a message that contains a single 8-bit signal. ```Spaces and the syntax is really strict```, so if you get a single space incorrect, the auto-generation script will likely fail.
|
|
|
|
|
|
**Example**
|
... | ... | @@ -148,7 +143,7 @@ Observations: |
|
|
* ```""```: There are no units. (it could be, for instance "inches")
|
|
|
* The receiver is ```DBG```.
|
|
|
|
|
|
### Signed and Unsigned Signals
|
|
|
## Signed and Unsigned Signals
|
|
|
A signed signal can be sent by simply applying a negative offset to a signal. Let's add a signed signal to the previous message.
|
|
|
|
|
|
**Example**
|
... | ... | @@ -161,7 +156,7 @@ BO_ 500 IO_DEBUG: 4 IO |
|
|
Observations
|
|
|
* ```@1-```: Defines that ```IO_DEBUG_test_signed``` signal is little-endian, and signed.
|
|
|
|
|
|
### Fractional Signals
|
|
|
## Fractional Signals
|
|
|
A floating point variable can be sent by deciding the range, and the precision that you require. For example, if we choose 8-bits, with ```0.1``` as a fraction, we can send the data range of ```0.0 -> 25.5```. On the other hand, if we want more precision and negative representation, we could use 12-bits with ```0.01``` as a fraction, and an offset. The second fractional signal also contains an explicit minimum and maximum, which is limited by 12-bit that can represent 4096 different numbers, and by factoring in the offset, and using half of the range for negative representation, it ends up with the limited range of ```-20.48 -> 20.47```.
|
|
|
|
|
|
```
|
... | ... | @@ -177,11 +172,11 @@ Observations |
|
|
* IO_DEBUG_test_float1: variable is calculated as ``` 0 + 0.1 * [raw value] ```.
|
|
|
* IO_DEBUG_test_float2: variable is calculated as ``` -20.48 + 0.01 * [raw value] ```.
|
|
|
|
|
|
### Little Endian Examples
|
|
|
## Little Endian Examples
|
|
|
|
|
|
Signals that are defined as Little Endian in the DBC are easier to edit manually without a UI based DBC editor. This is because when we indicate that an LSB of a signal is "4" and is a 14-bit signal, then it is easier to understand the bounds of this signals are `b17 ... b4`.
|
|
|
|
|
|
### Big Endian Examples
|
|
|
## Big Endian Examples
|
|
|
|
|
|
Big endian bits are not what they appear to be if you design the DBC manually. *It is relatively difficult to design a big endian DBC without a UI based editor*. Let us consider some examples:
|
|
|
|
... | ... | @@ -251,10 +246,10 @@ Signal Overlay (byte 0 is omitted): |
|
|
* `Start bit` = LSB bit = `7 - (offset % 8)` = 5
|
|
|
* `Start byte` = LSB byte = `offset // 8` = 3
|
|
|
|
|
|
### Multiplexed Signals
|
|
|
## Multiplexed Signals
|
|
|
<todo>
|
|
|
|
|
|
### Enumerations
|
|
|
## Enumerations
|
|
|
* Enumeration is a user defined data type. It is primarily used to assign labels to constants to make the logic easy to comprehend and maintain. Enumerated data types are data types consisting of a collection of values called enumerators. These values are comparable, but interpreters and compilers represent them arbitrarily, i.e., they do not have any specific representation in the memory. A variable that has been declared as having an enumerated type can have any of the enumerators as its value.
|
|
|
* Particularly, in a DBC file format, the user utilizes enumeration to be able to use names instead of numbers to represent states.
|
|
|
For example, in a traffic light state machine- the states '0', '1', '2' can be represented as "Red", "Yellow", and "Green" respectively.
|
... | ... | @@ -273,19 +268,19 @@ VAL_ 500 IO_DEBUG_test_enum 0 "Red" 1 "Yellow" 2 "Green"; |
|
|
```
|
|
|
|
|
|
|
|
|
### Miscellaneous
|
|
|
## Miscellaneous
|
|
|
Cycle time, initial values etc
|
|
|
|
|
|
|
|
|
<BR/>
|
|
|
|
|
|
## Typical CAN Driver
|
|
|
# Typical CAN Driver
|
|
|
<todo>
|
|
|
|
|
|
### CAN Frame Structure
|
|
|
## CAN Frame Structure
|
|
|
<todo>
|
|
|
|
|
|
### Bitrate Settings
|
|
|
## Bitrate Settings
|
|
|
|
|
|
A single bit is broken out into these separate time segments:
|
|
|
```
|
... | ... | @@ -311,44 +306,44 @@ ______________/\______|______|___________________________|_____________/\_______ |
|
|
* May be shortened or lengthened to help keep the clocks in sync
|
|
|
* The Sample Point taeks place between these 2 segments
|
|
|
|
|
|
#### Sample Point
|
|
|
## Sample Point
|
|
|
The sample point is the point where bus levels are sampled. This always takes place between Phase 1 and Phase 2 segments. A sample point of 75% is a common starting point, but busses with high baud rate may require a later sample point.
|
|
|
|
|
|
You should configure the clock prescaler driving your CAN peripheral, and your segment Tq registers such that you can achieve your desired sample point. To make this easier, there are many tools online to do these calculations:
|
|
|
|
|
|
[Bit Timing Calculator](#Bit-Time-Calculation)
|
|
|
|
|
|
#### Synchronization
|
|
|
## Synchronization
|
|
|
The CAN controller will lengthen or shorten a bit by a maximum number known as Synchronization Jump Width. The integer value of SJW represents Tq. This is typically fine left at default value.
|
|
|
|
|
|
### Mailboxes
|
|
|
## Mailboxes
|
|
|
<todo>
|
|
|
|
|
|
### Hardware Filters
|
|
|
## Hardware Filters
|
|
|
|
|
|
Filtering is a way to choose which messages to intercept from the CAN bus. The biggest confusion here is that as soon as your CAN is initialized, it will automatically **ACK the frames for ALL frames**. So just because you do not intercept a frame does not mean your CAN peripheral will not acknowledge.
|
|
|
|
|
|
### Listen-only mode
|
|
|
## Listen-only mode
|
|
|
<todo>
|
|
|
|
|
|
|
|
|
<BR/>
|
|
|
|
|
|
## CAN Tools
|
|
|
# CAN Tools
|
|
|
<todo>
|
|
|
|
|
|
### PCAN
|
|
|
## PCAN
|
|
|
|
|
|
### Bus Master
|
|
|
## Bus Master
|
|
|
|
|
|
### Vector
|
|
|
## Vector
|
|
|
|
|
|
|
|
|
<BR/>
|
|
|
|
|
|
## References
|
|
|
# References
|
|
|
|
|
|
### [Cantools](https://github.com/eerimoq/cantools)
|
|
|
## [Cantools](https://github.com/eerimoq/cantools)
|
|
|
|
|
|
Cantools is an awesome Python tool with so many features such as:
|
|
|
|
... | ... | @@ -358,6 +353,6 @@ Cantools is an awesome Python tool with so many features such as: |
|
|
|
|
|
We used it to generate the signal overlay of the CAN bytes, using the command `cantools dump your.dbc`. It is *very well written* and highly recommended than writing your own DBC parser.
|
|
|
|
|
|
### [Bit Time Calculation](http://www.bittiming.can-wiki.info/)
|
|
|
## [Bit Time Calculation](http://www.bittiming.can-wiki.info/)
|
|
|
|
|
|
This article can be used to calculate the baud-rate register settings for various different CAN peripherals. |
|
|
\ No newline at end of file |