Use SWO (i.e. `ITM_SendChar()`) rather than USB-serial converter for I/O

[dgazzoni]

This is a feature request to replace the current I/O implementation with one that uses the Serial Wire Output interface. In the case of ST MCUs using the ST-Link programmer, the data traffic goes through the same USB cable as the ST-Link. As such there is no need to have dangling jump wires connected to USART pins, connected to an extra piece of hardware (USB-serial converter) and the use of two USB connections to the computer -- some computers such as Apple's MacBook Airs have only two USB connectors and ideally one of these should be free for the power supply.

This would entail changing the code of hal_send_str() from libopencm3 to call ITM_SendChar() in place of usart_send_blocking(). This is the easy part and if this feature request is considered, I can contribute the required changes to this code.

However, if this approach were used, it would be no longer possible to read directly from a /dev/tty* device; one would have to use st-trace from the texane stlink package (which pqm4 already depends on). Thus it would be necessary to change all the Python scripts to use this different I/O method, and for that I'm afraid my Python skills may be too meager to contribute.

I understand there may be use cases where SWO is unwelcome (for instance, I'm not familiar with the support for SWO on programmers other than ST-Link). However, it could still be made an option alongside the existing USART I/O implementation, rather than a replacement.

[rpls]

Right now, we're in the process of switching the "main" board for benchmarking to the Nucleo-L4R5ZI, which has a directly connected serial interface. So no more cumbersome connecting of wires.

I took a look at the ITM stuff in the past, and actually used it in other projects. What kept me from taking steps was the software support on the host side. As you said, we'd have to use different tools, which may be somewhat cumbersome. And back when I worked with it, the SW support in open source tools was somewhat spotty, don't know if this is still the case. Also, I would actually like to completely move away from the st-util & co tools in favor of OpenOCD. Especially since stlink will drop MacOS support, and I'd at least like to support for Linux and MacOS for mupq/pqm4.

I guess there would be the following TODOs:

• [ ] Look into how one could use the ITM debug output in OpenOCD.
• [ ] Look into how one could capture the output in the framework.
• [ ] Check whether an active ITM changes the performance measurements (I don't see why it should, but I would want to make sure, it's a debugging feature in the core after all).

[dgazzoni]

OK. I understand from your reply that there is in principle interest in including this, so if that is the case, I can commit to investigating point #1 above (ITM on OpenOCD).

[rpls]

General interest, yeah. It would be a nice option to have, not super necessary for the new board, but a more hassle-free option for other boards. FYI, the code should then go into the mupq/mupq repository, since the general OpenOCD code is there in the platforms.py file.