search

mciantyre / teensy4-rs

Rust support for the Teensy 4
Apache License 2.0
289 stars 32 forks source link

Collaboration around i.mx rt #49

Closed teburd closed 4 years ago

teburd commented 4 years ago

Hi, this is a fantastic set of work. I'm looking to build software in rust around the nxp evk boards, specifically the 1062 and 1011 evk boards. I think there's a lot of common code that can be shared.

I tried creating a mega pac using svd2rust and found the compile super slow and found this crate noting you had the same issue. Splitting the crate up into many crates certainly improves things but I think an alternative to svd2rust using https://github.com/adamgreig/stm32ral python svd code generation script and macros might be significantly saner to work with, and started building things around that idea at https://github.com/imxrt-rs/imxrt-rs. The equivalent of the PAC crate, for almost all of the nxp imxrt series chips, builds in 3 seconds.

It does use macros rather than the type state functions svd2rust generates, but otherwise supports all of the same high level features and rust embedded ecosystem.

My thinking is

I'd really like to try porting your hal to this, and expand it to support other imxrt chips. I would love to get your approval of that idea, despite licensing it just feels like common courtesy.

If it doesn't pan out, expect some patches to support some more things for the evk boards

Thanks!

mciantyre commented 4 years ago

I'm happy to support a port of the HAL to a RAL-based implementation. I've been struggling with the PAC's long compile times (see #48). Deep down, I've wanted an alternative to what svd2rust produced, but hadn't looked for alternatives. Thanks for introducing me to the RAL idea.

Let me know if I can help with the HAL port. I might take the opportunity to clean up some HAL internals, and make the peripheral APIs more consistent.

Any thoughts on adopting the FCB generation and runtime crates? They both assume an iMXRT1062, but with some work they should be usable across iMXRT chip variants. I can contribute them to the imxrt-rs org if you find them useful. The runtime crate might be necessary until we have something like rust-embedded/cortex-m-rt#164 available.

I also have some SVD modifications I might be able to formalize in svdtool patches. Thanks for introducing me to that tool, too.

teburd commented 4 years ago

First of all I'm glad to hear your happy to support this.

Yes, the compile times are a bit long for most pacs, this series just happens to be massive and I think pushes the svd2rust method of creating them to a painful level.

I'd love help with the hal port, I've started by porting the ccm peripheral, the next up I think would be gpio, so I can get blinky leds everywhere. Past that, its really supporting the rest of the peripherals. This chip has a lot, and the work on USB in rust is especially exciting!

Any modifications you've done with the SVDs would almost certainly be welcome as svdtool type patches. There's certainly some quirks in there to sort out.

The way the imxrt-ral crate works for each chip is with a feature flag and then creating aliases at the root module. So with a feature flag imxrt_ral::ccm might be for the 1011 or the 1062. This is how I'm planning on writing a hal, this should let me reuse large swaths of code very quickly.

Maybe the same method can be used for your fcb and rt crates in a way that they can support other chips with feature flags taking advantage of any common functionality which there should be quite a bit.

I'm almost always on in #rust-embedded:matrix.org where many of the other rust embedded authors also chat if you want to discuss anything more readily.