On Sun, 24 Mar 2024 at 16:56, Arnaud Minier <arnaud.min...@telecom-paris.fr> wrote: > > This patch adds the STM32L4x5 USART > (Universal Synchronous/Asynchronous Receiver/Transmitter) > device and is part of a series implementing the > STM32L4x5 with a few peripherals. > > It implements the necessary functionalities to receive/send > characters over the serial port, which are useful to > communicate with the program currently running. > > Many thanks Peter for your review, I think I addressed almost > everything. > I'm just unsure about how to handle the waiting time in the tests. > I understand your concerns about the unreliability of using the wallclock > time but I don't understand how using clock_step() would make it > more reliable. We will always be waiting on something > that is out of our control (i.e. the OS). > I increased the delay from 5s to 10min to match the microbit test > and added a comment (I paraphrased your comment, is that okay ?).
I think I was slightly confused between two things. For a lot of qtests we do want to use clock_step() and not have wallclock-based delays, but we can only do that where the thing we're waiting for is purely simulation time (i.e. where we triggered a change via a qtest write and then want to look for the result via a qtest read). Where we're triggering something via a different OS pathway (e.g. here where we write to the socket that's backing the chardev connected to the UART and then look at the UART registers) we do need a wallclock delay. I recommend you follow Thomas's suggestions about timeouts in his comments on patch 6; I'd forgotten we have a meson timeout now too. thanks -- PMM