Ian McIntyre

I've not worked with CAN before, and I haven't heard of anyone working on a Rust-based CAN driver for these processors. I'm happy to support an i.MX RT CAN driver's...

Could we reopen this issue? #94 is focused on separating foundational, chip-specific drivers by repositories. It does not describe a repository boundary for chip-specific HALs. Release automation would still be...

How granular should the new HAL crates be? Today's RAL and HAL have a feature-flag per chip variant; `"imxrt1061"` and `"imxrt1062`" specify unique targets. But, they're nearly identical, and they...

Sounds reasonable! With goals for common register blocks and *optional* feature flags, it sounds like we're moving away from a "split HAL," and more towards a "unified RAL." Is that...

One of the previously stated values of a spit HAL was to support documentation, so I'd like to get your thoughts on how that will work. In #89, we're changing...

> [...] simply refer to those examples (with links hopefully) [...] Links back to examples works for me. We lose the benefit of documentation tests that make sure our examples...

I think it would be workable. Sorry, I might be confused about the goals of the common HAL. When I see a reason for splitting up our crates, like >...

> the concrete types depend on RAL types which vary over the chips. It sounded like a unified RAL could solve that. I want to make sure we're on the...

I think something resembling #92 would be a solution to this issue. If the HAL were a collection of modules designed to the RAL, users could pick and choose which...

Under the current design, we could release new peripherals as breaking changes. This burdens BSP maintainers / end users who aren't mixing the HAL and RAL. They're required to manually...