[Ovmsdev] yacc/lex on component/dbc

[Mark Webb-Johnson]

The first implementation of this has been committed. It builds for me on Mac and Linux, but I had to do a ‘make clean’ on one of my boxes to make it compile properly (it was complaining about dbc_tokeniser.c missing - but that was old and replaced with dbc_tokeniser.cpp, so I guess an issue with a pre-compiled header somewhere). I’ve since tried updating the component.mk to workaround this (so it hopefully won’t happen again).

The overall result looks quite good. The dbc_parser.y file is clean, and we now support the important VERSION, NS_, BS_, BU_, VAL_TABLE_, BO_, SG_, VAL_, and CM_ sections. There are others in the DBC standard, but not commonly used and of little use to us; we can simply add if required. Code size is roughly 25KB of flash (including the dbcapp for command handling).

Using LEX/YACC after 30+ years was ‘interesting’.  The DBC grammar is not too complex, and tokenisation rather trivial, so not too hard to port. The next step in parsing DBC can simply be derived from the current token, so YACC’s LR parser is probably overkill for this, but anyway it provides a good solid foundation for reading DBC files, and supporting extensions to the grammar over time.

This is all in 3.1.011-60-g88dc859, which will go out tonight to ’test’ release level ota. At the moment, you can:

dbc load - parse and load a DBC file into memory
dbc unload - unload a DBC file from memory
dbc list - show a summary of loaded DBC files
dbc show - export a memory DBC file to DBC format

The last of these ‘dbc show’ will change later to be a summary of the messages/signals, and the ‘dbc show’ functionality moved to a new ‘dbc save’ command.

OVMS# dbc load TS /store/dbc/teslamodels_can3.dbc
Loaded DBC TS ok
OVMS# dbc list
TS: 3 message(s), 42 signal(s), 92% coverage

The 92% coverage figure is interesting. That is the number of signal bits decoded vs the total number of bits defined in messages. If all bus messages are in the DBC, it should give an indication of how much of the bus information has been decoded.

To recap, here is the overall master plan:

Support DBC files - loading and saving. These DBC files become the single place to document the broadcast message behaviour of each CAN bus for each vehicle type.

Migrate RE tools to be fundamentally based on DBC files - support DBC multiplexors (rather than RE tools unique keys), show DBC signal values, and allow for maintenance of the DBC (and, for example, auto-creation of messages based on what is seen on the bus). This will all be real-time.

Provide a web interface for RE tools and DBC file maintenance. Again, real-time (either from bus or simulated crtd captures).

Provide vehicle module support for DBC files, loading, and acting on CAN bus messages to produce metrics without code.

Implement something similar for OBDII-like polling architectures.

So, now we are at step #1. Pretty much done. The only issue I have is that DBC likes to use floating point numbers for everything (such as minimum/maximum values, offsets and scale factors, etc). That is horrendously inefficient for step #4 (and not at all optimal for #2). So, it would be good to have an opaque type for ’number’ that automatically switches between integer and floating point maths for this.

Onwards…

Regards, Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181130/631251c8/attachment.htm>