Start work on the architectural refactor #129
Conversation
To make some traits unimplementable, add a sealed trait to avr-hal-generic.
Rahix
added
hal-api
|
As a short breakdown for anyone interested:
I.e. the POC example is now cd examples/arduino-uno
cargo run --bin uno-blink |
|
Added support for basic USART, to see how it works out... I ran into one issue which popped up due to the new pins architecture: The current USART code was running into the orphan rule because I've mitigated this by wrapping the "raw peripheral" from the PAC in a |
|
All basic features for two boards are there now, looking okay so far. One big thing I am still unsure about: Right now I have each HAL and board-crate redefine the Either, only peripherals with a HAL implementation are available or we'd have to explicitly name all not-yet-supported peripherals for each supported MCU individually. I think option 1 would make the HAL pretty much unusable, but option 2 is a lot of manual code-writing... Anyone has ideas for an alternative solution? |
Replace the existing port implementation with a new design. With the new design, there is a single `Pin` type for representing pins and specific pins can be discerned via one of its generic parameters. One one hand, this eases visibility of the public API as it is no longer hidden inside a magic macro and on the other hand it allows to easily support the different IO cells of old and new AVR MCUs. Please refer to the included documentation in this commit for more details. Ref: #114
Adjust the `impl_usart_traditional!()` macro to support the new design of pin types. This leads to an interesting issue: Because with the new design, neither the type (e.g. `USART0`) nor the trait (`UsartOps`) nor the pin type are from the HAL crate, we run into the orphan rule. Mitigate this by expecting a newtype wrapper around the peripheral, and as such do the register accesses through a `.0` accessor. In the future we might want to make this accessor configurable.
Start with the new unified HAL crate for all ATmega MCUs. Start with support for ATmega328P's GPIO pins and USART peripheral. Instead of, like the previous HAL, exposing `pac::Peripherals`, the HAL now defines its own `Peripherals` struct. This allows us to more cleanly implement more complex peripheral support. For example, instead of individual fields for each port (PORTB, PORTC, PORTD, ...), the `hal::Peripherals` only has a single field `pins`, wrapping all of the above. Ref: #94
Create a unified crate for all arduino boards, to combat code duplication in the current design. As a start, add very basic support for Arduino Uno. This includes GPIO pins and USART communication for now. Additionally, include a `prelude` for reexporting commonly needed traits again. This crate, similarly to atmega-hal, exposes its own `Peripherals` struct. This struct uses fields and types more fitting for the selected board. For example, the `pins` field has subfields for each of the boards external pins, named appropriately instead of relying on the MCU pin names. Ref: #117
With a unified `arduino-hal`, we cannot keep examples in the crate in a convenient way. Instead, let's add dedicated examples crate for each board which demonstrate usage of `arduino-hal`. Start with a blinky and usart communication example.
Add basic (ports & usart) support for ATmega32U4 to atmega-hal.
Add basic support for Arduino Leonardo.
Rahix
force-pushed
the
the-big-refactor
branch
from
75d4bfe
to
4691d8f
Compare
|
@explicite, if you want to work on Arduino Mega2560 support, these commits can probably serve as a good basis: |
So, it's finally time: I've gotten around to starting work on the big refactor that got more and more inevitable from issues like #114, #94, and #117.
Right now, the state is just barely enough to blink an LED on Arduino Uno. I wanted to get this out as quickly as possible to initiate discussions on the design. As this work will take a while to complete, we will go about it like this:
masterstays with the current architecture for now until the new design reaches feature-parity. Until then, we will use thenextbranch to get it there. Thus, this PR will be merged intonextinstead ofmaster.TODO
portmodule.