Other backends for debug_printf()

[dresco]

Thanks for adding the additional serial stream debug output options.

It would be useful to add support for debugger interfaces like SWO or Segger RTT. These would normally be written with printf(), with driver code to override the output - like this for SWO.

Would it be possible to add a similar debug_printf() implementation that targets printf() when enabled, and a NOP if DEBUG is not defined?

[terjeio]

Thinking aloud...

One way could be to use the DEBUGOUT symbol to direct the output? E.g. add something like this here:

#ifdef DEBUGOUT

#if DEBUGOUT == -1

#include "core_cm4.h"

void debug_write (const char *s)
{
    char c;

    while((c = *s++))
        ITM_SendChar(c);
}

void debug_writeln (const char *s)
{
    debug_write(s);
    debug_write(ASCII_EOL);
}

void debug_printf (const char *fmt, ...)
{
    char debug_out[DEBUG_BUFFER];

    va_list args;
    va_start(args, fmt);
    vsnprintf(debug_out, sizeof(debug_out) - 1, fmt, args);
    va_end(args);

    debug_writeln(debug_out);
}

bool debug_stream_init (void)
{
    return true;
}

#else

static stream_write_ptr dbg_write = NULL;
...

Perhaps make debug_write a weak function that could be overridden in a more appropriate location (out of the core since availability will be board specific)?
Another option could be adding the output as a grblHAL stream and not modify the core?

[dresco]

I quite like the idea of making debug_write (or even debug_printf) a weak function that could be overriden locally in the driver.

Both the SWO and Segger RTT implementations already override the low level GCC _write function, so debug_printf could just call printf directly for either of these? Don't know whether there is actually any benefit to bypassing the debug_out buffer etc, just a thought...

[terjeio]

I have now committed the code above with debug_write() as a weak function.

Both the SWO and Segger RTT implementations already override the low level GCC _write function, so debug_printf could just call printf directly for either of these?

Will this be true for all supported platforms/processors? When this is confirmed then such a change may make sense.

Don't know whether there is actually any benefit to bypassing the debug_out buffer etc, just a thought...

Having the buffer allows for setting a breakpoint in debug_printf () and inspect the buffer if no output is available?

[dresco]

I have now committed the code above with debug_write() as a weak function.

Thanks, will migrate my scattered printf() calls across..

Will this be true for all supported platforms/processors?

Good question. Believe SWO is a standard feature on Cortex M3, M4, & M7, although I have only used on ST parts.

Is not available on M0 though, so for those (or for other boards where the SWO pin is already used), Segger RTT can be used - does require a JLink adapter though. I have one here, so will give both options a sanity check..

[dresco]

Hi @terjeio

Have tested locally on the H7 driver. Is working well over SWO/RTT, and when DEBUGOUT is defined to a spare serial port.

However, I get a hardfault when console is on USB connection and DEBUG is defined without DEBUGOUT. It seems get_tx_buffer_count() is null for the USB stream?

core/stream.c

Line 764 in 8b9b785

while(hal.stream.get_tx_buffer_count()) // Wait until message is delivered

[terjeio]

Oops, I tested with my Nucleo-64 board and that does not have USB...
I'll check for hal.stream.get_tx_buffer_count != NULL in the next build.

[dresco]

I'll check for hal.stream.get_tx_buffer_count != NULL in the next build.

Thanks, I've pushed an update to the H7 driver. Should also work as-is for F3, F4, F7..

Defaults to SWO, but can be overriden to use Segger RTT with a DEBUGOUT_BACKEND definition. Also overrides the printf() backend in both cases, as noticed a few libraries where that may be used for log output (LwIP, littlefs, USB etc).