Using CAN network and CANopen stack
One day, I was faced with the task of developing an embedded system in which data could be transferred between nodes with maximum reliability. It was then that I first learned about CAN.
In this article I would like to talk briefly about what CAN is and about my experience with it. Perhaps people who are engaged in the development of embedded systems, after reading my article, will be interested in this standard, if it has not yet come into their field of vision. Moreover, the CAN controllers are currently present on many microcontrollers.
CAN (Controller Area Network) is a standard created by Bosch for networks used in automation and industry. The standard is widely used in industrial production, technologies of "smart home", as well as in the automotive industry. Very well suited for linking various sensors and control devices into a single network.
As a rule, a CAN network is a bus network in which all nodes can transmit and receive data.
It has low speed, but high reliability.
')
Next, I want to superficially describe the standard and talk about the use of such a network in practice.
The standard describes the data link layer and the basic requirements for the physical layer.
The main thing in the physical layer is the requirement of the possibility of transmitting a bit as “ dominant ” and “ recessive ”. The dominant signal is considered a unit, and the recessive signal is zero. The main requirement is that when transmitting a dominant and recessive signal at the same time, a dominant signal must come to all nodes. The arbitration mechanism is based on this principle. From this it follows that different media can be used for transmission, but in practice the differential pair is most often used.
Transmission to the network occurs in frames. There are two types of frames in the standard: basic and advanced.
The base frame contains 11 bit identifier, and the extended frame contains 29 bit. A frame also contains a bit of a request for transmission, information about the length of the transmitted data and the data itself. They can take from 0 to 8 bytes per frame. The same frame contains some service information, but for the programmer it is not critical, since its addition is implemented by hardware in the network controller.
Initially, identifiers are not tied to any node and characterize the message, not the sender and recipient. The identifiers also show the priority of the message. The priority is determined by the dominant bits in the identifier. So 10000000000 more priority than 01000000000.
The main advantage of CAN is its reliability. It uses the collision resolution mechanism (as opposed to the collision detection mechanism in Ethernet), which allows not to lose bandwidth due to collisions.
Its essence lies in the fact that each node listens to the network and, if it is free, can start the transmission. At the same time, he continues to listen to the network. If the sending of the recessive bit is assumed to be dominant, it means that simultaneously with this node another node with higher priority has started to transmit. In this case, the transfer is terminated.
In addition, error detection mechanisms are used, such as transmission controls, padding bits, using checksums and checking field values. Developers estimate the probability of not detecting a transmission error as 4.7 Ă— 10-11.
This standard does not describe top-level protocols, so several implementations, both commercial and open, were created.
The most famous of them are:
- CANopen
- DeviceNet
- CAN Kingdom
This and even more detailed information about the standard is easy to find on the Internet, so I finally proceed to the description of CANopen.
As I already wrote, once I needed to create a reliable network of microcontrollers. After considering possible options, it was decided to stop at the CAN network. CANopen was selected as the top-level protocol and its implementation is CANopenNode, since it is open and easy to port to the device I need. CANopenNode is licensed under the LGPL.
Highlights of the CANopen protocol:
- the protocol works with standard identifiers. The network can contain up to 127 nodes.
- each node is given a unique number in the network.
- the protocol does not require the presence of a network master (however, there are opportunities that are available only to one node on the network, which can be called a master conditionally)
- OD (Object Dictionary) - Object Dictionary. Contains a sorted list of variables that can be accessed over the network using SDO.
- SDO (Service Data Objects) - access mechanism to the dictionary of objects. To access host objects, a so-called SDO server must be running on this host. There can be only one SDO client on the network, conventionally called a wizard, which can receive data from any of the servers.
- PDO (Process Data Objects) - objects for fast interaction between nodes. They can contain up to 8 bytes of data and are transmitted in one frame. Each PDO is allocated its own identifier (in a specific range). PDOs are conventionally divided into incoming (RPDO) and outgoing (TPDO). Initially it is assumed that each node will have 4 RPDO and 4 TPDO, but they can be redistributed between nodes, to the extent that one node will be able to receive and transmit up to 512 PDOs. However, in this case there will not be enough identifiers for other nodes.
PDOs can be sent by timer, upon the occurrence of a specific event or by direct request for a parcel from the control program.
- NMT (Network Management) - network manager. Messages of this type can translate nodes into different states (initialization, working, pre-work, stopped), as well as with their help control of the network is provided - the heartbeat mechanism.
- Heartbeat - translated as a heartbeat. The essence of the mechanism lies in the fact that each node transmits a specific message to the network, unique for each node (ID is obtained by adding the node number in the network to a certain number). Any node that wants to know if it still has nodes with certain id should simply receive and process these messages. Messages from uninteresting nodes can be ignored.
- Emergency message - the protocol provides for sending emergency messages.
- EDS (Electronic Data Sheets) - special text files that allow you to customize the dictionary of objects. There are programs that help in the generation of such files.
CANopenNode is an open implementation of the CANopen protocol written in pure C for use in microcontrollers.
Now I will describe the features that I had to deal with when working with CANopenNode.
1. I used a 32-bit controller, and CANopenNode was originally written for 8/16 bit. Because of this, the timer went crazy in one place, because instead of overflowing and, as a result, resetting, it continued to grow and in the heartbeat mechanism there was an error stating that all the nodes exceeded the waiting time for the new heartbit.
2. My task was to transfer large amounts of data. However, several controllers could transmit this data, and the rest - to receive. I had to abandon the SDO mechanism (since there is only one controller in it that would be able to send data with a size greater than 8 bytes) and write its own add-in that used the first two bytes of the PDO as control information.
3. The decision from point two led to the fact that I needed to unambiguously identify the participants of the interaction, which can only be done using identifiers.
This was perhaps the most subtle point in the work. It was decided to limit the number of "masters" to four pieces. These four nodes received 127 PDOs at the input and at the output. The remaining nodes worked with 4 incoming and outgoing PDOs. Moreover, PDO identifiers were distributed in such a way that the “slave” nodes had one outgoing message, each of which read only a certain “master” and one incoming message from each “master”. The masters, respectively, had one channel for addressing personally any of the “slaves” and knew exactly which of them were accessing it.
This concept was the most difficult, because even in forums where people work with CAN, there is a perception that CANopen cannot be configured in this way.
4. The configuration of identifiers in this protocol occurs in the code. Moreover, the id of the nodes that will be read and received by a particular node depends on it. Therefore, changing the id on the move is difficult for this protocol and requires additional efforts.
In the end, I came to the conclusion that this protocol does not quite fit well with my task and that I will have to write my implementation. However, in the time I spent dealing with this protocol, I understood the principles of working with the CAN network much better. If you need to quickly get a working application that takes full advantage of reliable delivery, if you want your application to be compatible with many existing systems, if you need ready-made debugging tools for the CAN network, then CANopen is a very good choice.
I will be happy to answer any questions, accept criticism and additions, and I can also dwell on some points in more detail if anyone is interested.
Thank you for attention!
www.can-cia.org - (eng.) international organization CAN in Automation.
sourceforge.net/projects/canopennode - (eng.) project CANopenNode
UPD:
I forgot to add another interesting point that for some time misled me. I debug my network on two controllers that I connected directly.
1. When I reflashed one of the controllers, the network on the second started to generate errors (light bulbs began to flash often and often - the behavior defined in the CANopen stack). With a normal controller reset, this did not happen. Perhaps this is the specificity of a particular controller, but just in case it is worth bearing in mind.
2. The CANopen protocol is designed in such a way that if a message with a specific id was not sent before it should be sent again, this also causes an error. At the same time, every node of the network sends a hartbeat message every second. Therefore, even if you do not send anything, you can still get a network error.
In this article I would like to talk briefly about what CAN is and about my experience with it. Perhaps people who are engaged in the development of embedded systems, after reading my article, will be interested in this standard, if it has not yet come into their field of vision. Moreover, the CAN controllers are currently present on many microcontrollers.
CAN (Controller Area Network) is a standard created by Bosch for networks used in automation and industry. The standard is widely used in industrial production, technologies of "smart home", as well as in the automotive industry. Very well suited for linking various sensors and control devices into a single network.
As a rule, a CAN network is a bus network in which all nodes can transmit and receive data.
It has low speed, but high reliability.
')
Next, I want to superficially describe the standard and talk about the use of such a network in practice.
Standard
The standard describes the data link layer and the basic requirements for the physical layer.
The main thing in the physical layer is the requirement of the possibility of transmitting a bit as “ dominant ” and “ recessive ”. The dominant signal is considered a unit, and the recessive signal is zero. The main requirement is that when transmitting a dominant and recessive signal at the same time, a dominant signal must come to all nodes. The arbitration mechanism is based on this principle. From this it follows that different media can be used for transmission, but in practice the differential pair is most often used.
Transmission to the network occurs in frames. There are two types of frames in the standard: basic and advanced.
The base frame contains 11 bit identifier, and the extended frame contains 29 bit. A frame also contains a bit of a request for transmission, information about the length of the transmitted data and the data itself. They can take from 0 to 8 bytes per frame. The same frame contains some service information, but for the programmer it is not critical, since its addition is implemented by hardware in the network controller.
Initially, identifiers are not tied to any node and characterize the message, not the sender and recipient. The identifiers also show the priority of the message. The priority is determined by the dominant bits in the identifier. So 10000000000 more priority than 01000000000.
The main advantage of CAN is its reliability. It uses the collision resolution mechanism (as opposed to the collision detection mechanism in Ethernet), which allows not to lose bandwidth due to collisions.
Its essence lies in the fact that each node listens to the network and, if it is free, can start the transmission. At the same time, he continues to listen to the network. If the sending of the recessive bit is assumed to be dominant, it means that simultaneously with this node another node with higher priority has started to transmit. In this case, the transfer is terminated.
In addition, error detection mechanisms are used, such as transmission controls, padding bits, using checksums and checking field values. Developers estimate the probability of not detecting a transmission error as 4.7 Ă— 10-11.
This standard does not describe top-level protocols, so several implementations, both commercial and open, were created.
The most famous of them are:
- CANopen
- DeviceNet
- CAN Kingdom
This and even more detailed information about the standard is easy to find on the Internet, so I finally proceed to the description of CANopen.
Canopen
As I already wrote, once I needed to create a reliable network of microcontrollers. After considering possible options, it was decided to stop at the CAN network. CANopen was selected as the top-level protocol and its implementation is CANopenNode, since it is open and easy to port to the device I need. CANopenNode is licensed under the LGPL.
Highlights of the CANopen protocol:
- the protocol works with standard identifiers. The network can contain up to 127 nodes.
- each node is given a unique number in the network.
- the protocol does not require the presence of a network master (however, there are opportunities that are available only to one node on the network, which can be called a master conditionally)
- OD (Object Dictionary) - Object Dictionary. Contains a sorted list of variables that can be accessed over the network using SDO.
- SDO (Service Data Objects) - access mechanism to the dictionary of objects. To access host objects, a so-called SDO server must be running on this host. There can be only one SDO client on the network, conventionally called a wizard, which can receive data from any of the servers.
- PDO (Process Data Objects) - objects for fast interaction between nodes. They can contain up to 8 bytes of data and are transmitted in one frame. Each PDO is allocated its own identifier (in a specific range). PDOs are conventionally divided into incoming (RPDO) and outgoing (TPDO). Initially it is assumed that each node will have 4 RPDO and 4 TPDO, but they can be redistributed between nodes, to the extent that one node will be able to receive and transmit up to 512 PDOs. However, in this case there will not be enough identifiers for other nodes.
PDOs can be sent by timer, upon the occurrence of a specific event or by direct request for a parcel from the control program.
- NMT (Network Management) - network manager. Messages of this type can translate nodes into different states (initialization, working, pre-work, stopped), as well as with their help control of the network is provided - the heartbeat mechanism.
- Heartbeat - translated as a heartbeat. The essence of the mechanism lies in the fact that each node transmits a specific message to the network, unique for each node (ID is obtained by adding the node number in the network to a certain number). Any node that wants to know if it still has nodes with certain id should simply receive and process these messages. Messages from uninteresting nodes can be ignored.
- Emergency message - the protocol provides for sending emergency messages.
- EDS (Electronic Data Sheets) - special text files that allow you to customize the dictionary of objects. There are programs that help in the generation of such files.
CANopenNode
CANopenNode is an open implementation of the CANopen protocol written in pure C for use in microcontrollers.
Now I will describe the features that I had to deal with when working with CANopenNode.
1. I used a 32-bit controller, and CANopenNode was originally written for 8/16 bit. Because of this, the timer went crazy in one place, because instead of overflowing and, as a result, resetting, it continued to grow and in the heartbeat mechanism there was an error stating that all the nodes exceeded the waiting time for the new heartbit.
2. My task was to transfer large amounts of data. However, several controllers could transmit this data, and the rest - to receive. I had to abandon the SDO mechanism (since there is only one controller in it that would be able to send data with a size greater than 8 bytes) and write its own add-in that used the first two bytes of the PDO as control information.
3. The decision from point two led to the fact that I needed to unambiguously identify the participants of the interaction, which can only be done using identifiers.
This was perhaps the most subtle point in the work. It was decided to limit the number of "masters" to four pieces. These four nodes received 127 PDOs at the input and at the output. The remaining nodes worked with 4 incoming and outgoing PDOs. Moreover, PDO identifiers were distributed in such a way that the “slave” nodes had one outgoing message, each of which read only a certain “master” and one incoming message from each “master”. The masters, respectively, had one channel for addressing personally any of the “slaves” and knew exactly which of them were accessing it.
This concept was the most difficult, because even in forums where people work with CAN, there is a perception that CANopen cannot be configured in this way.
4. The configuration of identifiers in this protocol occurs in the code. Moreover, the id of the nodes that will be read and received by a particular node depends on it. Therefore, changing the id on the move is difficult for this protocol and requires additional efforts.
In conclusion
In the end, I came to the conclusion that this protocol does not quite fit well with my task and that I will have to write my implementation. However, in the time I spent dealing with this protocol, I understood the principles of working with the CAN network much better. If you need to quickly get a working application that takes full advantage of reliable delivery, if you want your application to be compatible with many existing systems, if you need ready-made debugging tools for the CAN network, then CANopen is a very good choice.
I will be happy to answer any questions, accept criticism and additions, and I can also dwell on some points in more detail if anyone is interested.
Thank you for attention!
Links to some resources related to CAN
www.can-cia.org - (eng.) international organization CAN in Automation.
sourceforge.net/projects/canopennode - (eng.) project CANopenNode
UPD:
I forgot to add another interesting point that for some time misled me. I debug my network on two controllers that I connected directly.
1. When I reflashed one of the controllers, the network on the second started to generate errors (light bulbs began to flash often and often - the behavior defined in the CANopen stack). With a normal controller reset, this did not happen. Perhaps this is the specificity of a particular controller, but just in case it is worth bearing in mind.
2. The CANopen protocol is designed in such a way that if a message with a specific id was not sent before it should be sent again, this also causes an error. At the same time, every node of the network sends a hartbeat message every second. Therefore, even if you do not send anything, you can still get a network error.
Source: https://habr.com/ru/post/144435/
All Articles