Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I fixed the signal packing for multiplex signals, issue #31
The new generated code takes into account the master multiplex value when generating the Pack functions.
I added an example dbc file test2.dbc that highlights the problem.
One of the messages in this dbc file is:
Here is a comparison of the generated code before this fix for the Pack function of the MUX_SIG_TEST1 CAN message from the test2.dbc file.
And now below is the generated code after this fix.
CAN messages with no multiplex values will generate the original style Pack functions this change only affects messages that contain multiplex signals.
Note1: For _d[0] the signals mux_master and signal1 are not affected by the value of mux_master so they appear in each possible multiplex master if statement. The other bytes d[1] to d[6] contain only the mux signals that are associated with each mux_master value.
Note2: For the case where the mux_master has a value that doesn't equal any of the expected multiplex signal values (e.g the last else statement for each byte) just pack all the multiplex signals for each byte as none of them are valid anyway. We could have tried only packing the master multiplexor and non multiplexed signals for this case but I don't think this would matter since all multiplex signal values would not be valid anyway for this case.