Hi friends of CAN codegen!

[killercup]

Hey, since there were a bunch of amazing contributions recently, I thought I'd enable the discussions feature on the repo and say hello to @marcelbuesing and @andresv here! 👋

Quick backstory: I made this crate last year together with @bitbleep for an internal proof of concept we are working on at @technocreatives (targetting a nrf52). As you know, it's based on Marcel's can-dbc parser, and supposed to be a bit lower level than his dbcc. Currently, we don't have an active project using it but that will most likely change soon.

What are you guys up to? 😃

[andresv]

Well I need something that is able to parse comma.ai dbc files: https://github.com/commaai/opendbc.
can-dbc can almost do it. It seems comma.ai files are not strictly following standard. However I cannot use can-dbc to generate actual CAN message payloads and here dbc-codegen comes into play.

In the future I would like to do generation in build.rs then I do not have to commit huge messages.rs to git. It will be built only if needed. At the moment dbc-codegen is a separate program, I would prefer it to be a lib. So I can do this in build.rs:

dbc_codegen::generate("my.dbc", "src/dbc", "mymessages")?;

This would generate mymessages.rs from my.dbc and writes it to src/dbc.

[killercup]

Cool, hadn't seen comma.ai yet! Seems like a super good test case!

However I cannot use can-dbc to generate actual CAN message payloads and here dbc-codegen comes into play.

Do you want to generate random messages? Would it make sense to add a feature flag to implement the Arbitrary trait on the structs we produce?

At the moment dbc-codegen is a separate program, I would prefer it to be a lib.

That sounds totally reasonable. I'll also publish it to crates.io once it's know to work with more files :)

Edit: Created #11 to track the librarification

[marcelbuesing]

Cool, hadn't seen comma.ai yet! Seems like a super good test case!

However I cannot use can-dbc to generate actual CAN message payloads and here dbc-codegen comes into play.

Do you want to generate random messages? Would it make sense to add a feature flag to implement the Arbitrary trait on the structs we produce?

At the moment dbc-codegen is a separate program, I would prefer it to be a lib.

That sounds totally reasonable. I'll also publish it to crates.io once it's know to work with more files :)

Edit: Created #11 to track the librarification

I think adding a Arbitrary trait implementations would be really great for testing especially since the dbc should provide all necessary input.

[marcelbuesing]

Hi, thanks for making dbc-codegen public. I kind of stopped working on dbcc since I actually like your implementation better.

I personally think Rust is language wise a great fit for the dbc domain (e.g. automotive) and all that is missing so far is basically tooling (e.g. dbc-codegen) and crates for protocols used in that domain (UDS, ISOTP...), at least for initial adoption. So I'm glad to see projects like dbc-codegen, bxcan ... exist.

Regarding can-dbc it probably should be more lenient when parsing or at least give better error messages that indicate where the issue occurred, so please feel free to add issues or PRs.

[killercup]

Thanks for the kind words and all your contributions to the ecosystem!

I agree (obviously 😉) -- with a little bit of tooling Rrust can make communication over CAN pretty convenient. I haven't worked with UDS etc. myself but I'd be pretty curious to see what this would look like in Rust.

[killercup]

Btw, one of the main obstacles with anything CAN for me as a non-automotive guy was to find good documentation. I think so far I pretty much just reverse engineered other implementationns. Does one of you have a good source? Any kind of spec (on DBC, message formats, UDS, what have you) would be super good to have.

[marcelbuesing]

I understand your pain when it comes to availability of documentation. The problem e.g. with dbc I don't think it was a format intended to be used outside of Vector software. For other things such as UDS there are ISO documents which sadly cost money ...

[andresv]

I haven't found anything and I still do not know if https://github.com/commaai/opendbc files are off the spec and actually it is OK if can-dbc is unable to decode them.
Yes there were some obvious mistakes like sometimes ; was missing from the end of a comment.
But should dlc file always begin like this:

VERSION ""

NS_ :
    NS_DESC_
    CM_
    BA_DEF_

Or are other fields also allowed and VERSION comes later.

[marcelbuesing]

So DBCs generated by the Vector Tools I think are always in that order. One might say that makes it the rule. I think can-dbc could be more lenient but I am not sure whether opendbc is actually a good source for well structured dbcs as it looks like their file structure comes from some of their tools. I guess it would be interesting to try to import one of those files into a Vector tool and see if that works.

[killercup]

Hi @projectgus and @JoNil! I just went thru the backlog of open PRs and saw you two have been quite active in this repo! Just wanted to say hi and invite you to share your use cases and plans for this project here as well.

We from @technocreatives have some use cases for it but we're not actively developing it. I don't want to be a bottleneck for this crate being useful to you! I'll happily merge reviewed PRs with a quick description for the motivation and do releases :)

[projectgus]

Thanks @killercup for the kind and thoughtful response to my unsolicited patches. 😆

Like andresv, I am also working with DBC files generated by comma.ai tools. Although in my case I'm just using their Cabana log analysis tool, and I'm not doing anything related to comma.ai's products or self-driving.

I have a personal project where I'm reverse engineering a Hyundai EV's drivetrain systems to use in EV conversions. (More here). Planning to eventually open source the whole thing.

My workflow has been to build up a DBC file using Cabana for CAN log analysis. I had initially written host Python code (with python-can) to interact with the Hyundai modules, but now I'm porting this to Rust (no_std, rtic, bxcan). dbc-codegen has been super useful for being able to quickly bring the DBC contents into Rust. ❤️

However, long term I need to write a fairly complex controller firmware and I'm not sure if dbc-codegen will end up being the right fit. I may manually write the necessary CAN payload serializers/deserializers, or I might go the total opposite and try to do something similar to dbc-codegen that leans into the type system a bit harder (i.e. make signals into types, support more generic traits over signals and messages).

Still thinking this part through, I'm not a Rust expert so it's possible I'm just going mad with the freedom of a real type system for embedded. 🤣