esp-rs
ETM configuration is a one-time operation
Motivations
Due to how various APIs of the event task matrix system are designed (especially EtmConfiguredChannel, gpio::etm::TaskChannel/Task among others), each channel (in the ETM, and in the peripherals that support ETM functionality) can only be configured once. In terms of hardware, at least from what I am reading (specifically ESP32-C6 technical reference manual), it should be possible to reconfigure the ETM at will, though some specific sequence of “deconfiguration” is usually required.
My use case for ETM is to run blinking status LEDs without CPU involvement, but those LEDs need to switch to constant on/off (or even PWM fade in the future, possibly) at certain points. It would be most convenient if I could simply deconfigure ETM to regain ownership of the GPIO pins involved. For now, I have to do some hacks to wait for the LEDs to be in the correct on/off state, then stop the timer, with the ETM configuration still active, and ready to be restarted later on.
Solution
Most ETM functions should use &mut self and return some kind of lifetime’d handle struct (could be the existing structs themselves) that holds a (PhantomData) mutable reference to the parent structure they were created from. E.g. for gpio::etm: Channels -> Task and EtmChannel -> EtmConfiguredChannel. Dropping one would then free up the parent again. This way, the borrow checker can be used to make sure that no misuse of the peripherals happen. This kind of approach is commonly followed across HAL crates and already exists somewhat with EtmChannel::setup’s arguments (though it should also take &mut self)
Alternatives
None?
Additional context
Thanks - I see much value in having the ETM driver more flexible. The current driver is far from complete and even more far from perfect. Having a safe and flexible API is something we should aim for. ETM is a bit special in that it involves multiple peripherals which might make it a bit more challenging to reason about. PRs are certainly welcome - I don't see that driver getting stabilized any time soon, so we are free to experiment regarding the final design
