Preparing imxrt-hal 0.6

2026-03-16 (Updated 2026-03-18)

It's been over three years since a breaking imxrt-hal release. Over that time, I've had chances to use the package in small and big projects. And through that usage, I can say that this project still needs work!

Here's what I have planned for imxrt-hal 0.6. I'm keeping the scope small; things that can land in non-breaking releases should come later.

Removing type states from drivers

The type states are helpful for checking that your pins and peripherals are compatible. But after that, I've found little value in carrying around the peripheral instance and pins in the type system. Constructors will still type-check pins and peripherals, but they'll return simple drivers, like Lpspi, instead of Lpspi<3, Pins<...>>.

I know some folks like the type states, but they're one of my gripes. Even using without_pins to ignore pin types, I still carry around the const generic peripheral instance. After construction, I haven't found a way to take advantage of that information. Dropping the type states simplifies the code I'm writing, and I think it will simplify your projects, too!

I'm still maintaining imxrt-iomuxc — we still need it to implement the type-checking APIs, and folks may find novel designs beyond this next imxrt-hal version. Similarly, imxrt-ral will continue to export const generics for peripheral instances; we still need them in this release.

Release 1180 MCU support in imxrt-ral

The 0.6 release of imxrt-hal will have very basic support for the i.MX RT 1180 MCUs. But in order to make that work, we need the MCU support in imxrt-ral.

The main branch of imxrt-ral has the work; it needs to find its way into the 0.6 branch. After that, it's a new release to crates.io, probably as imxrt-ral 0.6.2, since it shouldn't break anything.

embedded-hal 1.0 support for LPSPI

My last attempt didn't complete. I lost steam trying to figure out how SpiDevice — mostly the delay operation — should work, particularly when faced with LPSPI IP bugs. And I was still working with all those type states...

If I just focus on SpiBus, I think I can get something usable! A SpiDevice implementation could come later.

Simplifying & updating dependencies

bitflags is now 2.0, but we're still on 1.0. It's a good time to update little things like this, especially if they're used in the public API.

If embedded-hal 1.0 adoption goes well, I might remove embedded-hal 0.2 support. Folks could use embedded-hal-compat to gain the original support. This would prune some older, no-longer-maintained (in)direct dependencies from everyone's builds.

This exercise might extend to the rest of the imxrt-rs ecosystem, too...

Non-goals

I used to have

as stretch goals for this release. But, after re-reading my 2024 reflections, I'll probably de-scope these. So much for stretching!

Releasing these features as separate packages, before integrating them into imxrt-hal, gives us more flexibility to decide future releases. It also lets us iterate faster on these new packages.