Software Products
CANopen Software
CANopen software has a small ROM/RAM footprint and supports multiple CAN channels with a maximum of 512 TPDOs and RPDOs. Also supported are expedited SDO transfers, NMT messages, heartbeat producing, and PDO event/inhibit timers. Simma Software’s protocol stacks, device drivers, and bootloaders have been used in more than a million embedded systems, by ever major automotive OEM, and in more than 200 real-time designs.
CANopen Software Protocol Stack Details
Table of Contents
- MISRA C compliant
- ANSI C source code
- Use with or without an RTOS
- Use with 8, 16, 32, or 64-bit CPU
- Use with Flash Bootloader to update product
- CANopen user’s reference manual
9x
lower CPU cycles per message
Approx. for C2000 CPU
2x
smaller
code size
Approx. for C2000 CPU
CANopen
Introduction
This article is intended to give engineers a brief overview of the CANopen protocol, which is specified by CiA 301 and maintained by CAN in Automation. For details on the specification itself, please visit CAN in Automation (CiA). Here is a printable version of this CANopen Introduction.
CANopen is a real-time protocol used in automation, automotive, and medical equipment. CANopen handles the data link, transport protocol, network management, and application layers. Typically CANopen uses CAN as the physical layer with baud rates ranging from 125 Kbps to 1 Mbps.
Several different application layers exist and are known as device profiles. For example, CiA 401 defines the application layer (i.e. device profile) for a generic I/O device while CiA 402 defines operation for servo drives, frequency inverters and stepper motors. Altogether there are more than 50 separate and defined device profiles.
Overview
The standard goes on to define many other aspects, including message timeouts, how large messages are fragmented and reassembled, the network speed, the physical layer, and the node ID.
Object
Dictionary
At the heart of CANopen is the Object Dictionary (OD), which all nodes must contain. An OD contains all setup and configuration items for a node. It is standard for a CANopen protocol stack to provide a configurable OD. The OD is normally implemented, via CANopen software, as an array of objects. Per the spec, each object has an assigned 16-bit index and 8-bit sub-index. This allows for up to 255 sub-entries at each index.
All data is stored as entries in pre-defined locations of the object dictionary. An entries index and sub-index is listed in CiA 301 and it’s corresponding device profile. An OD entry has an index, object name, description, type, attribute, and optional field.
Process Data Object
(PDO)
A Process Data Object protocol is used to transmit information in an efficient manner with little overhead. Since PDOs are lightweight, CANopen uses them to transmit real-time diagnostic and control information. All PDOs are single frame, which means that a node can transfer up to 8 bytes of data per PDO. However, a single PDO can contain multiple data objects. Multiple objects inside of a single PDO are mapped via the object dictionary.
There are two kinds of PDOs: receive and transmit PDOs (RPDO and TPDO). A RPDO is used when a node needs to receive data (i.e. read data) and a TPDO is used when a node needs to transmit data (i.e. write data). CiA 301 defines eight identifiers, four for RPDOs and four for TPDOs. PDOs are transmitted periodically, by an external event, or when used the nodes receives a SYNC message. PDOs that are transmitted on the reception of a SYNC PDO are known as synchronous PDOs, while periodic PDOs are known as asynchronous.
Service Data Object
(SDO)
An SDO, service data object, is used to read and write values inside of an object dictionary. CANopen defines a write into an OD as an SDO download and a read from an OD as an SDO upload. Since SDOs can be larger than a single frame (i.e. 8 bytes), SDO implementations require fragmentation and reassembly (i.e. transport protocol).
An example of an SDO read is when a node requests the manufacturer device name and/or device type of another node.
CANopen
Ports
Our real-time CANopen protocol stack is completely platform independent and written in the ANSI C programming language. It is the CAN device driver, ssCAN, that is target specific and incorporates the details for a given microcontroller.
Together ssCANopen and ssCAN form a complete ported system allowing customers to be up and running almost immediately. Our ssCAN device driver has been ported to over 40 different microcontrollers.
See our full list of available ports.
Texas Instruments
- RM4x (DCAN)
- LM3Sx
- TMS470x
- TMS470Mx
- TMS570x
- Tiva TM4C
- F28M35xx
- TMS320F280x
- TMS320F281x
- TMS320F282x
- TMS320F283x
- AM3x – Sitara
- DM8x – DaVinci
- MSPM0
- MSPM0G
Microchip
- PIC18
- PIC24
- PIC32
- dsPIC30
- dsPIC33
- MCP2515
Freescale
- HCS08
- HCS12
- HCS12X
- MC68xxx
- MCF5xxx
- MPC5xxx
- Kinetis Kxx
STMicro
- ST7
- ST10
- STM8
- STR7
- STM32F1x
- STM32F2x
- STM32F3x
- STM32F4x
NXP
- LPC11xx
- LPC17xx
- LPC21xx
- LPC23xx
- SJA1000
Miscellaneous
- Amtel – SAM7 & AT90
- Intel – 82527
- Silicon Labs – C8051
- Infineon – C16x & TriCore
- Xilinux – LogiCORE AXI (axi_can)
- Windows 7/XP/Embedded
- Linux
Talk to us about CANopen needs
Please contact us if you are interested in a port or device driver for a hardware platform that is not listed.
Experience Summary
1000
Global
Customers
500
Protocol
Stacks
300
CAN
Device Drivers
75
Flash
Bootloaders
60
Microcontrollers
& DSPs
10
Real Time Operating Systems
Our Customers
Our Partners
