RFC: A 0.5 HAL to support more i.MX RT chips #121
Conversation
Delete all old sources, and prepare to checkout sources from the prototyping branch.
The LED example works on both the teensy4 and imxrt1010evk boards. Use the 'run' Cargo aliases to flash. You'll need additional tools to flash. Need documentation on flashing.
The CCM API is broken into a few separate modules: - clock_gate provides a named API for interfacing peripheral clock gates. - clock_tree builds on root clock modules, providing presets for system and peripheral clocks. - all other modules are root clock modules. ccm doesn't try to encapsulate the CCM and CCM_ANALOG peripherals; instead, it just works with references to these peripherals. The DCDC follows a similar design, though it's very simple today. The clock_tree API depends on the RunMode configuration.
Only enable RTIC examples when the example's RTIC feature is enabled.
Preferring to develop the DMA driver with the HAL for convenience. Taken at commit 7693b78 with slight lifetime modifications on the futures.
RTIC 1.0 behavior loops on nop. We can wait for interrupts instead.
TODO: Document the example. Describe how the menu works.
TODO: Finish testing all clocks. AHB, IPG, and PERCLK look great.
TODO: Fix runtime and memory layout. We can't feasibly put all things in
the 1010's OCRAM. Needed to optimize for size in order to get the
clock_out example linking.
Move this into a runtime support crate
It's cheap to copy clock gate locators, and we can remove accesses to read-only memory by inlining constants.
Pairs with latest changes in cortex-m-rt fork. The reset handler now conditionally copies instructions, vector tables, and read-only data to their proper regions. Use the released 'set-vtor' feature to set VTOR to the VMA region.
Use pyOCD to observe the panic message: pyocd rtt --target=mimxrt1010 --address=0x20000000 --size=0x8000
Board is now a helper crate linked into the HAL as a dev dependency. The RAL shim library is now part of the board package.
Would need to pass &mut CCM reference through the callback. It's annoying.
Mapped directly from the feature.
Slim down the config modules, and permit the CCM / DMA modules to directly reference chip-specific APIs.
Break this up!
Add *_with_config functions to handle advanced frontend and / or backend configurations.
Played around with adding more function pointers. Even though they're not in this commit, this makes it easier to add them in the future.
Thanks for the test and feedback @teburd.
I don't have immediate plans to upstream the
Updated in 81c0176, and documented in d4472cf. I'm accumulating dependent imxrt PRs in the top-level description. I plan to start merging them within the next few days. If there's interest in reviewing, add yourself as a reviewer or leave a note on the PR. I'll keep them in review. |
Its about the most I can do at the moment unfortunately
Yeah right on makes sense |
Refactor configurations in build.rs.
Move CCM items into a CCM namespace.
Use recent releases of each package.
|
Status update for those following along:
|
It's more flexible than the clock-tree-dependent approach, and it means the LPI2C module is completely stand-alone. The routine to compute timing settings assumes negligible rise times and no need for filters. It's inspired by the 0.4 imxrt-hal routine, but it runs in a const context.
Previously, the SRTC driver took the entire set of SNVS registers. This new design separates the SNVS registers by their functional capabilities. This should make it easier for us to add more SNVS capabilities without introducing breakages. The SNVS modules, and its submodules, are under common. The items exposed by today's modules are portable across 10xx and 11xx MCUs. However, there do seem to be some small differences in some register names; I'm coming to this conclusion after just a quick imxrt-ral study. When adding future SNVS features, we'll need to make sure that they can actually fit within common. Otherwise, we can take a split approach, as demonstrated by DMA. The new srtc example works on all three supported boards.
Includes all of the same content as the manual re-export, and also includes all of the modules for pin traits and type tags.
Two new examples demonstrate how to use a GPIO as an input. The board module configures the pad with a PU / PD, and the examples toggle an LED state based on the input's state or change. The 1010EVK has the easiest experience, since it already has an on-board user button. I'm choosing Pin 7 of the Teensy 4 for a external switch. The two boards now have a BOARD_BUTTON interrupt handler. I'm not sure how this will work if we start adding more GPIO inputs. The approach I'm taking bets that this isn't going to happen. Otherwise, we would need to figure how how to keep the examples consistent while varying how ISRs are mapped to their vectors. There's no support for the 1170EVK in this commit. The buttons on that board are routed to IOMUXC_SNVS pads, which we're not exposing from imxrt-iomuxc. At this time, it's non-trivial to introduce those pads, so the next commit adds a HAL work-around to avoid the limitation.
The last commit message mentioned that there's no imxrt-iomuxc API for IOMUXC_SNVS pads. The HAL can work around this limitation by letting users manually define the GPIO inputs and outputs. This effectively works around the pad resource management strategy, but I still think its safe. Users can elect not to use this API if they don't want to. With this in place, we can manually configure the 1170EVK's WAKEUP input using RAL APIs, and then fabricate a GPIO input. The two examples work as expected.
With the recent imxrt-iomuxc 1170 big bug, and given that we're slow to add pin implementations, I wanted to make sure HAL drivers are still useful regardless of the imxrt-iomuxc state. This commit adds constructors and methods so that we can use I/O drivers without their pin objects. Users who choose this API can configure their pins themselves. They should use type aliases that use the unit type '()' for the generic pin 'P' type argument. A previous commit effectively did this for the GPIO inputs and outputs, so this is an equivalent change for other drivers. Most of the code had a small scope for Pin trait constraints, so I'm expecting that nearly all methods still work without any more changes.
Bringing in the DMA package was just a development convenience. This commit drops those files. I've re-exported the changes to the imxrt-dma module.
Allows the user to re-acquire the register block.
Recommended by the rustdoc book, and applies to both the HAL and the logging crate. This commit also adds documentation for items that were missing documentation.
|
All imxrt-rs-maintained dependencies are now available on crates.io, so this work is almost ready for a release. We're waiting on I cleaned up these commits and orphaned them into the
Let me know if you disagree with this approach, either now or later. I consider this low-risk and reversible; I'm happy to rebase the orphaned commits back onto |
This work is now the I've released this work as imxrt-hal 0.5.0. Looking forward to getting more users and feedback as we play with it. |
|
Fantastic! |
I've infrequently played around with new
imxrt-halideas. This PR summarizes those ideas. It's a re-write of the 0.4 HAL, a package which only supports 1060 chips. This PR is big and incomplete, but I wanted to talk about ideas with working code.Unlike today's HAL, this exploratory HAL
imxrt-ral, including multi-core 1176 chips.This new HAL supports almost all peripherals from the 0.4 release, but everything is a breaking change.
Asks
If you have the time, here's what I'm hoping to get out of this discussion:
boardpackage, and see if you can turn on your board's LED. Ping me below or on the imxrt-rs Matrix chat for help / feedback / complaints.I don't expect a line-by-line review right now. After we discuss, I'll clean up the history, and make it easier to review and merge.
Try it out
All examples build and run on the
A number of examples also work for the Cortex M7 of the i.MX RT 1170 EVK. This chip support is WIP.
After pulling this branch, you can quickly light your Teensy's LED:
You can also light your i.MX RT 1010 EVK's LED with
cargo flash. You need an unreleased version of the tool:See
board/README.mdfor more information on board support. For tips on adding new boards, see the CONTRIBUTING guide.What's new?
Design
The HAL implements #92. Drivers adapt resources from
imxrt-ralandimxrt-iomuxcto provide a higher-level API andembedded-halsupport. Clock control for peripherals is implemented separately, unlike in today's peripherals.HAL drivers use const-generic instances from
imxrt-ral(imxrt-rs/imxrt-ral#24) and pair them with const-tagged resources fromimxrt-iomuxc(imxrt-rs/imxrt-iomuxc#10). This lets us statically ensure that peripherals and pins work together, as we have today. It also lets us express some const-heavy APIs, like the ones use for CCM clock gating (impl, example).Usage and structure
imxrt-halsupports multiple chips from one crate. There's common modules for allimxrt-raltargets. The common modules need oneimxrt-ralfeature, and zeroimxrt-halfeatures, to build. See the HAL API docs for more info on this idea.There's also conditionally-compiled modules which use coarse features to target select chips. Internally, the package uses module path attributes and configuration modules to maximize code reuse. If you want more info, I ramble about this in the CONTRIBUTING doc. I'll stress that this is not #56. It was a prototyping convenience, and I think it gives us a path towards a split HAL.
CCM and DMA drivers are back in the HAL. Just another prototyping convenience. I'm happy to split these back out if we think they're useful elsewhere (though I don't feel I demonstrated that utility, and there's less value when HALs aren't split).
Extras
There's a new logging package to supersede
imxrt-uart-log. It supports bothloganddefmt, and it works with both USB serial and LPUART peripherals. This was my reason to explore a high-speed USB driver; that's in its own repo.There's an experimental runtime,
imxrt-rt, that can boot all three boards. This should make it easier to bring up new boards with various FlexRAM / OCRAM / flash configurations.11xx support
imxrt-rs/imxrt-ral#26 notes early issues when trying to add common HAL support for 11xx chips:
imxrtral.pydoesn't handle that complexity.imxrt-ralresource management doesn't work for all multi-core cases.I tackle the first two issues with a new
imxrt-ralcode generator. I forkedchiptooland turned it intoraltool.raltoolemits animxrtral.py-compatible register access layer, making it easy to adopt the tool output. Thechiptoolintermediate representation made it easy to handle issue 1. The IR also made it easier to implement a new "combine" phase that consolidates peripherals across devices. The combine phase and thechiptooltransforms let us solve 2 without patching SVDs. Quick testing shows thatraltool-generated crates build faster thansvd2rust- andchiptool-generated crates, so changing thechiptoolcodegen was for more than just easier adoption.I'm punting problem 3 by removing any notion of resource management.
imxrt-ralno longer implements a resource management policy. Acquiring a RAL instance isunsafe, no matter what chip you're targeting. This aligns with the originalchiptoolcodegen. In our case, it keeps the RAL simple, and lets us explore resource management separately / later.Next steps
I think this is ready for feedback, but it's not ready to merge. It's not at parity with the 0.4 HAL, and dependencies are in various states of development. These are some of my TODOs I think this needs before it's merged.
HAL TODOs
TEMPMONperipheral.embedded-hal0.2 implementations; make sure they're all there.Implement the relevantembedded-hal1.0 alpha interface.board/src/imxrt1010evk.rs; useimxrt1010evk-fcb.Ecosystem TODOs
Finish work, clean up commits, then upstream changes to all dependencies:
bbqueueimxrt-boot-genimxrt-iomuxcimxrt-ralimxrt-rtimxrt-usbdPeripheralstrait to return register pointers imxrt-usbd#19imxrt-dmaral-registers