-
Notifications
You must be signed in to change notification settings - Fork 50
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
What is the scope / planned level of this library going forward? #3
Comments
(Another accidental close - I seem to keep doing this, sorry) |
An instance of what I mean is that currently the |
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.
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.
My plan is to eventually implement 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" |
Thanks for answering! In regards to the Implementing traits on things (e.g |
Remember that the
What kind of setting do you mean? |
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. |
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?) |
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 :-) |
Fair point!
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? |
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.
The text was updated successfully, but these errors were encountered: