Defmt support for enums and structs

[haata]

• Hidden behind defmt-impl feature (similar to how heapless handles defmt)

[stappersg]

But why?

Longer version: The pull request has been seen, not yet seen by me is what it improves. Consider that it is me who isn't seen the larger picture. Please elaborate defmt and tell what it makes better.

[haata]

USB tends to be timing sensitive, so in order to add logging inside a USB hal crate (what I'm currently working on https://github.com/atsam-rs/atsam4-hal/pull/49/files) defmt is necessary.

My current development flow is to use probe-run + defmt for logging and bracktrace support. defmt (https://ferrous-systems.com/blog/defmt/ is a good read, but I'll give the tl;dr here) strips out debug messages from the firmware, places it on the host side, then uses a protobuf-like mechanism to pass any necessary arguments back to the host to reassemble the print message. The benefit, significantly smaller firmware images (if you have lots of messages) as well as faster logging as fewer bytes need to be sent over the debug link (e.g. RTT).

If these derive macros aren't added, I would need to maintain either a fork or wrap each enum and struct with another struct in order to handle log message formatting.

Does that make sense?

[stappersg]

On Tue, Aug 24, 2021 at 12:45:19AM -0700, Jacob Alexander wrote:

USB tends to be timing sensitive, so in order to add logging inside a USB hal crate defmt is necessary.

... further good text ... ...(https://ferrous-systems.com/blog/defmt/ is a good read ...

Does that make sense?

Yes, it does.

It's worth to add to the commit message.

[haata]

Sorry for the delay, I've been under the weather.

[haata]

Done

[haata]

Thanks!

[ryan-summers]

No problem - thanks for the help! :)