<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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).<div class=""><br class=""></div><div class="">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).<br class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">This is all in 3.1.011-60-g88dc859, which will go out tonight to ’test’ release level ota. At the moment, you can:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">dbc load - parse and load a DBC file into memory</li><li class="">dbc unload - unload a DBC file from memory</li><li class="">dbc list - show a summary of loaded DBC files</li><li class="">dbc show - export a memory DBC file to DBC format</li></ul></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">OVMS# dbc load TS /store/dbc/teslamodels_can3.dbc</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">Loaded DBC TS ok</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">OVMS# dbc list</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">TS: 3 message(s), 42 signal(s), 92% coverage</span></font></div></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">To recap, here is the overall master plan:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">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.<br class=""><br class=""></li><li class="">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.<br class=""><br class=""></li><li class="">Provide a web interface for RE tools and DBC file maintenance. Again, real-time (either from bus or simulated crtd captures).<br class=""><br class=""></li><li class="">Provide vehicle module support for DBC files, loading, and acting on CAN bus messages to produce metrics without code.<br class=""><br class=""></li><li class="">Implement something similar for OBDII-like polling architectures.</li></ol></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Onwards…</div><div class=""><br class=""></div><div class="">Regards, Mark.</div></div></body></html>