Closed
hudson-ayers
changed the title
[RFC] Board-based instantiation of chip drivers and interrupt --> driver mapping.
Board-based instantiation of chip drivers and interrupt --> driver mapping for Apollo3 + SAM4L
Merged
2 tasks
Merged
2 tasks
This was referenced
Nov 4, 2020Merged
Merged
Merged
7 tasks
This was referenced
Nov 10, 2020Merged
Closed
Merged
7 tasks
Merged
2 tasks
bors Bot added a commit that referenced this pull request
Dec 2, 20202189: Board based instantiation of chip drivers and interrupt mappings: Msp432 r=hudson-ayers a=hudson-ayers ### Pull Request Overview This pull request ports the MSP432 chip/board to the new peripheral instantiation approach that does not rely on global variables (first proposed in #2069). This chip was relatively easy to change compared to some of the others, but @lebakassemmerl I would still appreciate a quick look over the changes or a test of a couple apps to ensure I haven't done anything stupid. This is the last remaining chip before all upstream chips/boards have been ported! ### Testing Strategy This pull request was tested by compiling, hardware testing would be nice. ### TODO or Help Wanted N/A ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Hudson Ayers <hayers@stanford.edu>
bors Bot added a commit that referenced this pull request
Dec 2, 20202200: Add Teensy 4 board r=bradjc a=mciantyre ### Pull Request Overview The PR proposes Tock support for the Teensy 4. As of this PR, the Tock kernel, and a variety of small examples, can run on [Teensy 4.0][teensy40] and [Teensy 4.1][teensy41] development boards. The PR builds on the i.MX RT chip foundation added in #1918. [teensy40]: https://www.pjrc.com/store/teensy40.html [teensy41]: https://www.pjrc.com/store/teensy41.html The board makes use of - the LED on pin 13 - UART2 on pins 14 and 15 - GPT1 as an alarm The Teensy 4 boards use i.MX RT **1062** chips. Given our current chip features, the 1060 chip family is identical to the 1050 chip family. Before integrating the Teensy 4 board, I *renamed `chips/imxrt1050` to `chips/imxrt10xx`*. I updated the `imxrt1050-evkb` board to use the renamed crate. Additional changes to the i.MX RT chip crate include - adding a LPUART2 peripheral - renaming the `gpt1` module to `gpt`, and adding `GPT2` - supporting periodic clock selection, allowing a user to select the static crystal oscillator as the GPT clock source Changes to the chip crate should be backwards compatible for `imxrt1050-evkb` users. Let me know if we see an issue. ### Testing Strategy I tested the PR by running `blink` and `console` libtock-c examples on both a Teensy 4.0 and 4.1 board. I repackaged the examples [here](https://github.com/mciantyre/tock-teensy4-apps). The PR was **not** tested on an NXP i.MX RT 1050 evaluation board; I don't have that hardware. ### TODO or Help Wanted This pull request may be tested on a 1050 evaluation board. @valexandru, if you have an opportunity to test this work and review these changes, I'd appreciate it! This PR does not address any of the TODOs noted in #1918. In particular, the `imxrt10xx` chip still does not use the new peripheral instantiation approach (#2069). If this is still TODO and not urgent, I'm happy to support that cleanup in a separate PR. This Teensy 4 support was based on a different chip implementation. That chip implementation supported DMA, and a UART driver that used DMA. If we see value in a DMA driver for i.MX RT chips, I'm happy to contribute the driver. ### Documentation Updated - [x] ~~Updated the relevant files in `/docs`~~, or **no updates are required** I've added documentation in `boards/teensy4`. The documentation - lists the tools that you need to program a Teensy 4 - how to build the kernel and apps - how to convert the program to a HEX file, which is necessary to program a board ### Formatting - [x] Ran `make prepush`. ### New Platform Checklist - [x] Hardware is widely available. - [x] I can support the platform, which includes release testing for the platform, at least initially. - Basic features are implemented: - [x] `Console`, including `debug!()` and userspace `printf()`. - [x] Timers. - [x] GPIO with interrupts. I assume the basic chip features were provided by #1918. Let me know if we need to make all three features available through the board. As of this writing, the Teensy 4 board does not expose an input GPIO that responds to an interrupt. 2216: add 15.4 and ble to nano33ble r=bradjc a=hudson-ayers ### Pull Request Overview This pull request adds the 15.4 and BLE drivers to the nano33ble, rather than leaving support as commented out, as the comments had already fallen out-of-date. ### Testing Strategy BLE was tested using the `ble_advertising` and `ble_passive_scanning` apps in `libtock-c`. 15.4 was tested using the `radio_tx` and `radio_rx` apps in `libtock-c` and sending messages back and forth with an nrf52840-dk. ### TODO or Help Wanted N/A ### Documentation Updated - [x] No updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Ian McIntyre <ianpmcintyre@gmail.com> Co-authored-by: Hudson Ayers <hayers@stanford.edu> Co-authored-by: Hudson Ayers <32688905+hudson-ayers@users.noreply.github.com>
Merged
7 tasks
bors Bot added a commit that referenced this pull request
Jan 5, 20212311: Board based instantiation of chip drivers and interrupt mappings: imxrt10xx r=bradjc a=mciantyre ### Pull Request Overview The PR refactors the `imxrt10xx` chip and boards to support board-based initialization (first proposed in #2069). It builds on the work of #1918 and #2200, where we noted the effort as a TODO. After this PR, you may instantiate and configure i.MX RT peripherals in a board, or use the default peripherals provided by the chip. Most peripherals were easily transitioned to the new API. The exception was the GPIO driver, which referenced `static` GPIO ports and pins throughout the code. I may have found some issues in the driver, so I took the refactoring opportunity to update the implementation, trying to follow [this suggestion](https://github.com/tock/tock/blob/master/chips/stm32f4xx/src/gpio.rs#L595). I'll leave more details in review comments. Other changes include - fix a GPT clock gating bug introduced in #2200 - move UART root clock initialization out of the `configure()` method, and into CCM peripheral setup ### Testing Strategy Tested `boards/teensy40` on a Teensy 4.0 using the tests from #2200. `boards/imxrt1050-evkb` continues to compile, but I don't have the hardware to test examples. ### TODO or Help Wanted Looking for feedback on the refactor. Let me know if it deviates too much from the other chips. Holding as draft to - [x] ~~wait for #2310, since the new GPIO driver needs `min_const_generics`~~ accepting as-is, and we'll remove the feature later - [x] figure out a way to remove the remaining `static` peripheral in `iomuxc_snvs` - [x] remove `std` dependency in new unit tests, avoiding the conditional `no_std` in the crate - [x] leave thoughts on GPIO changes - [x] clean up commit messages ### Documentation Updated - [x] ~~Updated the relevant files in `/docs`, or~~ no updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Ian McIntyre <ianpmcintyre@gmail.com>
hudson-ayers added a commit to hudson-ayers/tock that referenced this pull request
Jul 14, 2022This commit removes the const_mut_refs unstable feature and all uses of it. For the most part, this just required making every const constructor that created a `TakeCell` no longer const, as a result of `TakeCell::empty()` no longer being const. Thanks to the updated peripheral instantation approach in tock#2069 and related PRs, this was very straightforward to perform, as peripherals no longer need to be created in const context.
Merged
2 tasks
bors Bot added a commit that referenced this pull request
Jul 22, 20223082: Remove `#![feature(const_mut_refs)]` r=bradjc a=hudson-ayers ### Pull Request Overview This PR removes the `const_mut_refs` unstable feature and all uses of it. For the most part, this just required making every const constructor that created a `TakeCell` no longer const, as a result of `TakeCell::empty()` no longer being const. Thanks to the updated peripheral instantation approach in #2069 and related PRs, this was very straightforward to perform, as peripherals no longer need to be created in const context. ### Testing Strategy This pull request was tested by compiling, no functional changes are included. ### TODO or Help Wanted N/A ### Documentation Updated - [x] I will update #1654 if/when this is merged. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Hudson Ayers <hayers@stanford.edu>
sirchnik pushed a commit to sirchnik/tock that referenced this pull request
May 12, 2026sirchnik pushed a commit to sirchnik/tock that referenced this pull request
May 12, 20262189: Board based instantiation of chip drivers and interrupt mappings: Msp432 r=hudson-ayers a=hudson-ayers ### Pull Request Overview This pull request ports the MSP432 chip/board to the new peripheral instantiation approach that does not rely on global variables (first proposed in tock#2069). This chip was relatively easy to change compared to some of the others, but @lebakassemmerl I would still appreciate a quick look over the changes or a test of a couple apps to ensure I haven't done anything stupid. This is the last remaining chip before all upstream chips/boards have been ported! ### Testing Strategy This pull request was tested by compiling, hardware testing would be nice. ### TODO or Help Wanted N/A ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Hudson Ayers <hayers@stanford.edu>
sirchnik pushed a commit to sirchnik/tock that referenced this pull request
May 12, 20262200: Add Teensy 4 board r=bradjc a=mciantyre ### Pull Request Overview The PR proposes Tock support for the Teensy 4. As of this PR, the Tock kernel, and a variety of small examples, can run on [Teensy 4.0][teensy40] and [Teensy 4.1][teensy41] development boards. The PR builds on the i.MX RT chip foundation added in tock#1918. [teensy40]: https://www.pjrc.com/store/teensy40.html [teensy41]: https://www.pjrc.com/store/teensy41.html The board makes use of - the LED on pin 13 - UART2 on pins 14 and 15 - GPT1 as an alarm The Teensy 4 boards use i.MX RT **1062** chips. Given our current chip features, the 1060 chip family is identical to the 1050 chip family. Before integrating the Teensy 4 board, I *renamed `chips/imxrt1050` to `chips/imxrt10xx`*. I updated the `imxrt1050-evkb` board to use the renamed crate. Additional changes to the i.MX RT chip crate include - adding a LPUART2 peripheral - renaming the `gpt1` module to `gpt`, and adding `GPT2` - supporting periodic clock selection, allowing a user to select the static crystal oscillator as the GPT clock source Changes to the chip crate should be backwards compatible for `imxrt1050-evkb` users. Let me know if we see an issue. ### Testing Strategy I tested the PR by running `blink` and `console` libtock-c examples on both a Teensy 4.0 and 4.1 board. I repackaged the examples [here](https://github.com/mciantyre/tock-teensy4-apps). The PR was **not** tested on an NXP i.MX RT 1050 evaluation board; I don't have that hardware. ### TODO or Help Wanted This pull request may be tested on a 1050 evaluation board. @valexandru, if you have an opportunity to test this work and review these changes, I'd appreciate it! This PR does not address any of the TODOs noted in tock#1918. In particular, the `imxrt10xx` chip still does not use the new peripheral instantiation approach (tock#2069). If this is still TODO and not urgent, I'm happy to support that cleanup in a separate PR. This Teensy 4 support was based on a different chip implementation. That chip implementation supported DMA, and a UART driver that used DMA. If we see value in a DMA driver for i.MX RT chips, I'm happy to contribute the driver. ### Documentation Updated - [x] ~~Updated the relevant files in `/docs`~~, or **no updates are required** I've added documentation in `boards/teensy4`. The documentation - lists the tools that you need to program a Teensy 4 - how to build the kernel and apps - how to convert the program to a HEX file, which is necessary to program a board ### Formatting - [x] Ran `make prepush`. ### New Platform Checklist - [x] Hardware is widely available. - [x] I can support the platform, which includes release testing for the platform, at least initially. - Basic features are implemented: - [x] `Console`, including `debug!()` and userspace `printf()`. - [x] Timers. - [x] GPIO with interrupts. I assume the basic chip features were provided by tock#1918. Let me know if we need to make all three features available through the board. As of this writing, the Teensy 4 board does not expose an input GPIO that responds to an interrupt. 2216: add 15.4 and ble to nano33ble r=bradjc a=hudson-ayers ### Pull Request Overview This pull request adds the 15.4 and BLE drivers to the nano33ble, rather than leaving support as commented out, as the comments had already fallen out-of-date. ### Testing Strategy BLE was tested using the `ble_advertising` and `ble_passive_scanning` apps in `libtock-c`. 15.4 was tested using the `radio_tx` and `radio_rx` apps in `libtock-c` and sending messages back and forth with an nrf52840-dk. ### TODO or Help Wanted N/A ### Documentation Updated - [x] No updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Ian McIntyre <ianpmcintyre@gmail.com> Co-authored-by: Hudson Ayers <hayers@stanford.edu> Co-authored-by: Hudson Ayers <32688905+hudson-ayers@users.noreply.github.com>
sirchnik pushed a commit to sirchnik/tock that referenced this pull request
May 12, 20262311: Board based instantiation of chip drivers and interrupt mappings: imxrt10xx r=bradjc a=mciantyre ### Pull Request Overview The PR refactors the `imxrt10xx` chip and boards to support board-based initialization (first proposed in tock#2069). It builds on the work of tock#1918 and tock#2200, where we noted the effort as a TODO. After this PR, you may instantiate and configure i.MX RT peripherals in a board, or use the default peripherals provided by the chip. Most peripherals were easily transitioned to the new API. The exception was the GPIO driver, which referenced `static` GPIO ports and pins throughout the code. I may have found some issues in the driver, so I took the refactoring opportunity to update the implementation, trying to follow [this suggestion](https://github.com/tock/tock/blob/master/chips/stm32f4xx/src/gpio.rs#L595). I'll leave more details in review comments. Other changes include - fix a GPT clock gating bug introduced in tock#2200 - move UART root clock initialization out of the `configure()` method, and into CCM peripheral setup ### Testing Strategy Tested `boards/teensy40` on a Teensy 4.0 using the tests from tock#2200. `boards/imxrt1050-evkb` continues to compile, but I don't have the hardware to test examples. ### TODO or Help Wanted Looking for feedback on the refactor. Let me know if it deviates too much from the other chips. Holding as draft to - [x] ~~wait for tock#2310, since the new GPIO driver needs `min_const_generics`~~ accepting as-is, and we'll remove the feature later - [x] figure out a way to remove the remaining `static` peripheral in `iomuxc_snvs` - [x] remove `std` dependency in new unit tests, avoiding the conditional `no_std` in the crate - [x] leave thoughts on GPIO changes - [x] clean up commit messages ### Documentation Updated - [x] ~~Updated the relevant files in `/docs`, or~~ no updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Ian McIntyre <ianpmcintyre@gmail.com>
sirchnik pushed a commit to sirchnik/tock that referenced this pull request
May 12, 2026This commit removes the const_mut_refs unstable feature and all uses of it. For the most part, this just required making every const constructor that created a `TakeCell` no longer const, as a result of `TakeCell::empty()` no longer being const. Thanks to the updated peripheral instantation approach in tock#2069 and related PRs, this was very straightforward to perform, as peripherals no longer need to be created in const context.
sirchnik pushed a commit to sirchnik/tock that referenced this pull request
May 12, 20263082: Remove `#![feature(const_mut_refs)]` r=bradjc a=hudson-ayers ### Pull Request Overview This PR removes the `const_mut_refs` unstable feature and all uses of it. For the most part, this just required making every const constructor that created a `TakeCell` no longer const, as a result of `TakeCell::empty()` no longer being const. Thanks to the updated peripheral instantation approach in tock#2069 and related PRs, this was very straightforward to perform, as peripherals no longer need to be created in const context. ### Testing Strategy This pull request was tested by compiling, no functional changes are included. ### TODO or Help Wanted N/A ### Documentation Updated - [x] I will update tock#1654 if/when this is merged. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Hudson Ayers <hayers@stanford.edu>