I'm trying to add attiny support to arduino-hal and I was wondering if there's anyone who could help with some of the trickier generics/trait bounds
Although I am not quite sure, what you want to do? attinies by themselves belong into attiny-hal
So I need to figure out how to move the mega-specific stuff into
atmega-hal and make avr-hal-generic generic to allow a corresponding implementation in attiny-hal
what in particular? the only mega-specific things should be contained in the impl_* macros
so for tiny, the idea would be to write a second impl_* macro in avr-hal-generic which can then be used in attiny-hal
Likewise the
adc module has ReferenceVoltage baked into avr-hal-generic, though I think I've already successfully teased that apart.
well Baudrate should stay a type valid for all supported MCUs, not a HAL specific one, IMO. But I agree that we need to maybe move the calculation logic into the mega-specific impl_ macro instead, to accommodate for attinies
If it's a generic type then it shouldn't have ubrr and u2x fields.
1 reply
Shouldn't Baudrate be a trait, with HAL-specific implementations?
Why does that require a concrete type?
As long as the HAL-specific type implements From<i32>...
Here's what I'm noodling with:
Introduce a
UsartHal trait with associated types Event and Baudrate
although there is this added complication with the BaudrateArduinoExt which implements some board-specific errata
The problem I'm having is that I can't figure out how to shove CLOCK into that
since
Baudrate needs to be Baudrate<CLOCK>
it seems like that
CLOCK needs to propagate up the type tree into UsartHal<CLOCK>
but that also seems wrong to me because that's baking in the assumption that baud rate calculation is based on a clock
I'm not sure we should assume that all usarts require a clock
for example, a usart in synchronous mode does't need a clock
right, but you could always set CLOCK to a placeholder type for those cases
(I also think
Usart is a bit misnamed... it seems to me like it only supports asynchronous mode right now)
You could, but it feels like it's maybe the wrong abstraction layer
I feel like there should be a HAL-specific UsartSettings type
e.g. with bits/parity settings as well
(currently hardcoded in
raw_init)
yeah, this could work well. So raw_init takes
UsartSettings which is an associated type of UsartOps
1 reply
What is the reason most of these types take an H type parameter that is just an empty struct called Atmega?
because were implementing a foreign trait for a foreign type...
Do you think you could take a look at the WIP branch I have with the ADC changes to see what you think?
Would you mind glancing at https://github.com/Rahix/avr-hal/compare/main...quentinmit:attiny167 ?
Currently on my way to work, but I can take a closer look this evening if that's alright with you
It's 01:50 here
I... should be awake again by then :P
Maybe open a draft PR already, that's the best way to keep track of everything :)