
* Add a timer-driven task * Spawn another timer * Log * foo * Do not access current time on each schedule * Update generic queue * Minimize alarm priorities * Point to github with patches * Fix build without any queue impl selected * Remove explicit generic-queue features * Define cfgs, fix calling something uninitialized * Clean up RefCell+generic queue * Fix arg order * Feature * Fix single integrated-timer queue * Fix next expiration when arming * Add note * Adjust impl to latest changes * Local patch * Refactor the refactor refactor * Track the timer item's owner * Clear owner on dequeue * Clean up * Point at the right branch * Fix panic message * Hide private function * Remove integrated-timer references * Point at upstream embassy * Configure via esp-config * Document, clean up, fix * Hack * Remove patches * Update config separator, test the complex variant * Undo esp-config hack * Remove trouble example, update edge-net * Update test deps * Document * Update bt-hci. * Fix generic queue * Fix panic message * Fix UB * Fix rebase * Resolve UB * Avoid mutable reference in interrupt executor --------- Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
qa-test
This package contains a number of binary applications intended for manual/quality-assurance testing.
Each device has its own unique set of peripherals, and as such not every test will run on every device. We recommend building and flashing the tests using the xtask
method documented below, which will greatly simplify the process.
To check if a device is compatible with a given test, check the metadata comments above the imports, which will list all supported devices following the //% CHIPS:
designator. If this metadata is not present, then the test will work on any device supported by esp-hal
.
As previously stated, we use the cargo-xtask pattern for automation. Commands invoking this tool must be run from the root of the repository.
Building Tests
You can build all examples for a given device using the build-examples
subcommand:
cargo xtask build-examples qa-test esp32
Note that we must specify which package to build the tests for, since this repository contains multiple packages.
Running Tests
You can also build and then subsequently flash and run an test using the run-example
subcommand. With a target device connected to your host system, run:
cargo xtask run-example qa-test esp32c6 hello_world
Again, note that we must specify which package to build the test from, plus which test to build and flash to the target device.
Adding Tests
If you are contributing to esp-hal
and would like to add an test, the process is generally the same as any other project.
One major difference in our case is the metadata comments which state the compatible devices and required features for an test. Both of these designators are optional; if //% CHIPS:
is omitted then all devices considered to be supported, and if //% FEATURES:
is omitted then no features are enabled at build time.
To demonstrated, in src/bin/embassy_hello_world.rs
you will see the following:
//% CHIPS: esp32 esp32c2 esp32c3 esp32c6 esp32h2 esp32s2 esp32s3
//% FEATURES: embassy esp-hal-embassy/integrated-timers
Another thing to be aware of is the GPIO pins being used. We have tried to use pins available the DevKit-C boards from Espressif, however this is being done on a best-effort basis.
In general, the following GPIO are recommended for use, though be conscious of whether certain pins are used for UART, strapping pins, etc. on some devices:
- GPIO0
- GPIO1
- GPIO2
- GPIO3
- GPIO4
- GPIO5
- GPIO8
- GPIO9
- GPIO10