Preparing imxrt-hal 0.6

2026-03-16

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.

Integrate imxrt-enet

I will probably delay this to a patch release in the 0.6 series. As I started writing this post, I realized we can add this in a non-breaking release.

There's a looooong-running PR to add imxrt-enet, an ENET driver, to imxrt-hal. The 0.6 release will eventually export this driver for 1020, 1060, and 1170 MCUs.

I probably won't add support for ENET_1G right away. I think that can happen later, in a non-breaking change.

Power, clock control on 11xx MCUs

I want this to not be a stretch goal. But it'll probably be a stretch goal.

On 10xx MCUs, there are APIs for powering and configuring many of the PLLs. Without that, we can't use peripherals! On 11xx MCUs, I've gotten away with driver prototyping by relying on oscillators that are already running after reset. But once I start integrating larger drivers, like imxrt-enet, that doesn't work anymore — I need a clean clock source at a high frequency.

I'm not yet sure what the API will look like. If (when) it becomes a stretch goal, I'll jam the prototype GPC and PMU drivers into imxrt-hal/board and figure out a proper driver design in a future, non-breaking release.

Integrate imxrt-enet-qos

This is a stretch goal. If it doesn't happen in time for the 0.6 release, it can happen later in a patch release.

Some 1170 MCUs have a third MAC, called ENET_QOS, that's distinct from ENET and ENET_1G. A few months ago, I contributed imxrt-enet-qos to the open source project! It would be nice to export this through the HAL when targeting an 1170 MCU, along with an example showing it works as a smoltcp device implementation.