Add support for dbcs with extended multiplex messages #8
Conversation
src/lib.rs
Outdated
| @@ -747,13 +767,26 @@ impl DBC { | |||
| } | |||
|
|
|||
| /// Lookup the message multiplexor switch signal for a given message | |||
| /// ToDo This does not work for extended multiplexed messages. | |||
There was a problem hiding this comment.
I'm wondering if it makes more sense to turn the Option into an Result type or even a Result<Option<&Signal>>, from a library user perspective I think I personally would probably prefer being aware of a possible failure by the type signature instead of running into a runtime error. What do you think?
There was a problem hiding this comment.
In my opinion Result<Option<&Signal>> would be better as it clearly distinguished between the cases: no multiplexer and a extended multiplexing.
|
Hey thanks for bearing with me. This looks really great. Also thank you for adding the reference to the documentation I was not even aware this is possible. Lets figure out the best option for this one question. I'll merge afterwards and release a new version. |
|
Thanks so much again. I just tagged and released |
Parsing a DBC file with extendend multiplexing (multiple and possibly nested multiplexors per message) results currently in a partly parsed file.
Extended Multiplexing is described here: https://cdn.vector.com/cms/content/know-how/_application-notes/AN-ION-1-0521_Extended_Signal_Multiplexing.pdf
I added support, but the
message_multiplexor_switchfunction makes no sense for multiplexed messages. Any suggestions how to handle that?