-
Notifications
You must be signed in to change notification settings - Fork 221
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
Consider merging (some) HAL crates #94
Comments
This wikipedia article groups the ATtinys into 4 groups (not including the newer generation, which is pretty clear about its grouping). I'm not sure what exactly the process is for that, but it seems to be mostly by architecture? I'm not sure how useful it would be to use that in this case, but if the goal is just to reduce the number of crates, it seems like a reasonable metric. Otherwise, I'm a fan of splitting by |
Hmm, I also found this Stackoverflow Answer which might give a good base:
I think we can group some of them even more. For a start, I'd (without looking deeper) group the ATmega devices like this:
for the others, we don't currently have any devices supported, so we can take care of them later. For the ATtiny devices, I think we can try to merge the info from your link with this kind of 'generation' numbering scheme, to derive a sensible partitioning. What also needs to be evaluated is how to name those crates ... Not sure what would be intuitive. |
It is pretty difficult. I remember when I wrote a C library about 18 years ago it was difficult with the different ATmegas. Nowadays, with the new devices from Microchip, it becomes even worse, because their peripheral is totally different. You can try to put pin compatible devices like ATmega8/48/88.. into one crate. Also all 40 pin, all 64 pin and 100 pin. But even there it becomes a mess sooner or later. I assume that the original Atmel AVRs and the new Microchip AVRs need to be completely separated from each other. Even the IO ports are different. You need to write new drivers. |
Luckily we have one very big advantage in Rust: We can create very rich abstractions without impacting the generated code at all (= zero cost). I think it should not be too difficult to build HAL drivers that hide all this mess from downstream users. We just have to carefully evaluate where to draw the lines.
Yeah, I totally agree. I think those are what Microchip calls the 0-series devices (e.g. ATmegaXX08/09). I want the basic driver functionality (user facing API) to be the exact same for old and new devices. For any additional features found in the newer ones, additional API can be provided alongside. |
Seems to me like all the relevant information has been collected, and all that's left is to make a decision. I'm not sure if this assumption has already been made, but I think it's safe to assume that Microchip's future AVR chips will have well-defined boundaries (series 0,1,2, etc.), which can easily be categorized into their respective crates. For the rest, I think littering the code with Based on my understanding, the only thing this changes from a user perspective is how the crate is imported in Anyway, my opinions:
tl;dr: I support either the nuclear split or splitting by architecture |
Start with the new unified HAL crate for all ATmega MCUs. For now, only support ATmega328P with just a GPIO-pins implementation. Ref: #94
Okay, I decided to go with the "nuclear" split for now in #129. We can always resplit later on if this turns out to be infeasible, but at least it gets us moving forward from the current situation. Sorry for the long delay... |
Glad to hear the decision has been made! Just to clarify, are the newer series-0/1/2 chips getting their own category? and if so, are they each getting a crate or are they all being combined into one big |
Right, sorry for the long wait...
Yeah, they will at least be separate from |
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
From my perspective as the maintainer of
avr-hal
, the HAL crates are becoming more and more of a burden to maintain because any global change needs to be reflected in each one. There is a huge amount of code-duplication across the HAL crates which is not helping with this.I think it makes sense to look into merging at least some of the HAL crates, for chips where the differences are small enough that
#[cfg()]
s can be used to differentiate between them.The big question is where to draw the lines, what MCUs should go into which HAL crate:
ATmega
/ATtiny
into a crate. This would leave us with the minimum number of crates but a mess of#[cfg()]
s to manage them.IMO we need to larger grouping than the "Microchip Families" but just forcing all
ATmega
/ATtiny
devices into a single crate also looks scary. The latter might still be manageable now, but looking into the future, with more and more devices being supported, I can see it becoming a large mess.Not yet sure what to do ...
Proposals
"Nuclear" Split,
atmega
/atxmega
/attiny
Pros
Cons
#[cfg()]
s to differentiateSplit by Architecture
Pros
Cons
Split by Generation/Series
Original Comment:
Pros
Cons
Split by Family
Pros
Cons
The text was updated successfully, but these errors were encountered: