Drop custom Peripherals structs and RawPeripheral newtype wrapper
#152
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It seems the approach of defining a custom `Peripherals` struct does not scale well: We'd need to replicate all the fields from the respective MCUs `Peripherals` struct to provide a usable API. But doing so would be a huge effort. Instead, look for a design where the custom `Peripherals` is not needed. As a first step, convert the `Pins` initialization to a macro-based approach. A `pins!()` macro is provided which moves the relevant fields out of the `Peripherals` struct. This must be a macro because it must happen as part of the `main()` function where the `Peripherals` instance can linger in its partially moved state.
Also drop the custom `Peripherals` struct which is found in the `arduino-hal`. Provide the same `pins!()` macro here as well, just with board pins instead of MCU pins.
Use the new pins initialization which is based on a macro in all blink examples.
Because HAL crates neither own the `UsartOps` trait nor the `USARTn` instance, they are not allowed to implement it for the type. However, the orphan rules allow us to deal with this by adding a generic parameter to `UsartOps` which is local to the HAL crate. The new `H` parameter serves exactly this purpose and nothing more. A HAL should define a type and use it for `H` in all HAL implementations. Ideally, it should also export type-aliases for all types from `avr-hal-generic` with the `H` parameter already substituted.
`UsartOps` is no longer meant to be implemented on newtype-wrappers and as such the .0 field accessor is now superfluous. This partially reverts commit 9c33514 ("generic: usart: Introduce a type-parameter for orphan circumvention").
Drop the RawPeripheral() wrapper type and instead use a marker called `Atmega` to deal with the orphan rule. Update macro invocations to fit with the new design in avr-hal-generic.
Use the new `pins!()` macro.
Rahix
added
hal-api
42 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sadly it seems this approach is not going to work well, so we will have to follow a different route. Already, the following problems are showing prominently:
Peripheralsstruct, we need to manually add fields for all peripherals of all MCUs we support. This is not going to scale well.Peripheralswill look differently, this is going to look very confusing.Going back to the svd2rust generated
Peripheralsonly, we also have to drop theRawPeripheralnewtype. I tried different solutions here and just dropping it entirely does seem to be the best looking. Instead, I added a special type-parameter inavr-hal-genericwith the sole purpose of circumventing the orphan rule which seems to work out quite nicely. See commit 9c33514 for details.