|
1 | | - # CODERDBC |
| 1 | +# CODERDBC |
2 | 2 |
|
3 | | - ## What is it |
4 | | - |
5 | | - CLI utilty for generating C code from dbc (CAN matrix) files |
6 | | - |
7 | | - ## Build and run |
8 | | - |
9 | | - This manual works on Ubuntu 20.04 and Windows 10. You need to ensure that your system has |
10 | | - C++ compile and builing toolchain (**c++17**) |
11 | | - |
12 | | - To build coderdbc you need to make next steps: |
13 | | - |
14 | | - 1 install cmake |
15 | | - |
16 | | - 2 download source code: |
17 | | - |
18 | | - `git clone https://github.com/astand/c-coderdbc.git coderdbc` |
19 | | - |
20 | | - 3 goto source code directory: |
21 | | - |
22 | | - `cd coderdbc` |
23 | | - |
24 | | - 4 run cmake configuration to 'build' directory: |
25 | | - |
26 | | - `cmake -S src -B build` |
27 | | - |
28 | | - 5 run cmake build: |
29 | | - |
30 | | - `cmake --build build --config release` |
31 | | - |
32 | | - 6 goto to build directory and run: |
33 | | - |
34 | | - `cd build` |
35 | | - |
36 | | - `./coderdbc` |
37 | | - |
38 | | - Call without argument will print instruction how to pass DBC file for generation |
39 | | - |
40 | | - ## Driver functionality description |
41 | | - |
42 | | - The full pack of source code (both generated and manually edited) will be looked this |
43 | | - (presuming that the dbc driver name is "ecudb"): |
| 3 | +Coderdbc is a CLI utility for generating C code from DBC CAN matrix files |
| 4 | + |
| 5 | +### Features |
| 6 | +- ***Pack*** and ***Unpack*** functions for conversion signals to CAN payload raw data and vice verse |
| 7 | +- ***Node based*** Receive function _(each node (ECU) has its own ***Receive*** function according to its DBC configuration)_ |
| 8 | +- Automation on monitoring functions: CRC, counter and missing tests |
| 9 | +- Optional source code generation _(the generation of readonly and configuration files can be avoided)_ |
| 10 | +- Flexible setup via driver configuration _(see comments in source code for details)_ |
| 11 | + |
| 12 | +## Build and run |
| 13 | + |
| 14 | +For building project you need to have cmake and c++ development toolkit in your system |
| 15 | +1 download source code: |
| 16 | +```sh |
| 17 | +git clone https://github.com/astand/c-coderdbc.git coderdbc |
| 18 | +``` |
| 19 | +Go to the source code directory: |
| 20 | +```sh |
| 21 | +cd coderdbc |
| 22 | +``` |
| 23 | +Run cmake configuration to 'build' directory: |
| 24 | +```sh |
| 25 | +cmake -S src -B build |
| 26 | +``` |
| 27 | +Run cmake build: |
| 28 | +```sh |
| 29 | +cmake --build build --config release |
| 30 | +``` |
| 31 | +Go to the build directory and run: |
| 32 | +```sh |
| 33 | +cd build |
| 34 | +./coderdbc --help |
| 35 | +``` |
| 36 | + |
| 37 | +Help information with main instructions about using the tool will be printed |
| 38 | + |
| 39 | +## Driver functionality description |
| 40 | + |
| 41 | + The source code package includes the following source files (presuming that the dbc driver name is "ecudb"): |
44 | 42 | |
45 | | - ecudb.c / ecudb.h (1) RO / lib |
46 | | - |
47 | | - Main driver which has all dbc frames structs / pack functions / unpack functions these |
48 | | - source files preferably to place in lib level directory because they are RO using model |
49 | | - and can be |
50 | | - shared among few separated projects. |
| 43 | + ecudb.c / ecudb.h (1) RO / lib |
51 | 44 |
|
| 45 | + 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. |
| 46 | + |
52 | 47 | ecudb-fmon.h (2) RO / lib |
53 | 48 |
|
54 | | - Contains monitoring functions signatures which can be optionally called from unpack frame. |
55 | | - Best option to place file beside Main driver files (1). |
| 49 | + 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. |
56 | 50 |
|
57 | 51 | ecudb-fmon.c (3) app |
58 | 52 |
|
59 | | - User defined functions with diagnostic purpose. DLC, rolling, checksum errors can be handled |
60 | | - automatically if specific configuration enabled. This file is user level source code. |
| 53 | + 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. |
61 | 54 |
|
62 | 55 | ecudb-config.h (4) app / inc* |
63 | 56 |
|
64 | | - This is application specific configuration file. If you have a few projects (applications) |
65 | | - which referenced on single main driver (1,2) then each project have to have own copy of this |
66 | | - configuration. Source code (1,2) includes this configuration. If a few dbc matrix is in use |
67 | | - in your application then for each of (1,2) specific configuration file must be presented. |
| 57 | + 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. |
68 | 58 |
|
69 | 59 | dbccodeconf.h (5) app / inc |
70 | 60 |
|
71 | | - This is application specific configuration file. This file may include "CanFrame" definition, |
72 | | - sigfloat_t typedef and binutil macros which enables rx and tx structures allocation inside |
73 | | - ecudb-binutil.c. This file must be single for application (see template dbccodeconf.h), source |
74 | | - code (4,6) includes this configuration. |
| 61 | + 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. |
75 | 62 |
|
76 | 63 | ecudb-binutil.c / ecudb-binutil.h (6) RO / app |
77 | 64 |
|
78 | | - Basically this is application specific file. This driver has one function which intakes CAN |
79 | | - message data and calls dedicated unpacking function. Function selection based on binary search. |
| 65 | + The part which is used for generalization CAN frame flow receiving and unpacking. It also optionally can allocate CAN frame tx/rx structs. |
80 | 66 |
|
81 | 67 | canmonitorutil.h (7) lib |
82 | 68 |
|
83 | | - This is lib level source code. This file is basic for all automatic monitoring functions. |
84 | | - This configuration file location have to be added to project include path. |
| 69 | + General definitions for monitoring feature. The source file can be place to the share/library directory. |
85 | 70 |
|
86 | 71 | ----------------------------------------------------------------------------------------------- |
87 | 72 |
|
88 | 73 | *inc - file location have to be added to project include path. |
89 | 74 |
|
90 | | - ## "-nodeutils" option |
| 75 | +## generation options |
91 | 76 |
|
92 | | - If your matrix has strict routing setup, where each CAN device (node) has defined collection |
93 | | - of TX frames as well as defined collection of RX frames the "-nodeutils" option may be used. |
94 | | - In this mode all the nodes defined in CAN matrix will be handled as specific ECU and |
95 | | - for each of these specific ECUs dedicated "###-binutil.c/h" pair of source code will be generated. |
96 | | - |
97 | | - See help output using details. |
| 77 | + There are several available generation option, use '-help' option for details |
0 commit comments