Question: embedded-hal 0.2 vs 1.0 compatibility - seeking to understand technical decisions

[rud-lucien]

Background

Hi! I'm new to Rust and embedded development, and I'm working on a project using the teensy4-bsp crate. I noticed that this crate uses embedded-hal 0.2, while embedded-hal 1.0 has been available for some time now.

My Question

I'm trying to better understand the technical decisions around HAL versioning in embedded Rust projects. Could you help me understand:

1. What are the main technical reasons for staying with embedded-hal 0.2?

   • Are there specific breaking changes in 1.0 that would require significant rework?
   • Are there stability/maturity considerations?

2. What would be involved in migrating to embedded-hal 1.0?

   • Would it require rewriting hardware driver implementations?
   • Are there ecosystem compatibility concerns?

3. Is there a roadmap or timeline for potentially supporting embedded-hal 1.0?

   • Or are there reasons why 0.2 is preferred long-term?

Context

I ran into this while trying to use non-blocking I/O in my project. Initially, I had both embedded-hal versions in my Cargo.toml which caused trait conflicts. After learning more, I realized I needed to match the BSP's version (0.2) to get proper access to the non-blocking traits.

This experience made me curious about the broader technical considerations that go into these versioning decisions in the embedded Rust ecosystem.

Learning Goal

I'm not requesting a feature or reporting a bug - just trying to understand the technical landscape better as I learn embedded Rust development practices.

Thanks for maintaining this excellent crate!

[mciantyre]

Thanks for checking out the project. The short answer: I haven't needed embedded-hal 1.0 traits for my projects, and folks (me included) haven't made contributions to finish embedded-hal 1.0 support. If this is something you're interested in, I'm happy to help ya.

We develop Teensy 4 drivers in the imxrt-hal project. imxrt-rs/imxrt-hal#142 is our tracking issue for embedded-hal 1.0 support. There should be some drivers that support 1.0 traits, but we're incomplete.

embedded-hal 1.0 has been available since January 2024. However, this BSP tracks the imxrt-hal 0.5 series, first tagged January 2023. In a different timeline, we probably would have supported embedded-hal 1.0 from the start! Schedules didn't work out that way.

If you have more questions, let's talk in the tracking issue, where we'll reach a wider audience.

[rud-lucien]

Thank you so much for the detailed explanation and for maintaining this excellent project! As someone very new to both Rust and embedded development (coming from basic Arduino experience), this really helps clarify the ecosystem dynamics. Your explanation about the timeline mismatch (imxrt-hal 0.5 series from January 2023 vs embedded-hal 1.0 from January 2024) makes perfect sense. My specific challenge was implementing non-blocking UART operations. I initially tried following embedded-hal 1.0 examples (since that's what shows up in crates.io documentation), which led to trait conflicts. After investigating my dependency tree, I discovered I actually have both versions in my project: embedded-hal 0.2.7 - What I specified and what teensy4-bsp reliably uses embedded-hal 1.0.0 - Being pulled in by imxrt-hal v0.5.11 (as part of the partial migration you mentioned) This perfectly illustrates your point about "some drivers that support 1.0 traits, but we're incomplete." The compiler errors were actually really helpful in guiding me toward the 0.2 traits that work consistently. I've been using cargo doc --open to browse the local documentation, which shows both versions and helps me understand what's actually available in my specific project setup. For now, I'm sticking with embedded-hal 0.2.7 since it works reliably with all teensy4-bsp functionality. I'll follow the tracking issue (imxrt-rs/imxrt-hal#142) to learn more about the migration progress. I'm still very much in the learning phase of understanding the HAL/BSP/RAL ecosystem layers and honestly not sure if I'll ever reach a level where I could meaningfully contribute to this kind of systems-level code (but aspire to). But I really appreciate the open development process and being able to follow along with the technical discussions. Thanks again for the welcoming response and for helping me understand how the embedded Rust ecosystem evolves!

…

On Sat, Oct 4, 2025 at 11:01 AM Ian McIntyre ***@***.***> wrote: Closed #179 <#179> as resolved. — Reply to this email directly, view it on GitHub <#179>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHHSX4K7HQO4AYICZYJZL433V7OLFAVCNFSM6AAAAACIG5VOQ2VHI2DSMVQWIX3LMV45UABFIRUXGY3VONZWS33OIV3GK3TUHI5E433UNFTGSY3BORUW63R3GIYTSMBRGQYQ> . You are receiving this because you authored the thread.Message ID: ***@***.*** .com>