Comments (11)
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 ofsvd2rust
. This supersedes the hackish manual approach I had in my first HAL attempt.avr-device
: Register access crate generated usingatdf2svd
,svd2rust
, andstm32-rs
'ssvdpatch.py
.avr-hal
: Embedded HAL implementations foravr-device
and a few board-support-crates (Arduino Leonardo, Adafruit Trinket + soon Arduino Uno & Bigavr6)
from ruduino.
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?
from ruduino.
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.
from ruduino.
@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.
from ruduino.
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.
from ruduino.
Offtopic: does anyone have embedded-hal examples for analog IO for posting on #14?
from ruduino.
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.
from ruduino.
Anyone got any good AVR example programs (blink, serial, etc) that use embedded-hal?
I've got you covered :)
from ruduino.
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.
from ruduino.
@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.
from ruduino.
@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:
- avr-rust adopts avr-hal/avr-device
- Auxiliary contributors (such as @Rahix or myself) flesh out avr-hal until it reaches feature parity with ruduino
- Add documentation to Ruduino to suggest users consider using avr-hal depending on their needs
- Auxilliary contributors alter Ruduino so that it uses embedded-hal traits instead of using its own implementation
- 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);
}
from ruduino.
Related Issues (20)
- Shouldn't all IO registers use volatile operations?
- Differences between ports and other registers is jarring HOT 2
- WaveformGenerationMode / ClockSource are private
- `Register` trait is unsound HOT 1
- cores to structs (code architecture)
- Make `Register::set` use `volatile_write` HOT 2
- Compiling for ATmega4809; "no register group defined for this port" HOT 2
- Docs.rs is complaining this won't compile HOT 3
- When the ruduino compile, that fail by support error for LLVM. HOT 1
- no value available for environment variable 'AVR_CPU_FREQUENCY_HZ' HOT 1
- other atmega than src/cores
- #[feature(const_fn)] removed on latest rust nightly HOT 1
- Where does `timer1` in the README come from? HOT 1
- #![feature(unwind-attributes)] has been removed? HOT 1
- "out of registers" build error HOT 3
- wish: publish at crates.io
- Add .devcontainer
- ATmega32U4 support: collect register definitions from multiple modules HOT 1
- Timer configuration for interruptless mode
- Is this project still supported? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ruduino.