Software Products

CANopen Software

Our CANopen protocol stack provides a simple application program interface (API) for sending and receiving CANopen messages. Our CANopen protocol stack software abstracts away the technical details and many complexities associated with message timing and interfacing to the CANopen networks.

This increases the simplicity of your application software, improves your reliability, and shortens your product’s time to market.

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

  • 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

Quick Links

CANopen Bootloader

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

CANopen is a high level communications protocol, which operates on a Controller Area Network (CAN) bus. CiA 301 combined with a device profile (e.g. CiA 401) form a complete specification which specifies exactly how information (e.g. servo motor RPM) is exchanged between electronic control units (ECUs).
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

Customer Logos

Our Partners

TI Partner Logo Infineon Partner Logo Microchip Partner Logo ST Partner Logo NXP Partner Logo
0
    0
    Your Cart
    Your cart is emptyReturn to Store