-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add port implementations for AVR XMEGA / ATtiny404 #357
base: main
Are you sure you want to change the base?
Conversation
The generated machine code looks okay, all the I/O memory and SRAM accesses look correct. (Note, it may be difficult to find a GCC toolchain that has support/specs for attiny404. I got this crate to compile successfully using the toolchain packaged with Arduino IDE 1.8.19) |
I think I noticed a logic error in the open-drain implementation.
avr-hal/avr-hal-generic/src/port.rs Lines 152 to 171 in 8e4ba8f
... and also, avr-hal/avr-hal-generic/src/port.rs Lines 338 to 348 in 8e4ba8f
Because of this, the state of the XMEGA This wasn't a problem in other MCUs, because the pull-up state shares the same register as the output driver ( An easy fix for this would be to explicitly call |
Ooh, this looks interesting! I don't have time right now to look at it in more detail, but you may also want to check #139 to see how your work compares. I would assume yours to be more thorough, though... |
Oh, nice! They look pretty similar. The The other differences I noticed:
|
Yeah. The trick here is that the match will be optimized out so only the single correct option will actually end up in the final program. This way I can avoid having to pass yet another identifier.
I think you're right. I didn't look into it too deeply, my main goal was making a PoC so I can see whether the general structure of the |
I think I would err on the side of generating less code, even if the Having "yet another identifier" is not really that costly, especially compared to The ideal compromise between less code and less input/identifiers would be using something like Another option is syntax matching using macros - this one could be invoked by #[macro_export]
macro_rules! pinXctrl {
(0) => { pin0ctrl };
(1) => { pin1ctrl };
(2) => { pin2ctrl };
(3) => { pin3ctrl };
(4) => { pin4ctrl };
(5) => { pin5ctrl };
(6) => { pin6ctrl };
(7) => { pin7ctrl };
} I don't know whether I would prefer this over simply passing the identifier as input to the |
I just noticed the avr-device 0.5 release, I will rebase this PR tonight. |
f6b3634
to
001e030
Compare
This is my first time working with an XMEGA microcontroller. The XMEGA register maps are quite different from the ATmega / ATtiny ones I've seen, so I figured it would be best to start a separate crate for it.
This hasn't been tested on hardware yet; I'm expecting to receive the parts and prototype boards in mid/late November.
I also copied the delay re-export from attiny-hal, though I haven't checked if there are any differences in instruction timing that need to be accounted for.