Support for embedded-hal #5
Comments
|
Hey, I'm really interested in this issue, but I can't see any associated PRs (yet) or other activity regarding the proposal. I'm writing embedded firmware for an STM32, and I currently use Now, I'll be honest: I'm not good with embedded yet. But I'd like to help provide my - limited - input on this matter, if possible. I'd really like to keep the same code for UART I/O, on ARM64/x86_64 and ARM. My current implementation abstracts I/O into the I imagine this comment comes across as a `Hey, is there any progress on this?' - I want to reiterate that I would like to help make this possible, though. Thank you! |
|
Thank you for your interest!
|
|
@dbrgn created #59 for this topic a while ago. It is focused on on older version of embedded-hal 1.0 but a good sketch how this could be done for embedded-hal 0.2. Are there any plans to over serial I/O for embedded-io with embedded-hal-compat or a similar adapter in the future? |
|
Good point. It might be possible to bridge to |
|
Hi, sorry for my late reply. I think, looking at the state of things, there's not a lot I can contribute without becoming a hindrance. Is there a list of relevant PRs/issues/discussions worth subscribing to to keep track of things? I've recently published a unified -MODEM crate, which uses code from other XMODEM/YMODEM crates to unify them into one single crate. It'd be really good to be able to use that with |
No problem. We all are doing this in our spare time and have plenty of other things to do.
This issue here and #59 are the best known issues to me. Recently there were a lot of things going on with embedded-hal going towards 1.0 and I still need to keep up with them.
This sounds interesting and might be a good candidate for verifying the porting efforts. Which is your crate? |
|
Hi,
On Sat, Sep 09, 2023 at 08:13:05AM -0700, Christian Meusel wrote:
> Hi, sorry for my late reply.
No problem. We all are doing this in our spare time and have plenty of other
things to do.
Concur. I'm in the same position! :-)
> I think, looking at the state of things, there's not a lot I can contribute without becoming a hindrance.
>
> Is there a list of relevant PRs/issues/discussions worth subscribing to to keep track of things?
This issue here and #59 are the best known issues to me. Recently there were a lot of things going on with embedded-hal going towards 1.0 and I still need to keep up with them.
I've subscribed to both now.
> I've recently published a unified -MODEM crate, which uses code from other XMODEM/YMODEM crates to unify them into one single crate. It'd be really good to be able to use that with `embedded-hal` so that Rust code on embedded can interact with XMODEM. For example, this STM32 I'm working with currently uses XMODEM for updates.
This sounds interesting and might be a good candidate for verifying the porting efforts. Which is your crate?
It's `txmodems`. Basically, for my `Cosmo-CoDiOS` project, I needed a XMODEM
implementation, but I noted there's a fair amount of fragmentation regarding
implementations. Also lack of `no_std`, which was a requirement.
https://crates.io/crates/txmodems
I used the code from some of the existing crates, and implemented them as traits
in the `txmodems` project.
You're more than welcome to use the crate to verify the porting efforts. I
haven't been able to write unit tests yet, as it runs as embedded, but I plan to
refactor that in the future.
Currently, XMODEM is the only one that seems fully implemented. YMODEM I'm
thinking about.
Feel free to open any issues/PRs if you spot anything that looks 'off'. I don't
have a spare board to test the protocol on right now.
Best wishes,
--
Dom Rodriguez
GPG Fingerprint: EB0D 45E6 D0DC 1BA1 A2B5 FC24 72DC F123 1E54 BD43
***@***.***)
|
|
It should be noted that we have removed the |
|
I've been working on moving my |
|
Is there anything I can do to help? I heard vaguely some news about |
|
Me2, @shymega I’m only learning Rust since Dec’23, but have a project that is around serial port and ESP32 (RISC-V variant). Don’t think I can write this code - but can read and test. |
|
OK< so I was wrong about I've got a series of crates for abstracting over UART on Android/bare metal for a specific MCU. I'm not sure what I can do to help with this issue, and I suspect due to my naivety to the project in some regards, I may become a slight hindrance. However, a cross-party discussion with the Rust Embedded folks might be useful. |
|
If it helps, I'm using |
Thank you for proposing this solution and linking a real-world example @crespum! After looking into this recently, using the And I did not find much concrete documentation for
Yes, there is @shymega. I would love to provide or link to some simple examples. But I did not find the time to either do the research for something already available or build something. The |
|
It seems to be possible to adapt the writer example to be async on unix, using the async_io::Async adapter around TTYPort. This works because TTYPort implements AsRawFd, so the Async adapter can use that to register readiness callbacks when it would block. This might be useful for anyone wanting to use embedded-io-async (for testing embassy things locally without having to flash the device every time). I don't know what the equivalent would be on windows. patchdiff --git a/Cargo.toml b/Cargo.toml
index 5befb99..ccdf6f4 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -42,6 +42,7 @@ serde = { version = "1.0", features = ["derive"], optional = true }
[dev-dependencies]
assert_hex = "0.4.1"
+async-io = "1.13.0"
clap = { version = "3.1.6", features = ["derive"] }
envconfig = "0.10.0"
# TODES Remove pinning this subdependency (of clap) when we are bumping our
@@ -59,6 +60,7 @@ quickcheck_macros = "1.0.0"
rstest = { version = "0.12.0", default-features = false }
rstest_reuse = "0.6.0"
rustversion = "1.0.16"
+smol = "1.3.0"
[features]
default = ["libudev"]
diff --git a/examples/transmit.rs b/examples/transmit.rs
index 5161124..2574d08 100644
--- a/examples/transmit.rs
+++ b/examples/transmit.rs
@@ -3,17 +3,14 @@ use std::time::Duration;
use clap::{Arg, Command};
-use serialport::{DataBits, StopBits};
+use serialport::{DataBits, StopBits, TTYPort};
+use smol::io::AsyncWriteExt as _;
fn main() {
let matches = Command::new("Serialport Example - Heartbeat")
@@ -72,17 +69,18 @@ fn main() {
.stop_bits(stop_bits)
.data_bits(data_bits);
println!("{:?}", &builder);
- let mut port = builder.open().unwrap_or_else(|e| {
+ let port = TTYPort::open(&builder).unwrap_or_else(|e| {
eprintln!("Failed to open \"{}\". Error: {}", port_name, e);
::std::process::exit(1);
});
+ let mut port = async_io::Async::new(port).unwrap();
println!(
"Writing '{}' to {} at {} baud at {}Hz",
&string, &port_name, &baud_rate, &rate
);
- loop {
- match port.write(string.as_bytes()) {
+ smol::block_on(async move { loop {
+ match port.write(string.as_bytes()).await {
Ok(_) => {
print!("{}", &string);
std::io::stdout().flush().unwrap();
@@ -94,7 +92,7 @@ fn main() {
return;
}
std::thread::sleep(Duration::from_millis((1000.0 / (rate as f32)) as u64));
- }
+ }})
}
fn valid_baud(val: &str) -> std::result::Result<(), String> {Would it be useful for me to turn this into an example and contribute it to this repo? If so, is the |
This issue was migrated from GitLab. The original issue can be found here:
https://gitlab.com/susurrus/serialport-rs/-/issues/71
It would be awesome if
serialportwould add opt-in support for the embedded-hal traits at https://docs.rs/embedded-hal/*/embedded_hal/serial/. It would allow drivers to be easily tested on a non-embedded platform like Linux.Would you accept a MR that adds these impls behind a feature flag?
The text was updated successfully, but these errors were encountered: