can-api-generator 0.0.10

Program to generate a 'signal' style CAN API in C

can-api-generator

---

Table of Contents

• Installation
• License
• Overview
• Features of the library
• Additional features
  • Global RX
  • Periodic TX
  • Encode All Signals
  • TI C2000 compatibility
  • Double-buffered signal access
• Example Use
• Command-line reference

Installation

pip install can-api-generator

License

can-api-generator is distributed under the terms of the GPL-3.0-only license.

Overview

The can-api-generator is a program to generate a C implementation for a 'signal' style CAN API from a KCD file describing the signals and their arrangement in to messages sent over the can bus. A signal represents a value that is shared among all nodes of the bus. Due to the fact that CAN is based on packets, which are referred to as frames, multiple signals may to be grouped into a common message which is then transmitted as a can frame. Different messages are distinguished via the arbitration id that is part of the can frame. Thus the arbitration ID acts as a content address (think address of memory shared over the can bus), and not a source or destination address.

A Frames are sent out by the node that modifies a value that is contained in the Frame. A KCD file may encompass multiple nodes that have messages sent between them. To minimize the code generated, a Node needs to be specified so that only the messages that are transmitted or received by this node. Flags allow generating the additional code if needed.

The API is only concerned with frames that are defined by the KCD file from which the API was generated. Other frames may be transmitted over the bus and are outside the scope of this API. The code simply decodes what it can identify and only produces frames that are defined as 'tx' from the nodes

Practical uses

In practice frames are often sent periodically, even if no change has occured, to provide redundancy and fault tolerance to the system. Even though any node in the network may send any frame, in practice only a single node on a bus will update certain signals, thus avoiding the problems that arise when multiple nodes modify the same signal.

Can frames generated by this library are compatible to the DBC and KCD definitions and can thus be decoded by industry standard tools like busmaster/canoe/PeakCan etc.

Features of the library

---

• One struct per message: The struct contains the signals that are explicitly defined in the can frame (including multiplexes). This allows a single message struct to fully define a frame (the ID and length are declared as defines). (see the example for explicit code)
• Decodeing/Encoding functions: For each Message a decode and encode functions is generated that allow to translate the struct into a 'CanFrame' and decode a 'CanFrame' struct in to the message struct that contains the values encoded as native data types. The encoding function also sets the length and the arbitration id of the can frame.

Additional features

---

This generator may generate additional code that was found useful in many common cases:

• a global rx function (enabled with -r/--global-rx): takes a received can frame, matches it against the message definitions in the API, and decodes it into a 'global' api struct containing the signals for every message this node consumes.
• a periodic tx function (enabled with -p/--periodic-tx): schedules messages to be sent automatically. Auxiliary information is stored, similar to the 'global rx', in a TxContext struct. It allows for changing the period of the transmission on the fly and also allows a tx callback to be called upon transmission of any particular message. Transmission may also be disabled per message.
• an encode-every-signal helper per message (enabled with -a/--encode-all-signals-func): fills a caller-provided buffer with the minimum number of frames needed to cover every signal in a multiplexed message at least once. See Encode All Signals.
• an immediate-send override for the periodic tx path (enabled with --send-now): adds a per-message send_now flag that fires the next periodic_tx call regardless of schedule or enable state. Useful for publishing critical signal changes without waiting out the rest of the period.
• TI C2000 compatible codegen (enabled with --ti-compatible): hoists local variable declarations to the top of encode/decode functions so the generated C compiles under the TI C2000 compiler's strict C90 rules. See TI C2000 compatibility.
• double-buffered signal access (enabled with --double-buffered): emits two storage slots and front/back pointers per message so that an ISR-side decode never exposes a partially-written struct to readers, and a periodic tx encoder never reads a struct that user code is mid-update. See Double-buffered signal access.

Global RX

Global RX generates the code needed to take any received can frame and decode it in to the API if the message matches a definition in the API. This allows the application to call a single function once per received frame and have access to all signals shared via the CAN bus system by simply reading the signals in the RX struct.

The global rx funciton needs to be called with the 'current time'. which for MCUs is most often represented by a count of the milliseconds passed since power up.

The global RX struct also contains one MsgRxContext struct per message. This allows to configure parameters and read back metadata about the message. The MsgRxContext has the following form:

struct MsgRxContext {
    uint16_t ignore;
    uint16_t valid;
    uint64_t last_rx;
    void (*rx_callback)(void);
};

• When the ignore value is set to 1, the received message is not decoded even if it's arbitration id and length matched with the message definition.
• The valid field is set to 1 every time the corresponging message is received. This value may be written to 0 by the application and allows the application to simply check if the information in the message has been written to. This is useful when a critical section is to be entered that requires other programs to have set configuration parameters that need to be valid before the critical section is entered.
• last_rx field stores the value of the 'clock' the last time this message was received. this may be used for diagnostics and statistics

Periodic TX

The periodic TX is the counterpart to the 'global RX'. It takes care to schedule the transmission of periodic frames at the proper time. Periodic frames are pretty common on CAN bus systems and provide robust communication of critical data without the need for explicit synchronization mechanisms. Many controllers, often found in automotive applications send the same message periodically. This allows for 'quasi-analog' values to be transmitted via the CAN bus. When enabling the -p/--periodic-tx flag the can api generator generates a <api>_periodic_tx function that properly schedules periodic messages, an <api>_periodic_tx_init function that seeds the per-message contexts from the cycle_time values in the KCD, and an <api>_get_msg_tx_context_by_id helper for looking up a message context by arbitration id. To configure the periodic transmission the TxSignals struct, that is generated along with the periodic tx function, provisions one MsgTxContext struct for each message. The MsgTxContext is defined as following:

struct MsgTxContext {
    uint32_t arb_id;
    uint16_t enable;
    uint64_t last_tx;
    uint32_t period;
    uint32_t offset;
    uint32_t offset_seed;
    void (*tx_callback)(void);
    uint16_t send_now;         // only present when compiled with --send-now
};

• arb_id is the arbitration id of the message the context controls. It is seeded by <api>_periodic_tx_init so the application can look up a context by id via <api>_get_msg_tx_context_by_id.
• enable needs to be set to 1 for the message to be sent periodically. This allows the application to reduce bus load by silencing messages depending on the situation. Init sets this to 1 for messages that declare a cycle_time in the KCD and 0 for the rest.
• last_tx is updated by the periodic tx function every time a frame fires. Combined with period, it gates retransmission so a frame cannot fire more often than once per period.
• period configures the time between two messages (in MCU clock units). Most MCUs use a 1ms tick so this value often ends up being the number of milliseconds between two periodic transmissions. The application may change this at runtime via <api>_update_tx_period(ctx, new_period), which also recomputes offset so the phase stays consistent.
• offset is a value that adds an offset to the transmission time. Multiple messages will often have the same period (say 100ms). Without the offset the CAN bus becomes quite 'bursty' as every 100ms many messages are encoded at once and require transmission. This may lead to dropped messages and bus load problems even at low average load. This offset spreads out the transmission of messages through the entire transmission period, reducing pileup of messages.
• offset_seed is a per-message constant seeded at generation time so that different messages with the same period end up at different phases inside that period without the application having to pick offsets by hand.
• tx_callback is a function that is called after the tx frame has been encoded. It allows sending one message after the other (as used for data transfers). Using this technique it is possible to effectively set data transfer rates. This works well in combination with the enable flag.
• send_now is only emitted when the generator is invoked with --send-now. Setting this flag to 1 makes the next <api>_periodic_tx call emit the corresponding frame immediately, regardless of the periodic schedule or the enable bit. The function auto-clears the flag after firing, so each set fires exactly once. Useful when a critical signal has just changed and you want it on the bus on the very next tick instead of waiting out the remainder of the period.

Encode All Signals

Some messages use multiplexes combining many signals in to a single message. This may be particularly true for configuration messages that have many related parameters and use multiplexes to fit all parameters in to a single message using many mux groups. If the entire config should be read out and the read back happens periodically, the supervisory controller must wait a long time until the multiplex is cycled throug all it's mux groups. To reduce the time it takes to read back this kind of message, the encode all messages function is used. This function generates a group of CanFrames and stores them in to a buffer provided by the caller. This buffer can then be flushed by the application. The size of the buffer required for a given message is declared as a preprocessor define in the library header file. To receive all frames generated by the function the caller needs to provide a buffer of at least that size.

the 'encode all signals' function is generated when the tool is passed the -a option.

TI C2000 compatibility

Some target compilers — notably the TI C2000 toolchain — refuse C99-style "declaration after statement" code, which requires all local variables to be declared at the top of a block before any statements. The default code generator emits variable declarations inline inside switch/case bodies for multiplexed messages, which the TI compiler rejects. Passing --ti-compatible changes the codegen so every per-signal temporary is hoisted to the top of the enclosing encode/decode function, all mux variant assignments become pure stores instead of declarations, and the loop counter in the encode_every_signal helper is predeclared before its initializer. The resulting source compiles cleanly under both -std=c99 and -std=c90 -Wdeclaration-after-statement -Werror=declaration-after-statement, matching what the TI C2000 compiler will accept.

Double-buffered signal access

When an RX frame is decoded from an ISR while the main loop reads signals (or the converse for TX, where the user updates the struct while periodic_tx encodes it), a reader can observe a half-written struct and act on inconsistent data. Passing --double-buffered changes the generated global RX and periodic TX structs so every message carries two storage slots and two pointers, and the dispatcher / commit helper publishes new values via an atomic pointer swap instead of an in-place update:

struct DUTRxSignals {
    struct MsgRxContext message_1_context;
    struct Message1 message_1_signals_storage[2];
    struct Message1 * volatile message_1_signals;       /* reader view */
    struct Message1 * message_1_signals_back;            /* dispatcher decodes here */
    /* ... */
};

struct DUTTxSignals {
    struct MsgTxContext message_1_context;
    struct Message1 message_1_signals_storage[2];
    struct Message1 * message_1_signals;                 /* staging — user writes here */
    struct Message1 * volatile message_1_signals_committed; /* periodic_tx reads this */
    /* ... */
};

Semantics:

• Access to the signal sub-struct becomes pointer-style instead of dot-style. Read the latest decoded RX value as rx_signals.message_1_signals->field, and write a pending TX value as tx_signals.message_1_signals->field.
• <api>_global_rx_init(&rx_signals) wires up the front/back pointers and zeroes both storage slots. Call it once before <api>_process_received_frame.
• <api>_periodic_tx_init(&tx_signals, now) wires up the staging/committed pointers in addition to the usual context init. Call it once before <api>_periodic_tx.
• For each TX message the generator emits a per-message commit helper, <api>_<message_name>_commit(&tx_signals). It swaps the staging and committed pointers — after the call, the values the user just wrote into staging are live on the committed side, and the new staging slot contains the previous committed snapshot. The swap is cheap (two pointer writes) and allocation-free.
• The RX dispatcher decodes into message_<n>_signals_back and, on success, swaps message_<n>_signals ↔ message_<n>_signals_back inside a short inner block. A decode that aborts mid-way never publishes a partial struct — the front pointer keeps pointing at the previously-good decode.
• Because commits are pointer-swap rather than memcpy, the new staging slot holds the previous committed snapshot. Code that updates a subset of fields per commit therefore still publishes coherent messages, but code that relies on staging being zero after commit must zero it explicitly.

Ordering guarantee: the front/committed pointers are declared volatile so the compiler will not reorder the pointer publish across reads in the same translation unit. This is sufficient for a single-core MCU where the dispatcher runs in an ISR and readers run in the main loop, which is the target use case. On weakly-ordered multicore hosts, user code is responsible for inserting the appropriate memory barrier between the decode writes and the pointer publish, and between reading the pointer and dereferencing it — the generator does not emit any barriers itself.

Example Use

As an example the following KCD definition of all messages on a CAN bus is converted:

<?xml version="1.0" ?>
<NetworkDefinition xmlns="http://kayak.2codeornot2code.org/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="KCD_Definition.xsd">
  <Document name="can-api-generator-test-1" version="1" author="Alexander Krishna-Becker" company="radiation.systems" date="2025-11-01"/>
  <Node id="0" name="DUT"/>
  <Node id="1" name="other"/>
  <Bus name="ControlBus" baudrate="500000">
    <Message id="0x0" length="1" name="Message 1" interval="100" format="extended">
      <Notes>Test Note 1</Notes>
      <Producer> <NodeRef id="0"/> </Producer>
      <Signal name="Signal 1" offset="0" length="1">
        <Notes>Signal 1 of Message 1 of the DUT</Notes>
        <Consumer> <NodeRef id="1"/> </Consumer>
        <Value type="unsigned"/>
      </Signal>
      <Signal name="Signal 2" offset="1" length="7">
        <Notes>Signal 1 of Message 1 of the DUT</Notes>
        <Consumer> <NodeRef id="1"/> </Consumer>
        <Value type="signed"/>
      </Signal>
    </Message>

    <Message id="0x1" length="2" name="Message 2" interval="100" format="extended">
      <Notes>Test Note 1</Notes>
      <Producer> <NodeRef id="0"/> </Producer>
      <Signal name="Signal 3" offset="0" length="16">
        <Notes>Signal 1 of Message 1 of the DUT</Notes>
        <Consumer> <NodeRef id="1"/> </Consumer>
        <Value type="unsigned"/>
      </Signal>
    </Message>
  </Bus>
</NetworkDefinition>

The result of the conversion are the decode/encode functions along with the structs to hold the application accessible signals.

To convert the KCD file into C code the following command is used:

can-api-gen example.kcd my_api DUT

The first argument is the path to the kcd file. The second argument is the name of the API. This name determins the name of the C and H file headers as well as parts of the name of the struct and functions. This is done so that multiple APIs may be used within the same project without interfering with each other. The last entry is the name of the Device for which the can api is to be generated. This is needed as multiple devices may be described on a single can Bus. The KCD file then needs to describe what signal is sent by a device, as well as which signal a device is listening for. The interface generator uses this info to only generate messages that are relevant to the particular device. The following is the resulting header:

#ifndef CAN_API_MY_API
#define CAN_API_MY_API
#include "canframe.h"

// If all signals in a message need to be encoded then it will need
// a buffer of at least the size defined here to hold the frames to set each signal
// contained in the message at least once
#define MESSAGE_1_MIN_FRAMES_FOR_ALL_SIGNALS 1
#define MESSAGE_2_MIN_FRAMES_FOR_ALL_SIGNALS 1



struct Message1 {
    uint16_t signal_1;
    int16_t signal_2;
};
struct Message2 {
    uint16_t signal_3;
};

void my_api_message_1_decode(struct Message1 *msg, CanFrame *input_frame);
void my_api_message_1_encode(struct Message1 *msg, CanFrame *output_frame);
uint16_t my_api_message_1_encode_every_signal(struct Message1* msg, CanFrame *output_frame_buf, uint32_t buf_size);
void my_api_message_2_decode(struct Message2 *msg, CanFrame *input_frame);
void my_api_message_2_encode(struct Message2 *msg, CanFrame *output_frame);
uint16_t my_api_message_2_encode_every_signal(struct Message2* msg, CanFrame *output_frame_buf, uint32_t buf_size);
#endif

As can be seen it provides encode and decode functions for each message that interacts with the DUT. It also emits an encode_every_signal helper per message (because the example was generated with -a), the minimum buffer-size defines the caller needs for that helper, and the message structs themselves. The companion canframe.h file is written next to the library header; it declares the small CanFrame struct the API uses as an I/O boundary with the application's can driver.

To enable the additional features, pass the corresponding flags at generation time:

# Generate a full-featured API with global rx, periodic tx, encode-every-signal,
# send-now support, and TI C2000 compatible codegen.
can-api-gen example.kcd my_api DUT -r -p -a --send-now --ti-compatible

Command-line reference

Positional arguments:

• KCD_FILE — path to the KCD (XML) description of the bus.
• LIBRARY_NAME — stem of the generated library. The output files are <LIBRARY_NAME>.c, <LIBRARY_NAME>.h, and a sibling canframe.h. The stem is also used as the prefix for every generated function so multiple APIs can coexist in the same project.
• NODE_NAME — name of the node the API is being generated for. Only messages that this node produces or consumes are emitted, so the binary size stays small for embedded targets.

Options:

• -f, --force — overwrite existing output files. Without this, the generator refuses to clobber an existing .c/.h.
• -a, --encode-all-signals-func — for each message, emit an <api>_<msg>_encode_every_signal helper that fills a caller-provided buffer with enough frames to cover every signal at least once (primarily useful for multiplexed config messages).
• -r, --global-rx — emit the api-wide RxSignals struct plus a <api>_process_received_frame dispatcher that takes a raw CanFrame, figures out which message it corresponds to, and decodes it into the right per-message struct. See the Global RX section for details.
• -p, --periodic-tx — emit the api-wide TxSignals struct, the <api>_periodic_tx function, and <api>_periodic_tx_init / <api>_update_tx_period / <api>_get_msg_tx_context_by_id helpers. See the Periodic TX section.
• --send-now — add a send_now field to each MsgTxContext and a gate in the periodic tx function that fires a frame immediately when the flag is set, bypassing both enable and the periodic schedule. Only meaningful together with -p.
• --ti-compatible — hoist all per-signal temporaries to the top of every encode/decode function so the generated C compiles under strict C90 ("declarations before statements"), which is what the TI C2000 compiler requires. See TI C2000 compatibility.
• --double-buffered — emit two signal-struct storage slots plus front/back pointers per message, an <api>_global_rx_init helper that wires the RX pointers, and a per-message <api>_<msg>_commit helper that swaps the TX staging and committed pointers. The RX dispatcher publishes new decodes via pointer swap, and <api>_periodic_tx encodes from the committed slot. See Double-buffered signal access.
• -im, --id-member-name TEXT — override the name of the CanFrame member that carries the arbitration id (default arbitration_id). Used to adapt the API to an existing project's frame struct naming.
• -lm, --length-member-name TEXT — override the name of the CanFrame length member (default length).
• -pm, --payload-member-name TEXT — override the name of the CanFrame payload member (default payload).
• -v, --verbose — dump the processed message dicts that get fed into the Jinja templates. Useful when debugging template or generator changes.
• --help — show the CLI help and exit.