You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello. I am currently trying to develop a Timer/Counter abstraction for a university project, and plan to contribute it back once done. While taking care of that, I noticed both existing macro code as well as my own (which I am modeling after the former) could be heavily simplified with paste. It is already a dependency of avr-hal, so would you accept a PR to refactor into using it for more than just Usart?
As an example, take impl_port_traditional. It's currently used like:
So far, this generates equivalent (I'm tempted to say identical) code. It retains control over:
Port letter/identifier;
Register type in pac;
Which pins are actually available for use (vs. reserved).
...but abstracts away the identifiers for fields and other types, which are constructed from concatenation via paste. This could be seen as a disadvantageous lack of granularity, but I don't think there should be much variation in the names used by the Peripheral Access Crates.
I'll try to push the preview implementation later today, to see if this could be useful.
The text was updated successfully, but these errors were encountered:
Hello. I am currently trying to develop a Timer/Counter abstraction for a university project, and plan to contribute it back once done. While taking care of that, I noticed both existing macro code as well as my own (which I am modeling after the former) could be heavily simplified with paste. It is already a dependency of
avr-hal
, so would you accept a PR to refactor into using it for more than just Usart?As an example, take
impl_port_traditional
. It's currently used like:With
paste
, I've been able to shorten to:So far, this generates equivalent (I'm tempted to say identical) code. It retains control over:
pac
;...but abstracts away the identifiers for fields and other types, which are constructed from concatenation via
paste
. This could be seen as a disadvantageous lack of granularity, but I don't think there should be much variation in the names used by the Peripheral Access Crates.I'll try to push the preview implementation later today, to see if this could be useful.
The text was updated successfully, but these errors were encountered: