ITM Meldungen ausgeben (Cortex-M3 und höher)

[Hans W. (hanswieland)]

Ich habe mir überlegt, wie ich bequem Debug Meldungen über ITM ausgeben 
kann. Das Konstrukt mit den variablen Argumenten (args) ist mir 
allerdings neu. Habe ich das so richtig umgesetzt?

#include "stm32g4xx.h"
#include <stdio.h>
#include <stdarg.h>

// Output an ITM message
void debug_print(const char *ptr) {
    while (*ptr) {
        ITM_SendChar((uint32_t)*ptr++);
    }
}

// Like printf() but using ITM. Max. 80 characters.
void debug_printf(const char* format, ...) {

    // Skip if ITM is not enabled
    if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) &&((ITM->TER & 1UL) != 0UL)) {

        char buffer[81]; // change the size if needed
        va_list args;
        va_start(args, format);
        vsnprintf(buffer, sizeof(buffer), format, args);
        va_end(args);
        debug_print(buffer);
    }
}

int main() {
    ...
    debug_print("Hello World! \n");
    int i=42;
    debug_printf("value of i is %d \n",i);
}

Es funktioniert, aber ist es so auch fachlich sauber?

[Hans W. (hanswieland)]

Noch eine Frage:
Diese Zeile habe ich aus der CMSIS Bibliothek kopiert:

if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) && ((ITM->TER & 1UL) != 0UL))

Könnte man doch eigentlich auch so schreiben, oder nicht?

if ((ITM->TCR & ITM_TCR_ITMENA_Msk) && (ITM->TER & 1UL))

[Harald K. (kirnbichler)]

Der Code in den Zeilen 19 bis 22 ist soweit formal korrekt, so verwendet 
man va_list.

Unabhängig davon: Die Funktion belegt halt u.a. die Puffergröße auf dem 
Stack, das kann für eine Debugausgabe problematisch werden.

Günstiger könnte es sein, die Variante vfprintf zu verwenden, und die 
dort letztlich rausfallenden Zeichen direkt an ITM_SendChar zu 
übergeben.
Dazu musst Du allerdings rausfinden, wie in Deiner Entwicklungsumgebung 
mit printf und Dateihandles wie stdio etc. umgegangen wird.
Oft muss man nur eine lowlevel-Funktion wie _write ersetzen.


Und rein stilitisch: Was sollen die Leerzeichen vor den Zeilenumbrüchen 
in main()?

> Könnte man doch eigentlich auch so schreiben, oder nicht?

Ja, das kann man.

[Hans W. (hanswieland)]

Harald K. schrieb:
> Günstiger könnte es sein, die Variante vfprintf zu verwenden, und die
> dort letztlich rausfallenden Zeichen direkt an ITM_SendChar zu
> übergeben.

Ja das klappt.

> Dazu musst Du allerdings rausfinden, wie in Deiner Entwicklungsumgebung
> mit printf und Dateihandles wie stdio etc. umgegangen wird.
> Oft muss man nur eine lowlevel-Funktion wie _write ersetzen.

Jawoll, den Punkt kenne ich. Im Fall von Arduino schien es mir 
naheliegender, einen kleinen Puffer zu verwenden. STM32duino saut eh 
schon herum, was den Speicherbedarf angeht. Da fallen die 81 Bytes nicht 
weiter auf :-)

> Was sollen die Leerzeichen vor den Zeilenumbrüchen in main()?

Soll die Lesbarkeit des Beispiels erhöhen. In echt programmiere ich 
nicht so.

[Harald K. (kirnbichler)]

Hans W. schrieb:
> Soll die Lesbarkeit des Beispiels erhöhen.

Mir ist es als unerwartet aufgestoßen. Ich hatte mal einen Kollegen, 
der statt "\n" oder der unter Windows üblichen Sequenz "\r\n" hartnäckig 
”\n\r" verwendete, und das auch noch am Zeilenanfang statt -Ende.

Hmm.

[Hans W. (hanswieland)]

Harald K. schrieb:
> Mir ist es als unerwartet aufgestoßen.

Habe ich gemerkt, ich sehe ein, dass dies eine blöde Idee war.

[Hans-Georg L. (h-g-l)]

Harald K. schrieb:
> Günstiger könnte es sein, die Variante vfprintf zu verwenden, und die
> dort letztlich rausfallenden Zeichen direkt an ITM_SendChar zu
> übergeben.
> Dazu musst Du allerdings rausfinden, wie in Deiner Entwicklungsumgebung
> mit printf und Dateihandles wie stdio etc. umgegangen wird.
> Oft muss man nur eine lowlevel-Funktion wie _write ersetzen.

int __io_putchar(int ch) {
    ITM_SendChar(ch);
    return ch;
}

[Bauform B. (bauformb)]

Hans W. schrieb:
> Harald K. schrieb:
>> Günstiger könnte es sein, die Variante vfprintf zu verwenden,
>> und die dort letztlich rausfallenden Zeichen direkt an
>> ITM_SendChar zu übergeben.
>
> Im Fall von Arduino schien es mir naheliegender, einen kleinen
> Puffer zu verwenden. STM32duino saut eh schon herum, was den
> Speicherbedarf angeht. Da fallen die 81 Bytes nicht
> weiter auf :-)

Ein Kompromiss: der Puffer könnte static sein. So ein debug_print() 
möchte man irgendwann auch in einem fault handler benutzen, da fällt das 
auf dem Stack eher auf. Dafür lohnt sich evt. sogar Formatierung im 
Eigenbau. Wenn man auf Luxus wie %f, %*.*s verzichtet, braucht die nur 
ca. 12 Byte Puffer für beliebig lange Ausgaben. Und keine lib.

P.S. ich fände debug_printf mit 'f' schöner, gerade, wenn die die lib 
benutzt und alles kann.

[Harald K. (kirnbichler)]

Bauform B. schrieb:
> Dafür lohnt sich evt. sogar Formatierung im
> Eigenbau. Wenn man auf Luxus wie %f, %*.*s verzichtet, braucht die nur
> ca. 12 Byte Puffer für beliebig lange Ausgaben. Und keine lib.

Ich frage mich, wieviel Lebenszeit schon sinnlos verschwendet wurde, um 
krampfhaft printf() & Co. zu vermeiden, nur weil es etwas Code einspart.

Damals, als die µCs wirklich noch keinen Programmspeicher hatten, da war 
das wirklich ein Argument, aber hier geht es um irgendeinen Cortex - und 
der hat nun wirklich keine Probleme damit, die wenigen kByte einer 
printf-Implementierung unterzubringen. Und auf float-Unterstützung kann 
man immer noch verzichten; die Runtime-Libraries üblicher Compiler 
bieten genau deswegen verschieden zurechtgekürzte printf-Libraries an.

[Bauform B. (bauformb)]

Harald K. schrieb:
> Ich frage mich, wieviel Lebenszeit schon sinnlos verschwendet wurde, um
> krampfhaft printf() & Co. zu vermeiden, nur weil es etwas Code einspart.

Mir ging es drum, Abhängigkeiten zu vermeiden, Flash hat man, 
ausreichend. Mit einem printf(), das keinen Stack braucht, kann ich im 
fault handler immer noch "drucken", egal, wie groß das Chaos ist. OK, 
Hintergrund ist auch, ich lasse die Programme erstmal im RAM laufen und 
flashe selten.

Ich finde es auch angenehm, wenig bis keine fremden libs zu brauchen.

[Harald K. (kirnbichler)]

Bauform B. schrieb:
> Mit einem printf(), das keinen Stack braucht, kann ich im
> fault handler immer noch "drucken", egal, wie groß das Chaos ist.

OK, das Argument ist schlüssig.