astand / c-coderdbc

CAN DBC matrix to C code generator

CODERDBC

Coderdbc is a CLI utility for generating C code from DBC CAN matrix files

Features

• Pack and Unpack functions for conversion signals to CAN payload raw data and vice verse
• Node based Receive function (each node (ECU) has its own Receive function according to its DBC configuration)
• Automation on monitoring functions: CRC, counter and missing tests
• Optional source code generation (the generation of readonly and configuration files can be avoided)
• Flexible setup via driver configuration (see comments in source code for details)

Build and run

For building project you need to have cmake and c++ development toolkit in your system 1 download source code:

git clone https://github.com/astand/c-coderdbc.git coderdbc

Go to the source code directory:

cd coderdbc

Run cmake configuration to 'build' directory:

cmake -S src -B build

Run cmake build:

cmake --build build --config release

Go to the build directory and run:

cd build
./coderdbc --help

Help information with main instructions about using the tool will be printed

Driver functionality description

The source code package includes the following source files (presuming that the dbc driver name is "ecudb"):
  
  ecudb.c / ecudb.h                            (1) RO / lib

Pair of the main driver which contains all dbc frames structs / pack functions / unpack functions declarations. These source files preferably to place in the share/library directory. This part of the package is non-changable and has no any data, so can be used across multi projects.

  ecudb-fmon.h                                 (2) RO / lib

Fmon header is a readonly part of monitoring part of the package. It contains the list of functions for CAN message validation. Those functions should be defined in the scope of user code and can be optionally used in unpack messages. This file is preferably to place in the share/library directory next to the main driver source files.

  ecudb-fmon.c                                 (3) app

User specific part of monitoring functionality. If monitoring is fully enabled user code must define all the monitoring functions. This file is a part of the scope of user code.

  ecudb-config.h                               (4) app / inc*

An application specific configuration file for enabling features in the main driver. If there are a few projects (applications) which include a single main driver (1,2) then each project has to have its own copy of this configuration. Source code (1,2) includes this configuration. If a few dbc matrix is in use in your application then for each of (1,2) specific configuration file must be presented.

  dbccodeconf.h                                (5) app / inc

Application specific configuration file. This file might include "CanFrame" definition, sigfloat_t typedef and binutil macros which enables rx and tx structures allocation inside ecudb-binutil.c. Each project has to have its own copy of this configuration (see template dbccodeconf.h). Source code (4,6) includes this configuration.

  ecudb-binutil.c / ecudb-binutil.h            (6) RO / app

The part which is used for generalization CAN frame flow receiving and unpacking. It also optionally can allocate CAN frame tx/rx structs. 

  canmonitorutil.h                             (7) lib

General definitions for monitoring feature. The source file can be place to the share/library directory.

-----------------------------------------------------------------------------------------------

*inc - file location have to be added to project include path.

generation options

There are several available generation option, use '-help' option for details

c-coderdbc's Issues

compile error v3.0

Hi there!
I'm just trying to compile the project the first time on Windows 10 (compiler SDK VS 2022 x64)
And I'm getting the error in dbcscanner.cpp(348,30): error C2131
it looks like strlen doesn't work for some reason.

I tried to simply change the function and using sizeof instead and it compiles (TBT pending)

static const size_t VER_MIN_LENGTH = sizeof(versionAttr);//strlen(versionAttr);

does it make sense?

ty

Code is correct, inline comment swapped :)

c-coderdbc/src/parser/dbclineparser.cpp

Line 259 in d63b36a

// byte_order = '0' | '1'; (*0 = little endian, 1 = big endian*)

Generating enums

Is there any possibility to create from DBC file:

BO_ 1 Heartbeat: 8 Vector__XXX
 SG_ Axis_State : 32|32@1+ (1,0) [0|0] "" Vector__XXX
 SG_ Axis_Error : 0|32@1+ (1,0) [0|0] "" Vector__XXX


BA_ "FieldType" SG_ 1 Axis_State "Axis_State"
VAL_ 1 Axis_State 13 "ENCODER_HALL_PHASE_CALIBRATION" 12 "ENCODER_HALL_POLARITY_CALIBRATION" 11 "HOMING" 10 "ENCODER_DIR_FIND" 9 "LOCKIN_SPIN" 8 "CLOSED_LOOP_CONTROL" 7 "ENCODER_OFFSET_CALIBRATION" 4 "MOTOR_CALIBRATION" 3 "FULL_CALIBRATION_SEQUENCE" 1 "IDLE" 0 "UNDEFINED";

enumerate like this:

uint32_t Axis_Error;                       //      Bits=32

enum Axis_State_Val {
      UNDEFINED = 0,
      IDLE = 1,
      FULL_CALIBRATION_SEQUENCE = 3,
      MOTOR_CALIBRATION = 4,
      ENCODER_OFFSET_CALIBRATION = 7,
      CLOSED_LOOP_CONTROL = 8,
      LOCKIN_SPIN = 9,
      ENCODER_DIR_FIND = 10,
      HOMING = 11,
      ENCODER_HALL_POLARITY_CALIBRATION = 12,
      ENCODER_HALL_PHASE_CALIBRATION = 13
  } Axis_State;  //    Bits=32 

Instread of this:

 uint32_t Axis_Error;                       //      Bits=32

  //  13 : "ENCODER_HALL_PHASE_CALIBRATION"
  //  12 : "ENCODER_HALL_POLARITY_CALIBRATION"
  //  11 : "HOMING"
  //  10 : "ENCODER_DIR_FIND"
  //  9 : "LOCKIN_SPIN"
  //  8 : "CLOSED_LOOP_CONTROL"
  //  7 : "ENCODER_OFFSET_CALIBRATION"
  //  4 : "MOTOR_CALIBRATION"
  //  3 : "FULL_CALIBRATION_SEQUENCE"
  //  1 : "IDLE"
  //  0 : "UNDEFINED"
  uint32_t Axis_State;                       //      Bits=32

Add the coderdbc version and source *.dbc file name

I would like to see the coderdbc version and source *.dbc file name as a comment at the top of each generated file.

Is function for TX direction available in util file?

Hello.
In my DBC file I have declared TX message. I don't know why but it's appear in xxx_Receive function.

Is it a BUG or intended action?

coderdbc incorrectly translating scale factor of "1E-007"

To whom it may concern,

I am a graduate student working on a collegiate design series. The competition rules require us to publish our outputs over a scoring CAN bus, and they have provided us a DBC file to abide by when transmitting our outputs.

One of the messages is comprised of the following 2 signals:
SG_ VehicleLatitude : 7|32@0- (1E-007,0) [-90|90] "deg" DAQ
SG_ VehicleLongitude : 39|32@0- (1E-007,0) [-180|180] "deg" DAQ

As you know, these lines of the DBC state that the conversion factor between the physical and integer values is 10^(-7). However, the codegen software misinterprets this line by substituting it for a zero.

The output of the codegen is:
// signal: @VehicleLatitude_ro
#define SCORING_VehicleLatitude_ro_CovFactor (0)

This issue persisted even when the scale factor in the DBC was replaced with a more typical decimal point representation:
SG_ VehicleLatitude : 7|32@0- (0.0000001,0) [-90|90] "deg" DAQ

As I was writing this issue, we actually found (what we believe to be) one source of the error. In c-sigprinter.cpp, there are several formatted prints that use %f rather than something longer like %.10f and the number is truncated. This affects the CoV, toS, and fromS macros.

====

Another issue is that using scientific notation in the scale factor appears to cause issues in the output. Using scientific notation caused the codegen to misinterpret physical float values as integer values.

From the output of the codegen:
#ifdef E_USE_SIGFLOAT
uint64_t VehicleLatitude_phys;
#endif // E_USE_SIGFLOAT

The output should have used the sigfloat_t type instead. This issue can be somewhat fixed by not using scientific notation in DBC definitions, but we have found several other DBC files online where scientific notations are common.

License of generated code

Hi There!

First off, thanks for creating this auto-generator, it works great!
I noticed the licence of this repository and the coderdbc command-line tool is GPL-3.0.

However, I assume all code generated by the tool is free of any type of license or conditions of any kind?
Just wanted to double-check.

Thanks!

Unable to compile

Hi, i use the wsl-shell in Windows to compile your project.

I install the build-essentials, so i may missed some depencies. Do you have any clue, what's missing?

`> sudo cmake --build build --config release --clean-first

[ 9%] Building CXX object CMakeFiles/coderdbc.dir/codegen/c-main-generator.cpp.o

[ 18%] Building CXX object CMakeFiles/coderdbc.dir/codegen/c-util-generator.cpp.o

[ 27%] Building CXX object CMakeFiles/coderdbc.dir/codegen/conditional-tree.cpp.o

[ 36%] Building CXX object CMakeFiles/coderdbc.dir/codegen/c-sigprinter.cpp.o

[ 45%] Building CXX object CMakeFiles/coderdbc.dir/codegen/filewriter.cpp.o

[ 54%] Building CXX object CMakeFiles/coderdbc.dir/codegen/fs-creator.cpp.o

[ 63%] Building CXX object CMakeFiles/coderdbc.dir/helpers/formatter.cpp.o

[ 72%] Building CXX object CMakeFiles/coderdbc.dir/parser/dbclineparser.cpp.o

[ 81%] Building CXX object CMakeFiles/coderdbc.dir/parser/dbcscanner.cpp.o

[ 90%] Building CXX object CMakeFiles/coderdbc.dir/maincli.cpp.o

[100%] Linking CXX executable coderdbc

/usr/bin/ld: CMakeFiles/coderdbc.dir/codegen/fs-creator.cpp.o: in function
FsCreator::PrepareDirectory(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)': fs-creator.cpp:(.text+0xe3): undefined reference to std::filesystem::create_directory(std::filesystem::__cxx11::path const&)'

/usr/bin/ld: fs-creator.cpp:(.text+0x20c): undefined reference to `std::filesystem::create_directory(std::filesystem::__cxx11::path const&)'

/usr/bin/ld: fs-creator.cpp:(.text+0x263): undefined reference to `std::filesystem::create_directory(std::filesystem::__cxx11::path const&)'

/usr/bin/ld: CMakeFiles/coderdbc.dir/codegen/fs-creator.cpp.o: in function std::filesystem::__cxx11::path::path<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::filesystem::__cxx11::path>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::filesystem::__cxx11::path::format)': fs-creator.cpp:(.text._ZNSt10filesystem7__cxx114pathC2INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC5INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES1_EERKT_NS1_6formatE]+0x64): undefined reference to std::filesystem::__cxx11::path::_M_split_cmpts()'

/usr/bin/ld: CMakeFiles/coderdbc.dir/maincli.cpp.o: in function std::filesystem::exists(std::filesystem::__cxx11::path const&)': maincli.cpp:(.text._ZNSt10filesystem6existsERKNS_7__cxx114pathE[_ZNSt10filesystem6existsERKNS_7__cxx114pathE]+0x14): undefined reference to std::filesystem::status(std::filesystem::__cxx11::path const&)'

collect2: error: ld returned 1 exit status

make[2]: *** [CMakeFiles/coderdbc.dir/build.make:219: coderdbc] Error 1

make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/coderdbc.dir/all] Error 2

make: *** [Makefile:84: all] Error 2
`

Incorrect read long string

j1939.zip

When I try to decode j1939.dbc file (attached), the decoder hang.
While debugging, I found a problem with reading the input file. If readstream.getline(line, MAX_LINE) reading a string longer than MAX_LINE, the failure bit will be set in the readstream. To continue reading, you must clear current status (readstream.clear()) and reread remaining data. You code may look like:

if(readstrm.fail())
{
  readstrm.clear();
  readstrm.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
}

is CAN-FD whose message is more than 64-bits supported?

is CAN-FD supported? I have got some problem when using this generator. It seems that messages which are more than 8 DLC are not supported.

Identical #defines generated with test code

Using the test dbc file and generate code. Search in the header file for ???_U7_TEST_1_ro_CovFactor
You'll see that two #defined have been generated!
This is a result of only using the inner name of the signal and not having the PGN name or other unique identifier

BO_ 1911 SIG_TEST_1: 8 EPS
SG_ U7_TEST_1 : 55|7@0+ (1,-255) [-255|-128] "" BCM <===================== Creates the same #define!

BO_ 333 UTEST_2: 8 BCM
SG_ U8_TEST_1 : 39|8@0+ (1,0) [0|255] "" BMS
SG_ U7_TEST_1 : 47|7@0+ (1,-255) [-255|-128] "" BMS <===================== Creates the same #define!

web site coderdbc.com stop working

Hello,

firstly i would like to thank you for your great job!

Secondly i have a quiestion. The website https://coderdbc.com/ stop working just in time i start using your app. Are you going to repair it?

Thank you,
best regards,
Jiri

Checksum signal incorrect assignment.

Default Attribute Values not applied

Hi @astand I noticed that some of the CycleTime values for my messages were not set. After further investigation it seems that BCD file has the following entry

////////////////////////////////
//                            //
//  Attribute Default Values  //
//                            //
////////////////////////////////

BA_DEF_DEF_  "GenSigCycleTime" 33;
BA_DEF_DEF_  "GenMsgCycleTime" 33;
BA_DEF_DEF_  "GenSigSendType" "NoSigSendType";
BA_DEF_DEF_  "GenMsgSendType" "Cyclic ";
BA_DEF_DEF_  "Component_Address_Type" "NO_COMPONENT_ADDRESS";
BA_DEF_DEF_  "Component_Address" 0;

I examining the code generator and parse code and these default attribute values so not look like they are being extracted and used in the code generation.

A quick and simple fix would be to scan for these defaults and set them in the message constructor (or simular method) before parsing the messages.

a comment need be fixed

390th line in file c-coderdbc/src/codegen/c-main-generator.cpp.
after "(result may be tested in dedicated Fmon_*** function)." need a " */" to finish the comment.
this mistake is unnecessary to create an pull request. so submit it in here.

incorrect parsing of signed 8 bit signals

thank you for inventing and sharing this tool!
I believe I have found a bug related on unpack of signals defined as signed 8 bit
code generated is the following:
__m->YYY_signal1_ro = (d[3] & (0xFFU));
but YYY_signal1_ro (int16_t) will contain 0x00DF instead of 0x805F
so when the following will be executed
_#ifdef CANDB_MONDIAL_USE_SIGFLOAT //this is defined
_m->YYY_signal1_phys = CANDB_MONDIAL_YYY_signal1_ro_fromS(m->YYY_signal1_ro);
#endif // CANDB_MONDIAL_USE_SIGFLOAT
generate
00DF * factor + offset
instead of
0x805F * factor + offset

for a fast solution I modified the first line in
__m->YYY_signal1_ro = (int16_t)( (int8_t)(d[3] & (0xFFU)));
but many other solution could be implemented.

Fell free to contact me for any additional information