Consider integrating parts of LPC845 Test Stand

[hannobraun]

I've been working on a client project this year that included lots of improvements to this HAL. In addition, the client insisted on having automated tests for all features that I add. This resulted in the creation of LPC845 Test Stand.

LCP845 Test Stand basically consists of the following parts:

• A test suite for some LPC8xx HAL APIs, running on the host PC.
• Libraries for communication between the test suite and firmware.
• The target firmware, which uses the HAL APIs as directed by the test suite.
• The assistant firmware, which assists the test suite in directing the target and verifying its results.

Both target and assistant run on LPC845-BRK boards.

Right now, the test stand is specific to the LPC845/LPC845-BRK, but I've structured it in such a way that separating the LCP845 test suite and target from infrastructure components should be relatively straight-forward (there's been talk about a project that would include creating a test suite for another HAL, which would require me to work on this separation, but nothing's set in stone yet).

I'd like to suggest the possibility of moving the LPC845-specific parts (which by extension also cover the LPC82x) into this repository, basically hosting the test suite here and adding the infrastructure parts of the test stand as a dependency of that test suite. I don't think we should necessarily do that now or in its current form. I just want to start the discussion. (There's also the question of manpower. I might not be able to do this work any time soon.)

The test stand in its current form has some drawbacks, most of which we might want to fix before integrating it here:

• It is not fully automated. It would be nice to integrate probe-rs to automatically flash firmware, use a USB library to make sure the test suite talks to the right serial ports, etc. Right now, you need to do some manual work (connecting USB plugs in the right order; having two terminals open for running cargo embed, a third for running cargo test).
• The assistant board board brings a lot of complexity with it, mostly in the form of lots of wiring between target and assistant. This is necessary for what my clients wants to do with it, but I think it's largely unnecessary for a HAL API test suite. What the assistant mostly does currently is serve as a counterpart for USART/I2C/SPI, but I think we can achieve the same effect using simpler means (as all those peripherals support some form of loopback mode). For our use case here, it should be possible to do away with the assistant completely and have everything run on a single LPC845-BRK.

Once the test stand has been improved and simplified sufficiently, I believe it would be a great asset for this project. It would give us instant feedback on how changes affect existing functionality. Integrating it would require adding the following crates to the repository:

• Test suite: This is a standard crate with tests and some wrappers around test stand APIs, to provide the tests with a tailor-made API for their specific use case.
• Test target: The firmware that does the actual testing, as directed by the test suite. Currently, there's only one big target firmware (which is in need of some clean-up), but if we had the aforementioned automation based on probe-rs, we could have small and focused firmwares (e.g. one for I2C, one for SPI, one for async USART, one for sync USART, etc.).
• Protocol library: A small no_std library that defines the protocol the suite and the target use to communicate. Communication is currently based on Postcard/Serde.

I would suggest to add all those crates in a new subdirectory, to not clutter things up too much.

So much for the possible plan. I think it would be great if we could make this happen some time. I'd be interested in your thoughts, @david-sawatzke.