Buffered Debug Log (IDFGH-11811)

[mickeyl]

Is your feature request related to a problem?

I love logging. Unfortunately, for handling hardware events, logging via UART completely messes up the timing.

The ESP_LOG functions are very helpful, however they're not buffered.

Describe the solution you'd like.

I'd like to have a configuration option in sdkconfig, so that we could send ESP_LOG entries to memory -- and then an ultra low priority task would pick them up and commit it to the UART. Of course, it needs to have a (configurable?) maximum number of in-flight-messages / buffer size.

Describe alternatives you've considered.

I tried using other peripherals like TM1638, LEDs, Buzzer, etc. to signalize, but it's always much more cumbersome than using ESP_LOG.

Additional context.

On systems with an ultra-low-power coprocessor, instead of using a FreeRTOS task with minimal priority, we could perhaps hand over printing to the ULP. Yes, this will only work if hardware events come burst-wise. This solution will not work if there is a fast continuous stream of events, which would quickly exhaust memory (unless we also use PSRAM to buffer... but the ULP has no access to that memory I'm afraid).

[igrr]

Hi @mickeyl, We do have an updated version of logging framework in development, it will allow you to get such behavior.

In the meantime, you can implement buffering yourself using one of these methods:

• increase buffering for stdout stream using setvbuf function (e.g. disable the line-buffered mode)
• implement custom output handler function (with buffering) and redirect stdout to it using stdout = fwopen(...) early in app_main
• redirect only esp_log output to a custom handler using esp_log_set_vprintf

[ammaree]

I support this request and can add the following suggestions:

1. Using the RTC Slow SRAM as buffer, it can be accessed from both MCU’s and preserved across reboots.
2. Functionality to support the logging to a SYSLOG host in proper syslog format
3. Additional syslog level selector to determine priority level of messages destined for syslog server in addition to console.
4. Adding the task name, function name and MCU# to syslog output
5. Option to persist host destined SYSLOG messages to FFS/LFS should IP stack not yet be connected.

We have all the above functionality in our LOG replacement module and, although a bit convoluted, it works very well in aiding remote/offline debugging

On 23/12/31, 16:51, "Ivan Grokhotkov" @.**@.>> wrote:

Hi @mickeylhttps://github.com/mickeyl, We do have an updated version of logging framework in development, it will allow you to get such behavior.

In the meantime, you can implement buffering yourself using one of these methods:

• increase buffering for stdout stream using setvbuf function (e.g. disable the line-buffered mode)
• implement custom output handler function (with buffering) and redirect stdout to it using stdout = fwopen(...) early in app_main
• redirect only esp_log output to a custom handler using esp_log_set_vprintf

— Reply to this email directly, view it on GitHubhttps://github.com/espressif/esp-idf/issues/12906#issuecomment-1872967383, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAYT7GDGAUH2SBZNG5V3ZJDYMF3V5AVCNFSM6AAAAABBIIQE5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSHE3DOMZYGM. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ammaree]

Some additional thoughts....

1. We have a configurable inactivity timeout on the UART port. If no keystroke received from the UART port for a period of (1->16 in our case) minutes the info remain in the Slow RAM buffer until the next keystroke activates output again.

2. We have a flag on the buffer that can be set by any task using ESP_LOGX to (temporarily) halt output from the buffer to the UART should the task represent an alternative destination ie Telnet of HTTP where the console output should be redirected.