Add optional defmt::Format support for generated types.

[projectgus]

Add support for the low resource defmt logging system.

• Derived for enum types
• Formats messages by printing individual field values
• Enabled in can-messages test generation.

CAN messages are formatted by printing the fields, for example:

Vcu200(Vcu200 { RangeAdditionalClimateOff=0 CurrentGear=P RangeLSB=false Range=194 AccelPedal_Pos2=0 UnkStatus=0 Counter=0 AccelPedalPos3=0 }).

This is different to the current Debug support which just logs the enum name and the raw bytes, for example:

Vcu200(Vcu200([0, 0, 97, 0, 0, 0, 208, 0])).

My feeling is that it's always straightforward to log msg.id(), msg.raw() from the code, so having the structured formatting is useful.

defmt overhead is much less than Debug. In my embedded project which has 107 DBC Messages defined, using defmt to log an arbitrary Messages instance adds about 22KB of binary size. Using Debug (via Debug2Format) instead adds 85KB of binary size(!), despite the Debug output being less structured!! (Although to be fair most of this overhead is the one-off cost of including Debug formatting support.)

[tdittr]

This looks really nice :) The only thing I spotted that was missing was a #[derive(defmt::Format)] on the CanError.

[projectgus]

This looks really nice :) The only thing I spotted that was missing was a #[derive(defmt::Format)] on the CanError.

Thanks! CanError is a bit fiddly, as some variants include embedded_can::Id which doesn't implement Format. So we can't derive it. It would be possible to manually implement it, I guess...?

[tdittr]

Thanks! CanError is a bit fiddly, as some variants include embedded_can::Id which doesn't implement Format.

Ah that makes sense. It looks like embedded-can does already have support for defmt in main but not released it yet. I can ask about that at the next rust-embedded meeting tomorrow. I think implementing it by hand is not worth the effort.