Mark,
I'm not familiar with DBC. I only found partial community infos and
examples and an 11 year old PDF that seems to be available in two
versions -- is that the current specification?
https://kupdf.net/download/dbc-format-2007_59c7d97e08bbc5f7236872bc_pdf
https://wenku.baidu.com/view/41c36d25ed630b1c59eeb534
Is it possible to define a command/query scheme in DBC?
Thanks,
Michael
Am 26.07.2018 um 11:13 schrieb Mark
Webb-Johnson:
I’ve spent quite some time looking at the alternatives, with the
result that no matter how much I hate the specification, how
horrible I think the format is, how terribly designed is the
syntax, DBC is the standard that everyone seems to want to follow.
For our holy grain of DBC signals -> OVMS
metrics, we can use ‘attributes’ to define OVMS specific stuff
(like signal name to OVMS metric names).
So, I’ve created a DBC component, and put in the
basic structures to define the objects in a DBC file. I’ve also
started the work to parse DBC files and load them in. The basic
idea is:
- There is a core MyDBC object.
- DBC files can be loaded into that object (either
from VFS, or as static strings), unloaded, etc.
- The MyDBC object will contain functions to access
DBC files, and maintain them.
- Functions will also be provided to export DBC
files.
- Statically loaded (via strings) DBC objects can
be overwritten and modified (especially during development).
- The vehicle base class will be extended to allow
a DBC file to be associated with a particular CAN bus - that
will then automatically handle metrics from DBC signals.
- RE TOOLS will be changed to use DBC files
directly (in particular to use DBC modifiers, rather than
the current unique ID approach, but also for things like DBC
signal extraction and display).
The overall goal is:
- The ‘old’ (current) way of doing things is to
write C++ code in a vehicle module to match CAN bus #1, ID
0x102, and treat byte #3 an unsigned integer to set it as
the SOC metric.
- The DBC way is to instead create a DBC file
describe CAN bus #2, message ID 0x102, and a signal at byte
#3 (16 bits in, length 8 bits) mapped to the SOC metric.
Then, just tell the vehicle base module where that DBC file
is and let it handle the mapping automatically. No code.
Just DBC description files.
- We can still have custom C++ code, for custom
metrics.
- When reverse engineering, we can dynamically
modify a loaded DBC and instantly see the metrics change. We
can then export that DBC out, and include it in the firmware
for others to use.
The biggest amount of work is the DBC file handling
itself. The changes to the vehicle base class are pretty simple.
Regards, Mark.
The whole decoding/encoding thing
(where we use DBC or whatever to say key X byte Y is
converted to v.bat.soc using this formula) is of course
the holy grain of this; and is built upon all the
foundation I’m laying now. The end goal remains for
vehicle modules with just a DBC (or whatever) and no
actual code.
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26