Skip to content

Conversation

@dpgeorge
Copy link
Member

Summary

This PR converts tests/extmod/machine_spi_rate.py to use the target wiring mechanism, moving the port-specefic definition of the SPI instances that are being tested out of the tests/extmod/machine_spi_rate.py file and into the target wiring code. As part of this, the test is changed to always use the default pins for the given SPI instance.

This simplifies the test, makes it easier to add support for new ports/boards, and allows reusing the spi_standalone_instances definition in other tests (if needed one day).

It also adds SPI test support for the mimxrt, nrf, renesas-ra and samd ports.

Testing

Tested by running tests/extmod/machine_spi_rate.py on (thanks to octoprobe hardware!):

  • ARDUINO_NANO_33_BLE_SENSE
  • ESP32_GENERIC_C3
  • ESP32_GENERIC_P4
  • ESP32_GENERIC_S3
  • ESP8266_GENERIC
  • PYBD_SF2
  • PYBV10
  • RPI_PICO
  • RPI_PICO_W
  • SEEED_XIAO_SAMD21
  • TEENSY40

The test passes.

Trade-offs and Alternatives

There are few decisions made here:

  1. This is not technically "target wiring" because nothing needs to be wired up. It just uses the SPI as-is to measure TX speed. But I think it's still fair enough to configure the SPI instances in the target wiring definitions. It keeps everything self contained.
  2. Always use the default SPI pins for the given instance, instead of explicitly specifying them. Most ports already did this in the test, except for rp2 and esp32, so it's not a big difference in the way the test works. And this makes it much simpler to specify the SPI instances to test, you just specify the id (or None to use the default SPI instance).
  3. The new spi_standalone_instances variable in the target wiring is a little different in name to existing variables used there, but I think it's acceptable.

This commit converts `tests/extmod/machine_spi_rate.py` to use the target
wiring mechanism, moving the port-specefic definition of the SPI instances
that are being tested out of the `tests/extmod/machine_spi_rate.py` file
and into the target wiring code.  As part of this, the test is changed to
always use the default pins for the given SPI instance.

This simplifies the test, makes it easier to add support for new
ports/boards, and allows reusing the `spi_standalone_instances` definition
in other tests (if needed one day).

Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
@dpgeorge dpgeorge added the tests Relates to tests/ directory in source label Jan 25, 2026
@codecov
Copy link

codecov bot commented Jan 25, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.38%. Comparing base (f1363d8) to head (3d9928b).

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #18726   +/-   ##
=======================================
  Coverage   98.38%   98.38%           
=======================================
  Files         171      171           
  Lines       22298    22298           
=======================================
  Hits        21937    21937           
  Misses        361      361           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Signed-off-by: Damien George <damien@micropython.org>
@dpgeorge
Copy link
Member Author

I added a README to describe the target wiring specifications and what variables need to be defined.

From that, I think the SPI variables need to be tweaked to make them more consistent with existing UART configuration variables.

Also, it's probably a good idea to move all the tests in tests/extmod/ that use target wiring into tests/extmod_hardware/, it just makes more sense that way, so you can run all tests in tests/extmod/ without having to think about target wiring configuration.

I'll move this PR to draft for now.

@dpgeorge dpgeorge marked this pull request as draft January 26, 2026 01:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tests Relates to tests/ directory in source

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant