5.10. CANSIGNAL¶
The cansignal
module is part of the Module
layer.
The cansignal
module is a software module to handle the conversion from data
providers like a database or measurement modules to the can
module. It works
similar to a typical IPO (input-processing-output) pattern.
5.10.1. Module Files¶
- Driver:
embedded-software\mcu-common\src\module\cansignal\cansignal.h
(cansignal.h)embedded-software\mcu-common\src\module\cansignal\cansignal.c
(cansignal.c)
- Driver Configuration:
embedded-software\mcu-primary\src\module\config\cansignal_cfg.h
(cansignal_cfg.h)embedded-software\mcu-primary\src\module\config\cansignal_cfg.c
(cansignal_cfg.c)
5.10.2. Detailed Description¶
5.10.2.1. File Structure and Interfaces¶
The cansignal
module is a simple one-file module with one-file configuration:
The module itself consists of one file
cansignal.c
and its associatedcansignal.h
The configuration is given in
cansignal_cfg.c
and its associatedcansignal_cfg.h
The external interface to the cansignal
module is very easy and consists of just two functions:
CANS_Init
CANS_MainFunction
CANS_Init is for parameter and configuration checking of the cansignal
module.
CANS_MainFunction is for data processing and should be called periodically.
5.10.2.2. Data Flow¶
The data flow is generally divided in two different domains, one for reception of CAN messages and signal value distribution, the other for transmission of CAN message and signal value assembling/message composition.
When a CAN message is received physically, it is stored in a buffer which is
polled periodically by CANS_MainFunction()
. In case of a match, the
corresponding signals of the message are extracted, scaled and handed over to
a data consumer via the callback setter function.
When a CAN message needs to be transmitted physically, the signals data belonging to this CAN message are collected via their getter callback function. From this signals data, the CAN message is assembled. If everything worked fine, it is stored in a buffer and sent out over the CAN peripheral hardware.
fig. 5.26 shows the data flow used to assemble a CAN message.

Fig. 5.26 CAN data flow to assemble messages¶
5.10.2.3. Control Flow¶
The module operates from a single function call to CANS_MainFunction()
.
First the periodic message transmission is handled in this function. If
correspondence of an internal tick counter to a message repetition time and
phase is detected (i.e., the periodic time expired) the CAN message is
composed from its signals. Therefore all signals, which are included in a
message, are collected via their getter callback and written to the message
data block at the right position in the right length. This message data block
together with the ID, Data Length Code and so on, is handed over to the
can
module, which handles the low level transmission to the CAN specific
peripheral registers.
The message reception in turn is done by reading out the buffer of the
can
module. Then the signals configuration is searched for this message(s). If
one signal is represented in these received messages it is extracted and
handed over to the setter callback function configured for this signal.
5.10.3. CAN Configurations¶
5.10.3.1. Default Configuration¶
The configuration comprises:
enums for both receive and transmit message names (
CANS_messagesTx_e
respectivelyCANS_messagesRx_e
)enums for both receive and transmit signal names (
CANS_CANx_signalsTx_e
respectivelyCANS_CANx_signalsRx_e
)arrays for signal definition, for both receive and transmit signals
callback function implementations for getting and setting of signals
callback function implementations for post-processing after transmission and reception of messages
5.10.3.2. Custom Configuration Examples¶
See FAQ section on how to manually add/delete a CAN message.
5.10.4. Usage/Examples¶
To use can
module and cansignal
module with a correct CAN Configurations,
just call CANS_MainFunction
in the cyclic tasks timeslot, that is
configured in CANS_TICK_MS
.