itsscb/esp-hal
1
0
Fork 0
mirror of https://github.com/esp-rs/esp-hal.git synced 2025-09-27 04:10:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

update hil-test and qa-test readme to match reworked xtask (#3975)

Browse Source
This commit is contained in:
Juraj Sadel 2025-08-22 13:15:54 +02:00 committed by GitHub
parent 282415a35e
commit 90e3907617
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 8 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
hil-test/README.md
View File

@ -28,34 +28,23 @@ Target device **MUST** connected via its USB-Serial-JTAG port, or if unavailable
You can run all tests for a given device by running the following command from the workspace root: You can run all tests for a given device by running the following command from the workspace root:
```shell ```shell
cargo xtask run-tests $CHIP cargo xtask run tests $CHIP
``` ```
To run a single test on a target, run the following command from the workspace root: To run a single test on a target, run the following command from the workspace root:
```shell ```shell
# Run GPIO tests for ESP32-C6 # Run GPIO tests for ESP32-C6
cargo xtask run-tests esp32c6 --test gpio cargo xtask run tests esp32c6 --test gpio
``` ```
If you want to run a test multiple times: If you want to run a test multiple times:
```shell ```shell
# Run GPIO tests for ESP32-C6 # Run GPIO tests for ESP32-C6
cargo xtask run-tests esp32c6 --test gpio --repeat 10 cargo xtask run tests esp32c6 --test gpio --repeat 10
``` ```
Another alternative way of running a single test is, from the `hil-tests` folder:
```shell
# Run GPIO tests for ESP32-C6
CARGO_BUILD_TARGET=riscv32imac-unknown-none-elf \
PROBE_RS_CHIP=esp32c6 \
cargo +nightly test --features=esp32c6 --test=gpio
```
- If the `--test` argument is omitted, then all tests will be run, independently if the tests are supported for that target, for this reason, we encourage using the `xtask` approach.
- The build target **MUST** be specified via the `CARGO_BUILD_TARGET` environment variable or as an argument (`--target`).
- The chip **MUST** be specified via the `PROBE_RS_CHIP` environment variable or as an argument of `probe-rs` (`--chip`).
Some tests will require physical connections, please see the current [configuration in our runners]. Some tests will require physical connections, please see the current [configuration in our runners].
[probe-rs]: https://probe.rs [probe-rs]: https://probe.rs

20
qa-test/README.md
View File

@ -10,22 +10,12 @@ As previously stated, we use the [cargo-xtask] pattern for automation. Commands
[cargo-xtask]: https://github.com/matklad/cargo-xtask [cargo-xtask]: https://github.com/matklad/cargo-xtask
## Building Tests
You can build all examples for a given device using the `build-examples` subcommand:
```shell
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 ## 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: You can build and then subsequently flash and run an test using the `run example` subcommand. With a target device connected to your host system, run:
```shell ```shell
cargo xtask run-example qa-test esp32c6 hello_world cargo xtask run example --package qa-test --chip esp32c6 sleep_timer
``` ```
Again, note that we must specify which package to build the test from, plus which test to build and flash to the target device. Again, note that we must specify which package to build the test from, plus which test to build and flash to the target device.
@ -36,11 +26,11 @@ If you are contributing to `esp-hal` and would like to add an test, the process
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. 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: To demonstrated, in `src/bin/psram.rs` you will see the following:
```rust ```rust
//% CHIPS: esp32 esp32c2 esp32c3 esp32c6 esp32h2 esp32s2 esp32s3 //% CHIPS: esp32 esp32s2 esp32s3
//% FEATURES: embassy esp-hal-embassy/integrated-timers //% FEATURES: esp-hal/psram esp-alloc/internal-heap-stats
``` ```
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. 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.