Relationship with Embedded-HAL

[jonahbron]

What is the logical relationship between this project and Embedded-HAL? Would it make sense to modify this code (or fork a portion of the code) and make into an Embedded-HAL implementation for ATMega328p? It seems like that would enable the usage of all the available drivers on the Arduino Uno. But maybe there's more complexity here of which I'm unaware.

[jonahbron]

Through some more research, thanks to the awesome-avr-rust repo, I found my way to https://github.com/Rahix/avr-hal . This seems like the direction I need to go to get embedded-hal driver support. Is there any interest in refactoring this project to be based on avr-hal in the future to reduce duplicate effort?

[dylanmckay]

I think there's a usecase for both - a simple Arduino-like library, and an embedded-hal implementation.

You've noticed @Rahix's avr-hal crate, I'm fairly certain I've seen at least two other ports to AVR on GitHub around the place.

It would make sense to have a "blessed", or at least endorsed, AVR-hal implementation, similar to how the arduino crate is hosted under the avr-rust organisation. It also might be a good idea to create/transfer an AVR HAL crate to the avr-rust organisation and mention it in the avr-rust README.

The ruduino crate (formerly arduino) predates the embedded-hal library, which is the main reason for the current situation.

[Rahix]

So, funny thing @dylanmckay: I was thinking about asking if we should move my crates to avr-rust but was too afraid to ask so far as there is still so little to show. I don't know if you have taken a look at my work so far, so just as a small overview:

There are currently three relevant crates:

• atdf2svd: A tool to convert Atmel's atdf files to svd so we can make use of svd2rust. This supersedes the hackish manual approach I had in my first HAL attempt.
• avr-device: Register access crate generated using atdf2svd, svd2rust, and stm32-rs's svdpatch.py.
• avr-hal: Embedded HAL implementations for avr-device and a few board-support-crates (Arduino Leonardo, Adafruit Trinket + soon Arduino Uno & Bigavr6)

[jonahbron]

@dylanmckay @Rahix I agree it would make sense to consolidate the projects, I was going to suggest that too 😂

there is still so little to show

I don't think that's true, you've got demos with full GPIO and Serial support (that I've tested). There's more work to be done, but it's already useful in its current state

I think there's a usecase for both - a simple Arduino-like library, and an embedded-hal implementation.

In my (poorly informed) opinion, it stands to reason that the Arduino-like library would be an abstraction layer on top of avr-hal (or at least avr-device_, to share the registry definitions). Then we'd benefit from less duplicate code, while offering an optional higher-level interface that's closer to what a user might expect coming from Arduino IDE.

[dylanmckay]

I don't think that's true, you've got demos with full GPIO and Serial support (that I've tested). There's more work to be done, but it's already useful in its current state

Neat!

In my (poorly informed) opinion, it stands to reason that the Arduino-like library would be an abstraction layer on top of avr-hal (or at least avr-device_,

I agree. FWIW, whilst I think there's a need for something like a ruduino crate, I don't believe that should be the primary path (embedded-hal's platform-independence is much too valuable). It started out as a hobby project but then it made sense to move it to avr-rust due to lack of ecosystem at the time. If we can move a good HAL implementation to avr-rust, it might be a good idea to transfer ruduino out of avr-rust so that there is less dependence on it - after all, like Arduino, it is primarily a learning/educational platform, and if the "blessed" AVR library doesn't receive much love, perhaps it's better to let downstream crates fill the spot naturally.

Most of my time, and if I may be presumptious, fellow avr-rust contributor's time, is focused on the compiler as that is a hard dependency for every Rust AVR project out there and so we are fairly myopic with our focus on rustc as that brings the most value to the ecosystem when amortized over all the projects that do, or existentially could, depend on it. The devils advocate in me says that leaving ruduino under the avr-rust organization (and correspondingly, having the blink example use it) could be a disservice when there may be better, and more maintained libraries out there.

Anyone got any good AVR example programs (blink, serial, etc) that use embedded-hal?

I think it would be really good to create some kind of wiki page or README that outlines using embedded-hal on AVR, includes examples, and links to resources.

[dylanmckay]

Offtopic: does anyone have embedded-hal examples for analog IO for posting on #14?

[dylanmckay]

Data point: I just noticed the ruduino project has 237 stars, 62% of the stars of avr-rust. This means a sizable number of the people engaged on some small level with the project also engaged that same small amount with ruduino. Perhaps ruduino is overused - it would be strange if 62% of all C/C++ AVR projects used the Arduino platform rather than plain-old avr-libc or more serious embedded libraries.

[Rahix]

Anyone got any good AVR example programs (blink, serial, etc) that use embedded-hal?

I've got you covered :)

• Simple blink
• Serial communication
• Custom panic handler (using Serial)
• Clone of i2cdetect

[Rahix]

Offtopic: does anyone have embedded-hal examples for analog IO for posting on #14?

Sadly we miss an implementation for analog reads as well for now. embedded-hal has traits for ADC, we just need to add an implementation.

[Rahix]

@dylanmckay: avr-hal is still quite young, compared to ruduino. In fact, the current incarnation was started about one month back. We are a few guys working more or less actively on expanding the supported number of chips and peripherals.

The current state is summarized in the project's README and whats up next can be seen in the issue tracker. I'd love to have a more complete implementation to show you but as this was redesigned from the ground up after my first attempt, there is still a lot missing. Though I hope the new design allows adding those parts much quicker.

[jonahbron]

@dylanmckay I can totally understand not wanting to work on maintaining Ruduino. And I feel comfortable in saying that everyone greatly appreciates the work you and others have put into the compiler fork, and would like the focus to remain on getting it to a point where it can be merged upstream.

I humbly propose the following timeline:

1. avr-rust adopts avr-hal/avr-device
2. Auxiliary contributors (such as @Rahix or myself) flesh out avr-hal until it reaches feature parity with ruduino
3. Add documentation to Ruduino to suggest users consider using avr-hal depending on their needs
4. Auxilliary contributors alter Ruduino so that it uses embedded-hal traits instead of using its own implementation
5. Maybe? the HAL Team can be convinced to adopt Ruduino, since once it uses embedded-hal it no-longer depends on AVR and is useful for anyone getting into embedded Rust development no matter the platform. But no matter what it's no-longer avr-specific and needs a new home.

Expressed as Rust:

while !avr_device.supports_features_of(ruduino) {
    jonah_and_rahix.work_on(avr_device);
}
while !ruduino.calls_embedded_hal_traits() {
    jonah_and_rahix.work_on(ruduino);
}
let is_adopted = embedded_hal.adopt(ruduino);
if let Err(error) = is_adopted {
    Project::new().adopt(ruduino);
}