CAN protocol is designed to have a length of 8 bytes. It is necessary to implement a method to send higher data length. In this note I will describe what projects are out there that do this:
From the paper:
The Service Data Object (SDO) protocol,8which is part of CANopen
(see e.g. [4])—a communication protocol for embedded systems used in automation—also implements segmentation and desegmentation of longer messages. SDO is used for setting and for reading values from the object dictionary of a
remote device. Because the values can be larger than the 8 bytes limit of a CAN frame, the SDO protocol
implements also a fragmentation protocol. However, the fragmentation itself is a subprotocol and using
SDO or even the entire CANopen infrastructure is again too much of an overhead.
There are other solutions like:
- Using CANOpenNode that support fragmentation on the SDO, it is necessary an implementation. It is implemented the library on esp32 but not very documented.
- ISO 15765-2
ISO 15765-2
ISO 15765-2,[1] or ISO-TP (Transport Layer), is an international standard for sending data packets over a CAN-Bus. The protocol allows for the transport of messages that exceed the eight byte maximum payload of CAN frames.
Someone did an arduino implementation of the standard.
CSP implementation - CAN Fragmentation Protocol
The standard method to communicate with the SDR is the CAN-bus. The CAN interface on the SDR uses the
CSP CAN Fragmentation Protocol (CFP). CFP is a simple method to make CSP packets of up to 256 bytes,
span multiple CAN messages of up to 8 bytes each. The easiest way to implement CSP/CFP over CAN is to
download the CSP source code from http://libcsp.org and compile the CFP code directly into your own
embedded system.
Next questions
- How CSP Fragmentation Protocol works?
- Does it make sense in my implementation with CCSDS?
- Is the paper compatible with my design?
- Is it better to implement the protocol by myself?
How CSP Fragmentation works?
/**
@file
CAN interface.
CAN frames contains at most 8 bytes of data, so in order to transmit CSP
packets larger than this, a fragmentation protocol is required.
The CAN Fragmentation Protocol (CFP) is based on CAN2.0B, using all 29 bits of the
identifier. The CAN identifier is divided into these fields:
- Source: 5 bits
- Destination: 5 bits
- Type: 1 bit
- Remain: 8 bits
- Identifier: 10 bits
The \b Source and \b Destination fields must match the source and destiantion addressses in the CSP packet.
The \b Type field is used to distinguish the first and subsequent frames in a fragmented CSP
packet. Type is BEGIN (0) for the first fragment and MORE (1) for all other fragments.
The \b Remain field indicates number of remaining fragments, and must be decremented by one for each fragment sent.
The \b identifier field serves the same purpose as in the Internet Protocol, and should be an auto incrementing
integer to uniquely separate sessions.
Other CAN communication using a standard 11 bit identifier, can co-exist on the wire.
*/
The C code of the tx implementation is here using CAN1 and here using CAN2.
Function to receive, it is called every time a can packet is received. There is a thread the is continuosly reading the thread.
There is a buffer that is saving all the incoming packets.And the receiver is reading the packets and filling the information in the buffer.
It is definned for CAN1 and CAN2.… the difference is that the first is CFP1, and the second is CFP2, that is not described but uses more parameters for ports and these things.
Fadi solution in Danstar
They used FD CAN with modm because FDCAN supports more data length. This library supports multiple communication protocols and drivers, so is the same library for multiple scenarios.