STM32: Logging library choices

[dkonigs]

So I'm getting started figuring out STM32, and like many developers I appreciate being able to have my code generate log messages out the serial port. I'm also planning to use FreeRTOS for my project, if that helps to provide some background.

Ideally, I'd like to use some sort of well-written logging library for doing this, rather than simply hacking together HAL_UART_Transmit calls (directly or via printf redirection). I'm trying to figure out what options are out there, and I honestly haven't been able to find much.

As far as I know, two choices have come up so far...

• Take the ESP_LOG code from the ESP32 platform's ESP-IDF, and port it to STM32 (This isn't very hard, and I actually just did a first pass at it.)
• Take the "iot_logging" code from Amazon's FreeRTOS AWS Reference Integrations project, and hope I can free it from depending on a lot of code in that project I don't particularly care about. (and I'm not thrilled about having "Iot" prefixes all over the place either)

Are there any other good options for this that I'm not considering?

(I actually really like bits of how the ESP32 logging code works, but lifting code from the framework for a totally different MCU feels a little weird.)

[nuclearcat]

Consider using SWO instead of uart.
And probably avoid printf, especially %f, STM32 has few nasty bugs related to combination of it with FreeRTOS. Hint - anything that invoke dynamic memory allocation internally might not work well with Cube implementation of FreeRTOS.

[dkonigs]

While that doesn't actually answer my question, it did lead me down a rabbit hole on issues relating to FreeRTOS on STM32 that has caused me to add a whole bunch of bookmarks that I'll definitely be reviewing closely as I get farther along in this project :-)

My main question has more to do with finding that front-end library that manages the generation of logging messages from within your code, rather than the back-end function that actually spews the formatted log message out some I/O device (which all of these libraries do generally let you rewrite however you see fit.)

[Sal Ammoniac]

If you're using a Segger J-Link, an even better option is RTT: https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/

[MosherIV]

One thing you can do is to put the code that updates the serial data in the idle task of freeRToS.

You free up some software interaction by using dma. I am pretty sure you can use dma from memory to the uart, then the peripheral manages outputing the chars.

[dkonigs]

I'm still surprised there aren't really any obvious answers on this one. I know everyone had helpful suggestions for the best way to emit text out a debug port, but that's not really what I was asking about.

So after seeing how much baggage I'd have to drag along to use the "iot_logging" library, I ended up just porting over the ESP_LOG framework from ESP32's ESP-IDF.  It really wasn't that difficult to do, is fairly self-contained, and gives me pretty much everything I need.  There might be a few places in the guts I'll need to tweak in the future, but this gets the job done.

[techman-001]

If you're using a Segger J-Link, an even better option is RTT: https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/

Which is pretty much what I have been using with Mecrisp-Stellaris Forth for a while, but it doesn't need a Segger J-Link as any Stlink device will do.
https://mecrisp-stellaris-folkdoc.sourceforge.io/swdcom.html#swdcom

 

[Doctorandus_P]

You can use any library made for logging that formats data in some kind of way useful to you. That library does not have to be STM32 specific.

The only specific part for your STM32 is a function to output that data, and that depends on where you want to log to. UART, SWO, I2C flash chip, uSD card, SPI RF dongle, etc.

If you want a completely pre-baked solution, maybe the "arduino" or the "mbed" frameworks work for you. Those may have logging functions built in.

[dkonigs]

You can use any library made for logging that formats data in some kind of way useful to you. That library does not have to be STM32 specific.

This is true, but I still don't see you (or anyone else) offering any recommendations whatsoever on libraries they've found useful for this purpose. (And sometimes there are semi-platform-specifics, such as if they hook into the APIs of some RTOS for mutexes.)

The only specific part for your STM32 is a function to output that data, and that depends on where you want to log to. UART, SWO, I2C flash chip, uSD card, SPI RF dongle, etc.

And any decent logging library does let you, as the user, hook in your own function for handling this part.

If you want a completely pre-baked solution, maybe the "arduino" or the "mbed" frameworks work for you. Those may have logging functions built in.

Unless you're actually aware of logging libraries built into, or on top of, these frameworks to point at as examples, that doesn't really help.

[zeke]

Ideally, I'd like to use some sort of well-written logging library for doing this, rather than simply hacking together HAL_UART_Transmit calls (directly or via printf redirection). I'm trying to figure out what options are out there, and I honestly haven't been able to find much.

Are there any other good options for this that I'm not considering?

Yes, here is one more option for you:
https://github.com/armink/EasyLogger

[dkonigs]

Yes, here is one more option for you:
https://github.com/armink/EasyLogger

Thanks!  This is exactly the sort of thing I was actually looking for!

Unfortunately all of the documentation, commit history, issues, etc, are in Chinese. However, the code itself is (thankfully) commented/named in English and seems quite straightforward and easy to understand. I'm definitely going to check it out.

[poorchava]

Library for debug output? Seriously? How hard is it to dump stuff via UART at 2mbit or whatever?

What does this library do that UART dump + some C#/java/python app doesn't do?

[poorchava]

Consider using SWO instead of uart.
And probably avoid printf, especially %f, STM32 has few nasty bugs related to combination of it with FreeRTOS. Hint - anything that invoke dynamic memory allocation internally might not work well with Cube implementation of FreeRTOS.

The only thing needed is to redefine malloc and free to use the FreeRTOS functions. Works like a charm even with creating complex C++ objects with new()