| commit | c4b75b53b73dae03e504fcfe28afccf5aa08ff40 | [log] [tgz] |
|---|---|---|
| author | Eli Lipsitz <elipsitz@pigweed.infra.roller.google.com> | Fri Jan 24 09:18:16 2025 -0800 |
| committer | CQ Bot Account <pigweed-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Jan 24 09:18:16 2025 -0800 |
| tree | fa3c94f2b61915c9ad10281e0ad29d9840f7e931 | |
| parent | d551bbb69e8c8394c98c1498a66c15d5d276f103 [diff] |
roll: pigweed pw_digital_io_mcuxpresso: Use hardware level interrupts instead of edge This commit updates the internal implementation of McuxpressoDigitalInOutInterrupt to use hardware level-sensitive interrupts to implement all edge-sensitive interrupts. Previously, only "kBothEdges" interrupts were implemented with level-sensitive interrupts. The reason for this change is to work around a hardware bug around deep sleep and GPIO edge interrupts on the RT500 MCU. If, for example, a falling-edge interrupt is set, and the chip enters deep-sleep while the line is low, the chip will wake up immediately (the wakeup signal from the GPIO block always acts as level-sensitive in deep sleep). However, the edge detector in the block won't register an edge (as none occurred), so no interrupt will be pended in the NVIC. The chip will exit deep sleep, but there's nothing to do and no interrupts pending, so the chip enters deep sleep again. All of this happens without the CPU ever actually exiting WFI and executing instructions. If the line is still low when the chip enters deep sleep again, it'll repeat this over and over again. This "edge-sensitive emulation" works, at the cost of 2x the interrupts (handled internally in this class), because the system will wake up for the opposing edge (for internal polarity swapping and bookkeeping), in addition to the one it actually cares about. Original-Bug: b/370770558 Tested: Tried both falling and rising interrupts, confirmed they fired Tested: when expected. Tested: Also enabled deep sleep and set up an falling-edge interrupt Tested: attached to a button. Watched the PMIC_SEL0 pin in a logic Tested: analyzer. Confirmed that before this change, pressing the Tested: button causes rapid oscillations on PMIC_SEL0 (~5 us period). Tested: After this change, each time the button is pressed or released Tested: the system briefly wakes from deep sleep to service the Tested: interrupt, but then goes back to sleep. Original-Reviewed-on: https://pigweed-review.googlesource.com/c/pigweed/pigweed/+/261612 Presubmit-Verified: CQ Bot Account <pigweed-scoped@luci-project-accounts.iam.gserviceaccount.com> Original-Revision: b2441ff1e55ad1fbd055099a1ff210f7f7e7c589 Rolled-Repo: https://pigweed.googlesource.com/pigweed/pigweed Rolled-Commits: 3d1d7aec46d512..b2441ff1e55ad1 Roll-Count: 1 Roller-URL: https://cr-buildbucket.appspot.com/build/8724842441734211217 GitWatcher: ignore CQ-Do-Not-Cancel-Tryjobs: true Change-Id: I1ddd4c942f2406beb044bbde720570e186702876 Reviewed-on: https://pigweed-review.googlesource.com/c/pigweed/quickstart/bazel/+/262733 Lint: Lint 🤖 <android-build-ayeaye@system.gserviceaccount.com> Bot-Commit: Pigweed Roller <pigweed-roller@pigweed-service-accounts.iam.gserviceaccount.com> Commit-Queue: Pigweed Roller <pigweed-roller@pigweed-service-accounts.iam.gserviceaccount.com>
This repository contains a minimal example of a Bazel-based Pigweed project. It is a LED-blinking service (featuring RPC control!) for the Raspberry Pi Pico. It can also be run on any computer using the included simulator.
git clone https://pigweed.googlesource.com/pigweed/quickstart/bazel pw_bazel_quickstart cd pw_bazel_quickstart
The only dependency that must be installed is Bazelisk.
Bazelisk is a launcher for the Bazel build system that allows for easy management of multiple Bazel versions.
Instructions for installing Bazelisk can be found here.
To run the simulator, type: bazelisk run //apps/blinky:simulator_blinky Then, in a new console, connect to the simulator using: bazelisk run //apps/blinky:simulator_console
To start, connect a Raspberry Pi Pico, Pico 2, or debug probe via USB.
To run on the Raspberry Pi Pico, type: bazelisk run //apps/blinky:flash_rp2040 Then, in a new console, connect to the device using: bazelisk run //apps/blinky:rp2040_console
Once connected with a console, RPCs can be sent to control the LED. Try running:
device.set_led(True) device.set_led(False) device.toggle_led() device.blink(blink_count=3)
bazelisk test //... will run the unit tests defined in this project, such as the ones in modules/blinky/blinky_test.cc.
bazelisk run @pigweed//targets/rp2040/py:unit_test_server in one console followed by bazelisk test //... --config=rp2040 will also allow running the unit tests on-device.
Try poking around the codebase for inspiration about how Pigweed projects can be organized. Most of the relevant code in this quickstart (including RPC definitions) is inside modules/blinky, with some client-side Python code in tools/console.py.