mask the dbc id

[schphil]

hi, thanks for the work so far.

for extended 29-bit CAN IDs a mask needs to be applied.

[marcelbuesing]

Hi,

thank you for your PR. I think the problem with that would be that you are losing the information whether a message id is a 29bit extended frame id or only a 11bit id base frame id. I think it should be up to the application / library using the id to mask it. Maybe an idea could be to e.g. turn the messageid into an enum type similar to this: https://docs.rs/embedded-can/latest/embedded_can/enum.Id.html

The DBC ID adds 3 extra bits for 29 bit CAN IDs to serve as an 'extended ID' flag Source

[marcelbuesing]

Just noticed that you are working on dbc-codegen. I think it would basically make sense to do that masking in that case in dbc-codegen. But as mentioned it might make sense to include some way to make it less error prone using the can-dbc crate as well, because I am sure otherwise others will run into this as well.

[schphil]

Hi, thanks for your response. I would like the idea to turn the MessageId into an enum.

pub enum MessageId {
    Standard(u16),
    Extended(u32),
}

As it is now I read the documentation as MessageId contains the actual can id not just the dbc message id.

[erzoe]

Hi, thank you for this crate and this pull request. I have opened a new pull request which implements the MessageId enum proposed by schphil and updated the tests accordingly. https://github.com/marcelbuesing/can-dbc/pull/13

[kistenklaus]

I believe this crate is actually used by a lot of people, working with CAN dbc and code generation, therefor changing the interface might be problematic, i added a really short PR, that adds utility for MessageId #14. But i think that #13 is also a good solution =^).

PS. Love the lib <3

[marcelbuesing]

Thanks again I am closing this due to the changes in #13