-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use SWO (i.e. ITM_SendChar()
) rather than USB-serial converter for I/O
#317
Comments
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 I guess there would be the following TODOs:
|
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). |
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 |
The most likely cause for garbled serial output is using the wrong baud rate. I recommend going back to a simpler demo for debugging your setup. Something like https://github.com/libopencm3/libopencm3-examples. Once that is working, it should be easy to find the difference to pqm4. |
Does the code in your screenshot work with the serial comm or not?
somewhere. What command are you using to receive the output on the host? |
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 callITM_SendChar()
in place ofusart_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 usest-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.
The text was updated successfully, but these errors were encountered: