HVAC_M7_CAN_MATRIX/conf/candb-config.h

132 lines
4.9 KiB
C

// Generator version : v3.1
// DBC filename : CCU.dbc
#pragma once
/* include common dbccode configurations */
#include "dbccodeconf.h"
#define __DEF_CCU_CANDB__
/* ------------------------------------------------------------------------- *
This define enables using CAN message structs with bit-fielded signals
layout.
Note(!): bit-feild was not tested properly. */
/* #define CANDB_USE_BITS_SIGNAL */
/* ------------------------------------------------------------------------- *
This macro enables using CAN message descriptive struct packing functions
(by default signature of pack function intakes a few simple typed params
for loading data, len, etc). To compile you need to define the struct
__CoderDbcCanFrame_t__ which must have fields:
u32 MsgId (CAN Frame message ID)
u8 DLC (CAN Frame payload length field)
u8 Data[8] (CAN Frame payload data)
u8 IDE (CAN Frame Extended (1) / Standard (0) ID type)
This struct definition have to be placed (or be included) in dbccodeconf.h */
/* #define CANDB_USE_CANSTRUCT */
/* ------------------------------------------------------------------------- *
All the signals which have values of factor != 1 or offset != 0
will be named in message struct with posfix '_ro'. Pack to payload
operations will be made on this signal value as well as unpack from payload.
USE_SIGFLOAT macro makes some difference:
1. All the '_ro' fields will have a pair field with '_phys' postfix.
If only offset != 0 is true then the type of '_phys' signal is the same
as '_ro' signal. In other case the type will be @sigfloat_t which
have to be defined in user dbccodeconf.h
2. In pack function '_ro' signal will be rewritten by '_phys' signal, which
requires from user to use ONLY '_phys' signal for packing frame
3. In unpack function '_phys' signal will be written by '_ro' signal.
User have to use '_phys' signal to read physical value. */
/* #define CANDB_USE_SIGFLOAT */
/* ------------------------------------------------------------------------- *
Note(!) that the "canmonitorutil.h" must be accessed in include path:
This macro adds:
- monitor field @mon1 to message struct
- capture system tick in unpack function and save value to mon1 field
to provide to user better missing frame detection code. For this case
user must provide function declared in canmonitorutil.h - GetSysTick()
which may return 1ms uptime.
- calling function FMon_*** (from 'fmon' driver) inside unpack function
which is empty by default and have to be filled by user if
tests for DLC, rolling, checksum are necessary */
#define CANDB_USE_DIAG_MONITORS
/* ------------------------------------------------------------------------- *
When monitor using is enabled (CANDB_USE_DIAG_MONITORS) and define below
uncommented, additional signal will be added to message struct. ***_expt:
expected rolling counter, to perform monitoring rolling counter sequence
automatically (result may be tested in dedicated Fmon_*** function) */
/* #define CANDB_AUTO_ROLL */
/* ------------------------------------------------------------------------- *
When monitor using is enabled (CANDB_USE_DIAG_MONITORS) and define below
uncommented, frame checksum signal may be handled automatically.
The signal which may be marked as checksum signal must have substring
with next format:
<Checksum:XOR8:3>
where:
- "Checksum": constant marker word
- "XOR8": type of method, this text will be passed to GetFrameHash
(canmonitorutil.h) function as is, the best use case is to define 'enum
DbcCanCrcMethods' in canmonitorutil.h file with all possible
checksum algorithms (e.g. XOR8, XOR4 etc)
- "3": optional value that will be passed to GetFrameHash as integer value
Function GetFrameHash have to be implemented by user
In pack function checksum signal will be calculated automatically
and loaded to payload
In unpack function checksum signal is checked with calculated.
(result may be tested in dedicated Fmon_*** function). */
/* #define CANDB_AUTO_CSM */
/* ------------------------------------------------------------------------- *
FMon handling model can be build in two ways:
1 - Default. In this case when specific frame unpack is called the
specific FMon_{Frame name}_{driver name} functoin will be called.
User's code scope has to define each of these functions. Each function is
responsible for the error handling of one frame
2 - MONO. In this case there is only one function to perform any frame
monitoring. This function has to be implemented in the user's code scope.
This function is named as FMon_MONO_{driver name}. It takes frame id
which can be used for selection of the logic for a frame monitoring.
This mode costs a bit more in runtime but when you often edit you DBC and you
have more than one project it could be more maintanable (there is
no necessity to replace source code)
For using MONO way uncomment line below */
/* #define CANDB_USE_MONO_FMON */