Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit63fd84c

Browse files
committed
New readme 1st edition.
Readme update.
1 parent2b85200 commit63fd84c

File tree

1 file changed

+51
-71
lines changed

1 file changed

+51
-71
lines changed

‎README.md‎

Lines changed: 51 additions & 71 deletions
Original file line numberDiff line numberDiff line change
@@ -1,97 +1,77 @@
1-
#CODERDBC
1+
#CODERDBC
22

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+
--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"):
4442
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
5144

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+
5247
ecudb-fmon.h (2) RO / lib
5348

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.
5650

5751
ecudb-fmon.c (3) app
5852

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.
6154

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

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.
6858

6959
dbccodeconf.h (5) app / inc
7060

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.
7562

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

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.
8066

8167
canmonitorutil.h (7) lib
8268

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.
8570

8671
-----------------------------------------------------------------------------------------------
8772

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

90-
##"-nodeutils" option
75+
##generation options
9176

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

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp