MicroPython Forum (Archive)

This repo enables a running uasyncio application to be monitored. Physically the host is connected to a Pi Pico with a pair of wires (a UART tx and gnd). The Pico runs a utility. Selected coroutines on the host are prefixed with a decorator: Such coroutines are monitored and cause a pin on the Pico to go high every time they run. A scope or logic analyser enable the task execution to be monitored:



There is also provision for detection of CPU hogging, with a trigger pulse being generated if scheduling is blocked for longer than a chosen period. The above image shows this in action, with the "hog detect" pulse on line 00 triggering the logic analyser. Lines 01 and 03 are regularly running tasks, line 02 is a fast running task used for hog detection. Note that all tasks have been blocked for a period by another task which deliberately monopolises the CPU to demonstrate this detection.

The cases of tasks being interrupted by timeout or cancellation, and the case of multiple concurrent instances of a single task, are (hopefully) handled.

I could have used this in the past and I will certainly use it in the future! Nice work Peter, thanks!

I've now pushed an update which provides an alternative SPI interface. This is intended for the case where the application under test is hosted on a device with no spare UARTs.

To any existing users this is a breaking change: I had to change the Pico pin mapping to accommodate the three SPI interface connections. On the host side set_uart() is replaced by set_device().

It uses the RP2040 PIO to make a limited, special purpose, SPI slave. This is so fast that the latency is negative. (See the docs).

Love this Peter - super useful. Thank you

Thanks guys for the encouragement

I've pushed an update to the Pico with the aim of improving hog detection. The Pico now measures latency. This is potentially useful even in the absence of test equipment. The Pico code can be set up to report whenever the latency exceeds its prior maximum, printing the duration in ms. It can be set up only to issue the trigger pulse when this occurs.

Thanks, this is very useful.

Russ

I have updated this and moved it to its own repo.

The improvements stem from using it to analyse a rather challenging realtime usayncio application. The monitor's usage is now enhanced to time arbitrary segments of code. In addition to producing a trigger if blocking exceeds its prior maximum it can now also trigger if the time taken by a given code segment exceeds its prior maximum. It can also simply produce pulses at arbitrary points in the code enabling a variety of timing measurements to be made.

In pure synchronous code there are easier ways to do these things, but in any system with non-deterministic realtime behaviour, triggering a scope or logic analyser enables causes to be established and performance to be improved.

I can now see its application extending to threaded code and applications with demanding interrupt service routines.

I'd be interested in comments on this $20 backend. I'd like to know if there is any interest in the idea before I spend time tidying up the code and documenting it.

Hi Peter, I don't need it right now but at some point in the future, I will wish I did. I don't want to ask you to do more work but yes, I'm interested in it.

This is in a working state and I have written basic docs. There are some rough edges around the user interface, but it is very usable. It captures pre-trigger data and enables reasonably accurate timing measurements to be made (on the order of tens of μs). I was interested to see whether it was possible on a Pico. In practice it runs with ~53K of free RAM.

The problem is that my original back end with a good quality LA capable of capturing pre-trigger data is a better solution