[Ovmsdev] CAN bus hacking

[Michael Balzer]

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.
>
>> On 19 Apr 2018, at 11:06 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>
>> 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180726/3cc4697e/attachment-0001.html>