The CAN standard, popular in automotive applications, defines a simple broadcast serial network that works well for real-time short range communications. But there are few rules at the upper layers. Here's an easy way to keep proprietary application-layer CAN protocols compatible with an open standard.
With more and more microcontrollers including controller area network (CAN) interfaces on chip, such networks are softening the prejudice that CAN is primarily an automotive network. CAN has a way to go before it's “developer-friendly.” In this article, you'll learn some of the pitfalls and trade-offs of using full versions of application layers on top of CAN and the advantages of starting off “small” with MicroCANopen.
No CAN do?
Although CAN provides a reliable communication channel, the application developer still must perform a substantial network design to make a CAN application work. Many details are left to the higher-layer (or sometimes application-layer) CAN protocol of the application developer's choosing.
For example, while CAN messages have an identifier field (CAN-ID) and a data field of up to 8 bytes, it's not specified when and how to use that identifier. The endianness of the data field is also left unspecified, an ambiguity that may lead one system when communicating multibyte words to assume that the LSB comes first, while another system assumes the MSB comes first.
Several standardized higher-layer CAN protocols are available, such as CANKingdom, CANopen, DeviceNet, J1939, and Smart Distributed System. Most of these protocols were designed for specific applications, including use in trucks or industrial automation.
When implementing a CAN-based application, developers have to make a choice to either use an existing, standardized higher-layer CAN protocol or invent a proprietary protocol. Developers working on systems consisting of only a few nodes and a few network variables fear that a higher-layer CAN protocol is overkill and has a large learning curve. On the other hand, developing and maintaining an inhouse standard can be expensive, especially considering the lack of development tools. Many monitors, analyzers, configurators, and other tools available support the standardized higher-layer protocols.
For embedded applications that don't require all the functionality of a “full-grown” higher-layer CAN protocol, CANopen is a popular choice. One of the strongest features of CANopen is the “openness,” which enables you to implement only the functionality required by your particular application. You can even customize and optimize the communication to your needs.
For those engineers who aren't yet ready to use CANopen proper, the alternative is MicroCANopen. MicroCANopen isn't an existing standardit's a concept. With MicroCANopen, you don't shoot for full CANopen compliance; you just adopt the basic ideas of CANopen to your own network layout to get a quick start. If your design requires more complex CANopen features (or full compliance) in the future, you won't need to reinvent your system as the basics are already in place and compatible.
MicroCANopen is an “entry-level” alternative to CANopen that works well in systems with embedded applications with limited resources. Code and data sizes depend on your microcontroller and the functionality you want. On an 8051 with on-chip CAN interface, MicroCANopen requires as little as 4KB of code and some 200 bytes of RAM; compare this to the 50KB or more of code and 1KB of RAM for “full-featured” CANopen implementations.
Table 1: Comparison of CANopen and MicroCANopen features
|Data rates (bps)||10k, 20k, 50k, 125k, 250k, 500k, 800k, 1M||Same|
|Max. nodes per segment||127||Same|
|Network management||Typically using a master/manager||No master or manager required|
|Node guarding/heartbeat||Node guarding done by master or heartbeat monitoring by any node||All nodes produce heartbeat, can be monitored by communication partners|
|Configuration of nodes||Nodes can typically be configured via the network||Nodes are preconfigured, configuration cannot change during operation|
|Available, optional with ASCII string||Available,
32-bit IDs only
Process data variables
|Available, often with multiple access (8/16 bit)||Not available in OD, only in process data messages|
Process data configuration
Support of long variables
|Supports variables and data fields of any length||A single OD entry may not be longer than 4 bytes|
|Mapping of multiple variables into one CAN message||Supports dynamic remapping of variables into CAN messages||One fixed, preconfigured mapping|
|Triggering methods of CAN messages with process data||Any combination of time-based, polled, change-of-state, synchronized, or manufacturer specific. Inhibit time supported.||Time-based and/or change-of-state only. Inhibit time supported.|
Table 1 compares the features of MicroCANopen and CANopen. Code examples for MicroCANopen are available at www.microcanopen.com.
To implement a minimal CANopen-like system, we need to address a few basic parameters and limitations. Note that some items aren't necessarily limitations of CANopen, but compromises we made to achieve this “minimal” version of CANopen.
Baud rate/bit timing: All network nodes start up with the same CAN bus baud rate. The baud rate used in one system/application may be 10kbps, 20kbps, 50kbps, 125kkbps, 250kbps, 500kbps, 800kbps, or 1Mbps.
Node-ID: Each network node has a unique Node-ID, and this ID is in the range of 1 to 127, allowing for a total of 127 nodes in the system. This ID must be assigned and known to each node before it gets onto the live network.
Byte ordering: In multibyte variables, the bytes are ordered by significancelowest significant byte comes first.
Process data variables: Each variable shared via the network can contain 1 to 4 bytes. Note that multiple variables can go into a single CAN message.
Network management (NMT) master: A regular CANopen network would expect the presence of a CANopen NMT master to actually start and monitor the nodes. In deeply embedded applications where all nodes are preconfigured and know what they need to do, a master might not be required. In MicroCANopen we assume that no master is present and that all nodes startup automatically after power-up.
PDO and SDO communication: The major CANopen communication types PDO (Process Data Object) and SDO (Service Data Object) are both supported. An SDO channel is used by a configuration tool or master for point-to-point communication of configuration data. The PDO channels contain process data and can be sent from one node in the network to multple nodes in the network (one-to-many, multicast).
Each MicroCANopen node implements a minimal CANopen Object Dictionary. The Object Dictionary (OD) of a regular CANopen implementation holds all network variables that a node needs to receive or transmit. Each entry implemented has a unique 16-bit index and 8-bit sub-index value that identifies one network variable in this CANopen node. Note: this identifier is different from the CAN-ID, which identifies a unique message on the bus.
Table 2: CANopen Object Dictionary entries implemented by MicroCANopen
|1000h||00h||32-bit device type information, typically set to “generic I/O”|
|1001h||00h||8-bit error register|
|1018h||00h||8-bit entry of “4”number of subindexes in this record|
|1018h||01h||32-bit vendor ID|
|1018h||02h||32-bit product code|
|1018h||03h||32-bit revision number|
|1018h||04h||32-bit serial number (optional)|
In MicroCANopen only the OD entries listed in Table 2 are implemented. The process data variables aren't implemented in the OD; they're only available via the process data messages listed further below.
The main function of any CANopen implementation is to receive and transmit messages. MicroCANopen nodes produce and consume the following CAN messages:
- Upon startup, each MicroCANopen node transmits a boot-up message and continues to regularly transmit a heartbeat message in the specified heartbeat time interval. Other nodes can take this as an indication of the current status of the transmitting node.
- Read accesses to the OD are accepted and replied to. This enables standardized CANopen configuration tools or NMT to recognize a MicroCANopen node.
- Up to four separate transmit messages with process data can be triggered individually by a timer (every n milliseconds) or automatically by a detected change-of-state (COS) in the data to be transmitted.
- Up to four separate receive messages with process data can be received.
MicroCANopen and CANopen both require the use of a CAN 2.0A-compliant physical interface, which has an 11-bit identifier field. The message identifiers used in the system are assigned in accordance to the CANopen predefined connection set, which embeds the node ID number into the identifier field. To transmit, a MicroCANopen node uses the CAN-IDs specified in Table 3. For example, the node with ID 3 would use CAN-ID 0x703 to transmit its boot-up message.
Table 3: Message identifiers used to transmit
|CAN-ID||Used for transmitting|
|0x080 + Node-ID||Emergency Message (optional)|
|0x180 + Node-ID||Transmit Process Data Message 1 (TPDO1)|
|0x280 + Node-ID||Transmit Process Data Message 2 (TPDO2)|
|0x380 + Node-ID||Transmit Process Data Message 3 (TPDO3)|
|0x480 + Node-ID||Transmit Process Data Message 4 (TPDO4)|
|0x580 + Node-ID||Service Data Response (SDO tx)|
|0x700 + Node-ID||Boot-up message and heartbeat|
Table 4: Message identifiers used to receive
|CAN-ID||Used for receiving|
|0x000||Network Management Master Message (NMT)|
|* 0x200 + Node-ID||Receive Process Data Message 1 (RPDO1)|
|* 0x300 + Node-ID||Receive Process Data Message 2 (RPDO2)|
|* 0x400 + Node-ID||Receive Process Data Message 3 (RPDO3)|
|* 0x500 + Node-ID||Receive Process Data Message 4 (RPDO4)|
|0x600 + Node-ID||Service Data Request (SDO rx)|
Table 4 shows the CAN-IDs a MicroCANopen node listens for. The entries marked with “*” can be customized to ensure that a node directly listens to the process data message it needs to receive. So if we want the RPDO2 of node 5 to directly consume TPDO1 of node 8, the CAN-ID listened to would need to be changed from 0x305 (default receive ID for RPDO2 of node 5) to 0x188 (transmit ID for TPDO1 of node 8)
A CANopen Network Management Master or generic configuration tool would access a single node by using the appropriate SDO channel. A channel consists of two messages, one used for the SDO request from the configuration tool to the node and one used for the SDO response from the node back to the requester. To access node 3, a configuration tool would use CAN-ID 0x603 and would expect a response coming back using CAN-ID 0x583.
Figure 1: Vector CANalyzer trace recording of power-up cycle
Figure 1 shows a screenshot of a trace window with CANopen messages. The trace recoding was made with Vector's CANalyzer and shows the power-up cycle of MicroCANopen node 3. After transmitting the boot-up message, node 3 starts transmitting its heartbeat about every 2.5 seconds.
After receipt of the NMT master message “Start Node,” the MicroCANopen node starts transmitting the process data messages with the IDs 0x183 and 0x283.
Figure 2: A possible mapping of variables into the 8 data bytes of a CAN message
Now that the CAN identifiers are assigned, let's look at the required message contents. The PDO messages are the easiest, as you may simply fill them with one or multiple variables. Figure 2 shows how the 8 bytes of a CAN message could be used in a PDO: Bytes 1 and 2 contain the 8-bit variables A and B. Bytes 3 and 4 are used for the 16-bit variable C and bytes 5 and 6 are used for variable D. Bytes 7 and 8 remain unused and aren't transmitted.
In CANopen, many message types and conditions can trigger the transmittal of a message. To achieve our minimal MicroCANopen implementation, though, we limited ourselves to the messages related to boot-up/heartbeat, service data, and process data:
Boot-up and heartbeat message: As soon as the internal initialization is completed, our MicroCANopen nodes transmit their boot-up message followed by a continuous heartbeat. The heartbeat frequency is configurable and is typically in the area of hundreds of milliseconds to seconds, depending on application requirements. The timer resolution is 1ms.
Service data: A master or configuration tool initiates any SDO communication. The MicroCANopen nodes may not trigger SDO communication by themselves, only in response to a request. Any SDO request directed at a node requires a response: either the correct SDO response or an appropriate abort message.
Process data: CANopen supports a multitude of triggering mechanisms for the transmittal of PDO messages containing the process data. Out of the available mechanisms MicroCANopen nodes support event-timer transmission and event-change (or change of state [COS]) transmission. In event timer mode a PDO is transmitted every n milliseconds. In event change mode, the PDO is transmitted whenever a change of state in any of the data to be transmitted is detected.
To prevent a high-frequency change of state from continually triggering data messages, the MicroCANopen nodes support the inhibit time feature of CANopen. An interval timer prohibits a change of state PDO from being transmitted again until at least a minimum period of time has elapsed.
In MicroCANopen, we have to deal with two software communication interfaces: a CAN driver that provides us with some minimal functionality to receive and transmit CAN messages and a user interface for the application.
Hardware driver interface
Due to the major differences in the implementations of CAN controllers, portability to different microcontrollers isn't easy. For this implementation, we simply assume that the drivers are taking care of all real-time issues including the CAN interrupt service routine and provide both a receive and a transmit queue. In order to avoid making the CANopen communication a high priority within the embedded system, MicroCANopen is implemented as a background task that can be called from main.
Listing 1 shows the driver functions required by MicroCANopen. You need the first two functions for initialization of the hardware. In addition, the driver must implement some sort of receive and transmit queue for messages. These queues are accessed by the PullMessage and PushMessage functions.
Listing 2 shows the functions provided for the application interface. The ProcessStack must be called frequently as background task (for instance calling it from the while(1) loop in main). The only messages made transparent to the application are those with process data. All service messages are handled within ProcessStack without additional interfacing to the application. The ReceivedPDO function is a call-back function. This means it must be implemented by the user/application. The ReceivedPDO gets called from within the stack whenever new process data arrives. The default states that this function is called from within ProcessStac kmeaning that an unpredictable delay occurs from the time a message arrives until this function actually gets called.
Experienced users facing tougher real-time requirements can modify the code and call this function from within the interrupt service routine (ISR) receiving the CAN messages. However, in this case you should ensure that the code executed within the call-back function is absolutely minimal as it will add to the execution time of the ISR.
Debugging and testing
Several tools are available for debugging and testing CANopen nodes. Besides monitor and analysis tools, CANopen-specific tools to maintain and access the Object Dictionary are very helpful. CANeds, from Vector, is a helpful editor for CANopen electronic data sheets and device configuration files (EDS, DCF). These files specify which OD entries are implemented by a particular node. Configuration tools, analysis tools or NMT master implementations can use this information to directly access the OD entries of that particular node.
The communication implemented within MicroCANopen allows the sharing of process data among several CAN nodes in a CANopen manner. Data can be transmitted on a preset frequency (say every n milliseconds) or on change of state. MicroCANopen is compatible enough with the standard CANopen protocols that you can use off-the-shelf CANopen configuration tools, monitors/analyzers, and master implementations with it.
Olaf Pfeiffer holds a degree in computer science from the Co-Operative University Karlsruhe, Germany. His publications include multiple articles and the book Embedded Networking with CAN and CANopen. Olaf regularly conducts training classes through the Embedded Systems Academy. Contact him at .
Home of MicroCANopen and PCANopenMagic: http://www.microcanopen.com
The CAN in Automation web pages on CANopen: http://www.canopen.org/canopen
CANopen introductory pages: http://www.canopen.us
Commercial CANopen solutions: http://www.vector-cantech.com