CAN Bus Definition

CAN Usage Background

CAN is the most universal technical topic discussed on EVT. Using CAN properly requires coordination between the Electrical, Firmware, and Integration sub-teams. Electrical engineers are responsible are responsible for ensuring the hardware is designed properly to support the CAN bus physical standard. As firmware engineers, we implement software to use that hardware for inter-board communication and sometimes follow the CANopen standard. Integration engineers then attempt to combine multiple boards, often needing to debug communications hardware and software to get the bike to operate properly.

When this many people are touching a single thing, a lot of questions start to come up about what data should be sent, what ID boards should have, and other similar details. While these often aren't difficult questions to answer, everyone needs to agree on the answer, or the team's boards won't be able to communicate. To ensure we're able to coordinate the team's approach to CAN, our team uses Electronic Datasheet (EDS) and CAN Database (DBC) files.

EDS files are a CANopen-specific file format for describing communication for a single node. It lists all the TPDOs, RPDOs, SDOs, etc. that a particular board produces or responds to. It also has a 1:1 correspondence with the values in a CANopen object dictionary, so we can generate these files from our code fairly easily. DBC files are generic to all CAN buses, and they list all the messages sent on a bus. DBC files can always be generated from EDS files, but the inverse is not always true.

Once generated, these files can be used as internal documentation for people to understand the communications for our boards, but they can also be used for debugging a system. Specifically, we combine all EDS and DBC files into a single master DBC for the entire bike. Then, the Integration team uses CANalyzer and the Vector dongle to decode the messages live into human-readable values. Getting this information without having to spend extra time decoding the messages makes a huge difference in the testing cycle time for integration members, so it's important that we're always able to get them accurate DBCs for the bikes.

Software Setup

Before you can start viewing and editing CAN files, you'll need to install the tools necessary. There are a number of open-source tools for editing these files, which you're welcome to use, but our team most often uses Vector's tools for this. To set it up, you can download the latest full installer for CANalyzer, which contains CANeds, and CANdb++ from Vector's Download Center. The CANeds editor is used for EDS files and CANdb++ for DBC files. CANalyzer is a larger tool with extra functionality. In the past, we've just installed all the packages, but you might be able to get away with a partial installation. Also note that CANalyzer has advanced features that require a license. If needed, our team does have a single license, tied to our Vector dongle, but it is normally reserved for the Integration team.

There is some documentation on using CANeds editor on an Integration page, but our documentation can be found here: CANdb++, CANeds.

Defining CANopen Buses

Requirements Definition

The first step in setting up a new CANopen bus is defining the requirements. For a CANopen bus, this is most easily done with a spreadsheet that defines each node's ID, transmit data, transmit frequency, and receive data. This spreadsheet should not define data sizes or which TPDO/SDO each piece of data is in. If the bus has both CANopen and non-CANopen messages, follow the procedure below for specifying those other messages. Also, be sure there are no conflicts between the IDs of the two types of messages.

Implementation

After requirements are defined, the Firmware team is responsible for implementing those requirements in the system. Because this is a CANopen bus, each board will be using the CANopen Stack and an object dictionary for implementation. The implementer should use the node ID defined in the board requirements and should add all transmit and receive data to the object dictionary. Transmit data can be arranged into TPDOs more-or-less arbitrarily, but in general, more important data should be placed in lower TPDOs. RPDOs need to be set up so they correspond with the TPDOs set up on other nodes. If the other boards haven't been set up yet, the RPDOs can be set up as placeholders and updated later.

Bus Decoding Support

Once the bus has been implemented, we can generate an EDS file from each board's object dictionary, using a team-developed Python script (not yet developed). The Firmware team then sends these generated EDS files to the Integration team. When they have EDS files for all the boards on a bus, they can use CANalyzer to generate a DBC file for the entire bus that describes the behavior of all the boards on the bus. This DBC can then be used to decode bus messages and as a reference for team members to better understand the CAN bus.

Defining CAN Bus

Requirements Definition

For CAN buses that don't use CANopen, we still use a spreadsheet, but it is slightly different. The spreadsheet should define all the CAN messages coming from each board, including the frame ID, transmit frequency, transmit data, and receiving boards. Messages are assigned frame IDs according first to their importance, such that more important messages get lower frame IDs, and then by their organization, such that messages with similar content get similar IDs, so they can easily be filtered out.

Implementation

Because we don't have a framework like the CANopen Stack to rely on, implementing the messages for this kind of bus requires a bit more work. The firmware needs to be carefully designed to ensure the right data is sent in the right message and that the message is sent on time. The details of this implementation vary widely from board to board, so the firmware for each board on this type of bus should be scrutinized heavily.

Bus Decoding Support

Because this uses a custom setup, we also have no automatic CAN file generation to rely, so we have to create the DBC file by hand. However, because there's no direct reliance on the implementation, this file can be developed in parallel with the firmware implementation, so long as the person working on the file is communicating with the firmware developer. All messages on the bus should be tracked in a single DBC file that is version controlled with git and GitHub. Once this file is complete, as with the CANopen bus, it can be used for bus decoding and internal documentation.

Page updated

Report abuse