# Testing the embedded Rust ecosystem

I want to make it easier to test Rust drivers and HALs. To that end I want to start a project which includes hardware to test physical interfaces. And also test cases which run on that hardware and the device under test to validate it is performing as expected.

At the end my vision is to have a rack full of MCUs and devices that can be connected together to run tests of HALs against known devices or other controllers, run tests of drivers on different MCUs and have all devices USB and Ethernet ports connected to PCs to check if those interfaces work with common PCs.

But for the start having a tester that can act as a device for interfaces like SPI, I2C, and PWM should suffice. That is already enough to develop an embedded-hal test-suite that can check if a HAL implements the given traits correctly.

For know I am still juggling these ideas and am happy about any questions, feedback or pointers to existing resources.

Goals
-----

* Ensure that HALs and drivers continue to just work
* Make it easier to have hardware in the loop (HIL) tests for new components
* Allow users to run their tests on no_std platforms in CI
* Ensure that changes in the compiler do not negatively impact embedded targets

Outline
-------
### Level 0 (<-- currently here)

* Check if there is a need for this
* Ask people for ideas
* Identify relevant interfaces that should be tested
* Find a name
* Croupier (A person that shuffles cards (PCBs))
* Meteor (A crater being plugged in)
* Switchboard (Connecting together devices on customer request)

### Level 1

* Create an embedded-hal(-nb|-async)? test suite
* Check if the same test cases can be used for blocking, nb, and async
* Create a Arduino Uno compatible carrier for a proof of concept tester (RP2040?)
* Testers interfaces are connected to the headers to act as a device
* Tester runs logic which stimulates or reacts to the test cases running on the device under test
* Test first HALs
* STM32 (Nucleo-64, Nucleo-144)
* NRF52
* ATSAMD51 (Metro M4)
* ... (other MCUs where boards with Arduino Uno headers exist)
* Collect learning and check if this is useful to the ecosystem

### Level 2

* Expand test suite to more complex protocols
* USB
* Ethernet
* Create a test suite for a device driver class like [embedded-storage](https://docs.rs/embedded-storage), [accelerometer](https://docs.rs/accelerometer), or [embedded-graphics](https://docs.rs/embedded-graphics/)
* Create a carrier board that houses many of the supported devices on one board and allows individual connections to these from an on-board MCU

### Level 3..

* Add power-measurement to allow testing sleep-modes
* Package everything nicely to fit into racks ([case-idea](https://www.reichelt.com/nl/en/subrack-set-for-connectors-and-railway-technology-bgt-22380-12-p345202.html?&nbc=1))
* Add an interconnect bus (with analog switches) to connect arbitrary MCUs to arbitrary
* devices
* debug probes
* Create a "smart" USB hub that can connect a USB device to different hosts, and can handle USB-OTG switchero