avr-rust
What is the scope / planned level of this library going forward?
Hi! I'm looking to code Rust on Arduino. I love the Arduino platform, and Rust intrigues me. I just have a couple questions:
Is this designed to be a low level library? Are there plans to make it higher level (less unsafe code, for instance)? What is the scope of this library going forward?
Thanks in advance! 😄
PS: Sorry if this is the wrong place for questions, I wasn't sure.
An instance of what I mean is that currently the serial module is quite low level - providing just sending per-character. It could be extended to be more like the standard Arduino library - with print, println, etc
Is this designed to be a low level library?
Are there plans to make it higher level
I think there are many kinds of "lower" and "higher" levels to be had here — it is embedded after all 😇
I think the answer is "yes" to both. I'd like to see it provide lower level abstractions and then higher level abstractions on top of them.
less unsafe code, for instance
I think a large goal of this library is to provide the safe wrappers around unsafe code. Hopefully, most users of this library will not need to write much unsafe code themselves.
It's not a goal for the implementation of the library to have less unsafe code.
What is the scope of this library going forward?
the serial module is quite low level - providing just sending per-character. It could be extended to be more like the standard Arduino library - with print, println, etc
My plan is to eventually implement core::fmt::Write so that you could do something akin to
writeln!(SomeSerialPortType, "format string {}", 42).expect("nope");
This relies on some LLVM bugs going away first, though.
It's possible we may want to have some "default" println implementation, but there's no One True Stdout stream in the embedded world, so this is dubious!
Thanks for answering! In regards to the println! implementation -- yeah, it'd be difficult to figure out exactly which serial port should be used. Perhaps it could be passed as a flag when building, or configured otherwise. I see what you mean about the implementation not being unsafe -- that is quite unavoidable, and to be honest a lot of the "unsafe" code is really quite safe (it'd be unsafe in any other setting, though).
Implementing traits on things (e.g Write on serial) would be really cool -- it'd help make it "feel" higher level, while leaving you space to write however low you want to (yay for 0 cost abstraction).
and to be honest a lot of the "unsafe" code is really quite safe
Remember that the unsafe keyword means "the code inside this block upholds all of Rust's safety rules, but the compiler cannot verify that is the case". Unsafe code isn't bad by any means, it's just something you want to spend more time on as a human to verify it's safe. Ideally, you then provide safe wrappers around that code.
it'd be unsafe in any other setting
What kind of setting do you mean?
What kind of setting do you mean?
Say, I wouldn't go around setting arbitrary memory values on my PC
Say, I wouldn't go around setting arbitrary memory values on my PC
You certainly might, if you were writing an OS in Rust.
I'd say that in many cases, this library would provide functionality that is lower than a "true" OS, but also some pieces that would be higher level because there's no OS.
You certainly might, if you were writing an OS in Rust.
Fair point. Let's say that I wouldn't set arbitrary memory values in many settings, such as writing for computers with os's
(I'm not sure whether this should go here, thought maybe because it's about the library's future)
What about renaming this to something like avr-hardware-utils or avr-hardware? It doesn't seem to be particularly exclusive to arduino's themselves (is it?)
renaming this to something like avr-hardware-utils or avr-hardware?
I think renaming might have to happen for copyright concerns, but I think we can fly under the radar for a while. Hopefully by then, we will have a better understanding of what the library should and shouldn't do to help guide a name :-)
renaming might have to happen for copyright concerns
Fair point!
we will have a better understanding of what the library should and shouldn't do to help guide a name :-)
Sound desicion.
Hijacking this issue, but what's the long term plan for this crate regarding things such as embedded-hal? It would make sense (I think?) to have ruduino built upon embedded-hal implementations for the various chips, but right now it is not.
@shepmaster You mentioned embedded in this comment but that was more than a year ago. What's your take on this matter now?
Cheers!
I'm wondering why the project isn't using bindgen for generating Rust bindings directly from Arduino library code? I've just done some and have Arduino PCM library Rust version.
