Open Source Projekt TRICE - ein Software-Tracer & Logger für alle µC: PIC, AVR, ARM, TI, Infinion,..

[Thomas H. (rokath)]

Wenn Log-Ausgaben mit printf oder einfach puts nicht oder schwer 
möglich sind, etwa im Interrupt oder Scheduler, instrumentiere den Code 
mit **TRICE**. Dadurch sinkt der Gesamt-Flashspeicherbedarf da nur 
etwa 150 Bytes Code hinzukommen, aber man erhält dafür den ganzen Platz 
den bisher die Logstrings und der printf Library Code benötigten. Man 
kann damit auch wunderbar Zeitmessungen machen, da ein TRICE sehr 
schnell geht.

Siehe https://github.com/rokath/trice

Die maschinell in Deutsch übersetzte Version:
https://translate.google.com/translate?sl=en&tl=de&u=https://github.com/rokath/trice

Nicht von der Doku abschrecken lassen, es sollte ganz ganz einfach zu 
benutzen sein für alle Arten von Prozessoren.

Gerne hätte ich dazu Feedback und wenn jemand eine Portierung beisteuern 
möchte, wäre das toll.

[eeeeeee (Gast)]

Die Firma heißt Infineon.  :-)

[Thomas H. (rokath)]

Danke, kann es leider nicht mehr korrigieren...

[David M. (milo-d)]

Hallo,

ich finde das Projekt sehr interessant. Gefällt mir ^^ Das Blockdiagramm 
ist auch sehr gelungen. Schade, dass sich hier nur so wenige gemeldet 
haben.

Ich hätte da eine Frage. Bei folgender Signatur:

 Trice8_2i( "sig:task %d -> %d: ", previousTaskID, nexTaskID );

Gibt es einen bestimmten Grund aus dem du keine variadischen Argumente 
akzeptierst ? Damit könnte man sich den Suffix _2i bzw. _ni sparen.

Ich kenne mich mit dem TRICE Quellcode nicht aus, deswegen gehe ich 
davon aus, dass dies schon seine Gründe hat ^^ Wollte diese hier nur mal 
kurz erfragen ^^

Wenn ich mal wieder was mit den stm32 boards mache, werde ich auf TRICE 
zurück kommen.

Danke für die Software :)

[Thomas H. (rokath)]

Sorry David, habe Deine Frage eben erst gesehen.

Zunächst: Es ist **kein** STM32 spezifisches Projekt, sondern sollte auf 
jedem Mikrocontroller laufen.

Variadic Arguments habe ich aus zwei Gründen vermieden:

1. Laufzeit: So ein TRICE Makro soll schnellstmöglich ausgeführt werden. 
Jegliche variadischen Argumente würden dies verlangsamen. Initial kannst 
Du
einfach schreiben ```Trice8i( "sig:task %d -> %d: ", previousTaskID, 
nexTaskID );``` oder ```Trice8( "sig:task %d -> %d: ", previousTaskID, 
nexTaskID );``` und `trice u` wird `_2` automatisch einfügen zusammen 
mit der generierten Id(123).

2. CompileTime Check: Wenn Du z.B. im Code hast ```printf( "%d", a, b 
):``` oder ```printf( "%d%d", a);``` bemerkst Du das Problem 
normalerweise erst zur Laufzeit, also beim Debuggen/Testen. Ein 
```TRICE8( "%d%d", a);``` wird mit `trice u` zu ```TRICE8_2( Id(123), 
"%d%d", a);``` da ```trice u``` nur die Formatspezifier auswertet. Der 
Compiler wird aber einen Fehler melden, da die Parameterzahl nicht 
stimmt und Du kannst es korrigieren.

[Frank M. (ukw) (Moderator)]

Thomas H. schrieb:
> Variadic Arguments habe ich aus zwei Gründen vermieden:

Beide Gründe treffen aber nicht zu. David meinte ein sog. Variadic 
Macro. Das wird zur Compilezeit vom Preprocessor umgesetzt.

Beispiele für ein Variadic Macro:

#define eprintf(...) fprintf (stderr, __VA_ARGS__)

Auch hier ist es ein Macro mit CompileTime-Check, d.h. Anzahl und Typen 
der Argumente werden at Compile Time überprüft.

Siehe auch https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

[Thomas H. (rokath)]

Vielleicht hast Du irgendwie recht, Frank, und es wäre toll einfach nur

TRICE8( Id(123), "%d%d", a, b);

final im Code zu haben.
Augenblicklich aber keine Idee wie das ohne Laufzeit 
Geschwindigkeitsverlust Compiler unabhängig umsetzbar wäre.
Wenn Du beispielsweise auf diese beiden Definitionen aus der FLEX 
Codierung schaust:

#define TRICE8_1i( id, pFmt, d0 ) do{ \
    TRICE_HTON_U32PUSH( id|0x0100|triceCycle ); \
    triceCycle++; \
    TRICE_HTON_U32PUSH( (uint8_t)(d0) ); \
} while(0)

#define TRICE8_2i( id, pFmt, d0, d1 ) do{ \
    TRICE_HTON_U32PUSH( id|0x0200|triceCycle ); \
    triceCycle++; \
    TRICE_HTON_U32PUSH( TRICE_U8_JOIN(d0,d1) ); \
} while(0)

Wie könnte dann TRICE8 als variadic Macro geschrieben werden? Wenn es 
dafür eine akzeptable Lösung gibt setze ich das gerne um.

(Mod: C-Formatierung korrigiert)

[Frank M. (ukw) (Moderator)]

Thomas H. schrieb:
> Wie könnte dann TRICE8 als variadic Macro geschrieben werden?

Hm, das wird wohl dann doch komplizierter, wenn nicht gar unmöglich. 
Dazu müsste ich mir mal in Ruhe die anderen Makros wie 
TRICE_HTON_U32PUSH und TRICE_U8_JOIN anschauen. Leider habe ich für den 
Rest des Abends keine Zeit, vielleicht morgen.

[Klaus H. (klummel69)]

Hi Thomas,

schönes Projekt! Den Ressourcenverbrauch von printf auf kleinen µC hat 
mich auch immer gestört.
Und warum soll ein µC sich mit der Konvertierung rumschlagen, wenn ich 
das Ganze sowieso nur über die Schnittstelle am PC ausgebe. Ich habe 
etwas ähnliches gebastelt aber das ist nicht so ausgereift wie dein 
Projekt (Läuft immerhin auf STM32 und AVRs).
Hier ein bisschen Feedback von mir (wobei das eher persönlicher 
Geschmack ist, das Projekt ist gut umgesetzt. Sorry, falls ich was 
übersehen habe.)

* Die Idee mit der automatischen Instrumentierung und der Vergabe der 
IDs ist OK. Ich bin allerdings kein Freund davon Sourcecode zu 
überschreiben. Hatte mal Probleme mit einem Tool, das Code 
instrumentalisiert hat und dabei einen Fehler eingebaut hat. Aber mit 
ordentlichen Diff Tools ist sowas ja durchaus aufdeckbar.

* Fliesskomma Typen sind bisher nicht berücksichtigt, oder? Zumindest 
für ARM Controller sinnvoll.

* Ich würde in der Datei til.json noch Dateiname und Sourcecodezeile 
speichern. Dann kann diese gleich bei der Ausgabe mit angegeben werden. 
Ich liebe es, wenn man aus dem Log-Fenster mit Klick direkt in den Code 
springen kann. (Gefahr ist natürlich, dass die Zeilennummern bei 
vergessenem Update nicht mehr passen).

* Die Encrypt Idee ist Klasse. Für "einfachen" Schutz gut nutzbar.

* Ich hätte die Endianess Unterscheidung weggelassen. Sowas kann auch 
die Empfängerseite machen.

* Schön auch die Einbindung der RTT Schnittstelle. Deutlich performanter 
als vieles andere.

* Das Variadic Macro Problem hatte ich auch. Eine bessere Lösung hatte 
ich auch nicht.

* Das Makro ``#define Id(n) (n)`` halte ich für gefährlich. Den 
Bezeichner "Id" nutze ich immer mal wieder. Könnte zu Kollisionen mit 
anderen Modulen kommen. Besser wäre einen eigenen Namensraum per Makro 
Prefix zu nutzen, z.B. ``#define TRICE_ID(n) (n)``. Noch sicherer: einen 
eigenen Datei-Typ definieren. Dann meckert ggf der Compiler.

* Mir fehlt noch ein Wrapper für Logging, so dass je Modul und Loglevel 
Meldungen statisch/dynamisch ein/ausgeschaltet werden können. Aber das 
kann man natürlich auch selber drum herum bauen. Dafür würde sich aber 
natürlich auch die Id() anbieten. Statt dass das Id() Makro direkt den 
Wert ausgibt, mapt man die Zahl z.B. über eine enum. Dann kann man vor 
dem Compilieren die Ausgabe Konfigurieren.

Inzwischen schreibe ich Code nur noch in C++ und nutze printf nur in 
Notfällen. Die Ausgabe erfolgt per überladenem Stream operator. Dadurch 
entfallen die vielen Trace Macro-varianten und jede Überladung nutzt 
automatisch die richtige Implementierung. Ist aber ein komplett anderer 
Ansatz (und ich will jetzt um Gotteswillen nicht wieder diese 
Diskussionen um C/C++ anfachen.)

Ein tolles Projekt! Schönen Sonntag.

[Klaus H. (klummel69)]

Jetzt ist mir doch eingefallen, wie man TRICE8 als variadic Macro 
schreiben kann. Ist sogar recht simpel. Intern brauchst Du allerdings 
weiterhin die Makros TRICE8_1, TRICE8_2...

Die Vorgehensweise wird in https://stackoverflow.com/a/11763277/2931984 
beschrieben.

Hier ein Beispiel das mit 1...4 Parametern umgehen kann.

#define TRICE8_GETNAME(_1,_2,_3,_4, NAME,...) NAME
#define TRICE8(id, ...) TRICE8_GETNAME(__VA_ARGS__,TRICE8_4,TRICE8_3,TRICE8_2,TRICE8_1)(id, __VA_ARGS__)

Dann müsste sowas funktionieren

TRICE8(Id(18031),"START");
TRICE8(Id(17033),"x=%d", 1);
TRICE8(Id(17243),"%d,%d", 1,2);
TRICE8(Id(17121),"%d,%d,%d", 1,2,3);

[Klaus H. (klummel69)]

Update: Der Parameter frmt zählt nicht zu den variablen Daten.

#define TRICE8_GETNAME(_1,_2,_3,_4, NAME,...) NAME
#define TRICE8(id,frmt, ...) TRICE8_GETNAME(__VA_ARGS__,TRICE8_4,TRICE8_3,TRICE8_2,TRICE8_1)(id,frmt, __VA_ARGS__)

[Thomas H. (rokath)]

Hi Klaus,

vielen Dank für Deine Nachricht - weiter unten ein paar Kommentare:

Klaus H. schrieb:
> Hi Thomas,
>
> schönes Projekt! Den Ressourcenverbrauch von printf auf kleinen µC hat
> mich auch immer gestört.
> Und warum soll ein µC sich mit der Konvertierung rumschlagen, wenn ich
> das Ganze sowieso nur über die Schnittstelle am PC ausgebe. Ich habe
> etwas ähnliches gebastelt aber das ist nicht so ausgereift wie dein
> Projekt (Läuft immerhin auf STM32 und AVRs).
> Hier ein bisschen Feedback von mir (wobei das eher persönlicher
> Geschmack ist, das Projekt ist gut umgesetzt. Sorry, falls ich was
> übersehen habe.)
>
> * Die Idee mit der automatischen Instrumentierung und der Vergabe der
> IDs ist OK. Ich bin allerdings kein Freund davon Sourcecode zu
> überschreiben. Hatte mal Probleme mit einem Tool, das Code
> instrumentalisiert hat und dabei einen Fehler eingebaut hat. Aber mit
> ordentlichen Diff Tools ist sowas ja durchaus aufdeckbar.

Da bin ich ganz bei Dir und ich habe lange darüber nachgedacht und keine
bessere Lösung gefunden. Durch die ID-Vergabepolitik (Default Random 1 
aus
ca. 1 Million) ist selbst bei größeren Projekten die Wahrscheinlichkeit
hinreichend klein für Kollisionen und eine einmal vergebene ID wird nor-
malerweise nicht mehr geändert. Problematisch kann es aber bei Library
Code sein, der in mehreren Projekten verwendet wird. Da aber durch den
-src Schalter mehrere Verzeichnisse ausgewählt und durch Nichtauswählen
ausgeschlossen werden können, lässt sich Library Code mit TRICE Makros
sicher schützen.

>
> * Fliesskomma Typen sind bisher nicht berücksichtigt, oder? Zumindest
> für ARM Controller sinnvoll.
>

Richtig. In Ermanglung passender Hardware erstmal nicht dabei, da ohne
HW nicht so easy testbar. Ist aber mit überschaubarem Aufwand 
nachrüstbar.

> * Ich würde in der Datei til.json noch Dateiname und Sourcecodezeile
> speichern. Dann kann diese gleich bei der Ausgabe mit angegeben werden.
> Ich liebe es, wenn man aus dem Log-Fenster mit Klick direkt in den Code
> springen kann. (Gefahr ist natürlich, dass die Zeilennummern bei
> vergessenem Update nicht mehr passen).
>

Ja und Nein. Derzeit bekommen mehrfache identische TRICEs auch alle die
gleiche ID (=same ID, was leicht änderbar ist =uniq ID) und damit ist 
der Ort
mehrdeutig. Auch ist til.json eher als Metafile für mehrere Projekte 
gedacht.
Man kann naürlich auch mit _LINE_ als Parameter arbeiten...auch der
Dateiname ist machbar.

Evenutell ist es sinnvoll eine zweite Datei namens location.json bei
jedem Compilerlauf projektspezifisch zu generieren mit den Zusatzdaten.
Zusammen mit unique IDs wäre es dann was Du willst.

> * Die Encrypt Idee ist Klasse. Für "einfachen" Schutz gut nutzbar.
>

An eine Banking APP hatte ich nicht gedacht :-)

> * Ich hätte die Endianess Unterscheidung weggelassen. Sowas kann auch
> die Empfängerseite machen.
>

Ist es per Default, aber es gibt wohl big-endian Targets und die
sollen es auch leicht haben können. Die Transfer-Endiannes lässt sich 
per
Compilerschalter an die Target-Endiannes anpassen.

> * Schön auch die Einbindung der RTT Schnittstelle. Deutlich performanter
> als vieles andere.
>

Und sehr hilfreich beim Debuggen und wenn kein anderes Interface da ist.

> * Das Variadic Macro Problem hatte ich auch. Eine bessere Lösung hatte
> ich auch nicht.
>
> * Das Makro ``#define Id(n) (n)`` halte ich für gefährlich. Den
> Bezeichner "Id" nutze ich immer mal wieder. Könnte zu Kollisionen mit
> anderen Modulen kommen. Besser wäre einen eigenen Namensraum per Makro
> Prefix zu nutzen, z.B. ``#define TRICE_ID(n) (n)``. Noch sicherer: einen
> eigenen Datei-Typ definieren. Dann meckert ggf der Compiler.
>

Das sind auch genau meine Bauchschmerzen, aber

TRICE64_1( TRICE_ID(103456), "%d", 7);

liest sich sehr holperig. im Vergleich zu

TRICE64_1( Id(103456), "%d", 7);

Wie meinst Du das mit dem "eigenen Datei-Typ definieren"?
Leider reicht mein Macro Programmierwissen nicht um so etwas zu machen:

TRICE##103456##_64_1( "%d", 7);

> * Mir fehlt noch ein Wrapper für Logging, so dass je Modul und Loglevel
> Meldungen statisch/dynamisch ein/ausgeschaltet werden können. Aber das
> kann man natürlich auch selber drum herum bauen. Dafür würde sich aber
> natürlich auch die Id() anbieten. Statt dass das Id() Makro direkt den
> Wert ausgibt, mapt man die Zahl z.B. über eine enum. Dann kann man vor
> dem Compilieren die Ausgabe Konfigurieren.
>

Derzeit kann man Datei-spezifisch zur Compile-Time die TRICEs 
wegschalten.
Da die TRICEs so wenig Strom brauchen kann man dynamisch auf dem Host 
machen was man will, also nur bestimmte ID-Räume anzeigen oder Kanäle in 
separate Fenster leiten. Das trice Tool hat noch viel Potential zur 
Verbesserung. Ich denke man sollte den Target Code einfach halten, auch 
in der Benutzung. Auch beinhaltet Id() einen Compile Time Shift zur 
Laufzeitoptimierung.

> Inzwischen schreibe ich Code nur noch in C++ und nutze printf nur in
> Notfällen. Die Ausgabe erfolgt per überladenem Stream operator. Dadurch
> entfallen die vielen Trace Macro-varianten und jede Überladung nutzt
> automatisch die richtige Implementierung. Ist aber ein komplett anderer
> Ansatz (und ich will jetzt um Gotteswillen nicht wieder diese
> Diskussionen um C/C++ anfachen.)
>

Ja, C++... habe den Stroustrup seinerzeit gelesen und bin nicht warm 
geworden mit C++. Man muss C++ schon sehr gut beherrschen um effektiven 
Code für embedded Devices zu schreiben. Auch ist mir C++ too rich.
In C arbeite ich gerne mit Functionpointer Tabellen und vermisse C++ 
nicht, vielleicht sind meine Projekte auch zu trivial.

> Ein tolles Projekt! Schönen Sonntag.

Und im übrigen bin ich nun ein Go Fan. Das trice Tool hatte ich in C++
angefangen und zum Glück hatte ich einen Tip bzgl. Go bekommen, sonst 
wäre
nicht das geworden was jetzt da ist.

Danke für Deine Kritik!

[Thomas H. (rokath)]

Cool, Deine Macro Anregungen, Klaus, schaue ich mir demnächst genauer 
an!

[Thomas H. (rokath)]

OK, variadic Macro würde funktionieren. Man büßt allerdings die 
implizite Verifizierung der Parameteranzahl ein. Das ist aber nicht 
schlimm, denn dem User bleibt die Wahl ob er

TRICE8( Id(0), "...%u...%b...", 1, 2);

 oder

TRICE8_2( Id(0), "...%u...%b...", 1, 2);

 schreibt. Diese Wahl hat er jetzt schon. Allerdings ändert das trice 
Tool ein TRICE8 um in ein TRICE8_2 wenn 2 Formatspezifier gefunden 
werden. Ich könnte eine zusätzliche Option für update einführen, die das 
unterbindet. Allerdings muss dann die Generierung der til.json auf etwas 
andere Weise geschehen. Merke ich mir als ein ToDo vor. Vielleicht gibt 
es noch eine gute Idee für die Id(n) Notation und dann mache ich das in 
einem Rutsch.

[Andreas M. (amesser)]

Wir hatten bei uns auchmal so etwas ähnliches in Verwendung. Die Trace 
Ids wurden dabei in einer externen Datei vorgegeben, daraus dann ein 
C-Header + C-Source mit den Trace Funktionen erzeugt die man dann 
einfach aufgerufen hat. War also nicht so ganz komfortabel zu benutzen.

Als Ausgabepfad aus dem System heraus gab es dann verschiedene Backends:
- Über DCC Register ( ich glaube das ist wie Segger RTT)
- Über UART oder USB
- Über Ethernet als "Syslog" Telegramme.[*]

[*] Dazu wurde dann aus den gesammelten Trace Ids eine c-Source erstellt 
der die ganzen printf Format-Strings wieder im Bauch hatte und mit in 
die Firmware eincompiliert war. Der hat das auf dem Chip (in einer Extra 
Task) dekodiert und auf das Netzwerk gesendet im Syslog Format gesendet. 
Syslog hat den Vorteil das der Wireshark das schön lesbar anzeigt und da 
unsere Anwendung immer Netzwerkanschlüsse hat war das sinnvoll. (Um so 
ein Syslog UDP Telegram zu erzeugen braucht man nicht mal einen IP 
Stack)

Inzwischen sind wir aber wieder auf ein Printf ähnliches system 
umgestiegen, wir haben einfach zu viele vorkompilierte Komponenten, da 
synchronisiert sich das mit fixen Ids  etwas schwierig. Da wir die 
Rechenpower haben ist das für uns so einfacher. Der Unterschied zum 
normalen printf ist jedoch, das unser "Printf" statt den String direkt 
zu formatieren, den Pointer auf den Formatstring und die va_args in eine 
FIFO wirft und diese Fifo dann in einer extra Task gelesen, formatiert 
und ausgegeben wird. (Mit Syslog und Webserver backend) Theoretisch 
könnte man auch die FIFO rauststreamen, sich am PC aus der ELF die 
Formatstrings fischen und dann extern formatieren.

Als Vorschlag würde ich bei deinen Traces noch einen "Message-Zähler" 
mitlaufen lassen. Das ist sehr hilfreich, wenn man erkennen will, dass 
die Trace FIFO übergelaufen ist. Man sieht dann auf der Ausgabe Sprünge 
in der Nummer.

[Hartmut (Gast)]

Von der GitHub-Seite:

Or build trice from Go sources

    Install Go.

Hole ich mir damit die Schnüffler von Google auf den Hals?

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Ich frage mich, warum da alle immer alles selber instrumentieren wollen.
Der GCC kann das doch automatisch... siehe "-finstrument-functions"

Du musst dann noch ein paar Funktionen definieren und schwupps, bekommst 
du von jedem functionscall einen entsprechenden callback (also für enter 
und exit).

Damit brauchst du eigentlich keine IDs mehr (das kann ja der entrypoint 
der Funktion sein) und du hast mehr Infos (nämlich die Funktion und den 
Caller!) wie z.B. mit den _LINE_ Makro.

In den FiFo schiebst du die enter und exit events und dazwischen deine 
outputs. Im postprocessing kannst du gemütlich das dann wieder 
zusammenführen.

Willst du ganz krass arbeiten, dann kann sich deine debug-print-routine 
auch vom stack die caller adresse holen.

Dein Visualisierungstool muss nur aus dem ELF die entsprechenden Debug 
Ausgaben raussuchen (was ja nicht das Thema ist, weil du die Symbole 
dafür ja kennst) und dann das filtern, was du willst.

BTDT...

Die paar zeitkritischen Funktionen, die diese Art von Instrumentierung 
nicht vertragen bekommen im Zweifelsfall das Attribut 
"no_instrument_function"...

73

[Andreas M. (amesser)]

Hans W. schrieb:
> Ich frage mich, warum da alle immer alles selber instrumentieren wollen.
> Der GCC kann das doch automatisch... siehe "-finstrument-functions"

Hans W. schrieb:
> Die paar zeitkritischen Funktionen, die diese Art von Instrumentierung
> nicht vertragen bekommen im Zweifelsfall das Attribut
> "no_instrument_function"...

Wenn man genug FIFO Speicher hat, dann kann man das tun. Unser Power 
Trace 32 braucht "gerade mal" 512MB für 40 Sekunden Programablauf... Im 
übrigen gibt es Anwendungen wo es nicht nur "ein paar" zeitkritische 
Funktionen gibt, sondern die Aufgabe der gesamten Firmware darin besteht 
zeitkritsche Kommunikation zu machen...

[Marc (Gast)]

Hans W. schrieb:
> Ich frage mich, warum da alle immer alles selber instrumentieren wollen.
> Der GCC kann das doch automatisch... siehe "-finstrument-functions"

Es geht hier um die Ausgabe von Daten nicht um Funktioncalls.
Ggf hat man in einer Funktion 10 Ausgaben, in anderen Funktion keine.

[Klaus H. (klummel69)]

Thomas H. schrieb:
> Derzeit bekommen mehrfache identische TRICEs auch alle die
> gleiche ID (=same ID, was leicht änderbar ist =uniq ID) und damit ist
> der Ort mehrdeutig.
Ah, ok. Dachte Du sammelst einfach alle Ausgaben ein.
UniqueIDs hätten u.a. den Vorteil dass man bei der Ausgabe danach 
filtern könnte.


>> ...#define TRICE_ID(n) (n)
> Das sind auch genau meine Bauchschmerzen, aber
> TRICE64_1( TRICE_ID(103456), "%d", 7);
> liest sich sehr holperig. im Vergleich zu
> TRICE64_1( Id(103456), "%d", 7);
> Wie meinst Du das mit dem "eigenen Datei-Typ definieren"?

Statt eines Id() Makros hätte ich eher einen Datentyp Id erstellt und 
den Wert über einen Type Cast eingefügt.
Zum Beispiel

typedef uint16_t Id;
//...
TRICE8( (Id)103456, "%d", 7);
//Oder als Compound literal geschrieben
TRICE8( (Id){103456}, "%d", 7);

Vorteil: der Datentyp Id wird durch den Compiler geprüft. Nutzt 
irgendein Stück Code
den Bezeichner Id anders meckert der Compiler.
(Der Preprozessor meckert nicht, der ersetzt einfach nur stur.)
Nachteil: Dein Tool muss halt nach (Id)123 statt Id(123) suchen.

> Derzeit kann man Datei-spezifisch zur Compile-Time die TRICEs wegschalten.
Ich nutzte oft einen Aufbau in dem ich gezielt Ausgaben ein / auschalten 
kann
(Logglevel je Modul):

LOGG(MEAS_INFO,"Temp1:%d", Temp1);
LOGG(MEAS_INFO,"Temp2:%d", Temp2);
LOGG(MEAS_ERR, "ERR: No Data");
LOGG(COMM_INFO,"COM: %d", comport);

Die Ids MEAS_INFO... sind Konstanten. Innerhalb des LOGG Makros wird 
einfach geprüft
ob die Id !=0 ist. Ansonsten wird sie nicht ausgeführt.
Dadurch kann man sehr granular konfigurieren, was einen interessiert.
Zum Beispiel nur Errors und Warnings durchlassen.
Bei zeitkritischen Ausgaben wird einfach alles was nicht nötig ist auf 0 
gesetzt = abgeschaltet.

Könnte man theoretisch auch mit deinen Ids machen, aber die sind ja 
nicht unique.
Und ich vermute es wird dann zu unübersichtlich.

> Und im übrigen bin ich nun ein Go Fan. Das trice Tool hatte ich in C++
> angefangen und zum Glück hatte ich einen Tip bzgl. Go bekommen, sonst
> wäre nicht das geworden was jetzt da ist.
Ich gebe zu, dass ich auch damit liebgeäugelt habe. Nette Sprache.
Aber allein... es fehlt die Zeit...

> Danke für Deine Kritik!
Gerne, aber Kritik würde ich das nicht bezeichnen.

[Thomas H. (rokath)]

Andreas M. schrieb:
>
> Als Vorschlag würde ich bei deinen Traces noch einen "Message-Zähler"
> mitlaufen lassen. Das ist sehr hilfreich, wenn man erkennen will, dass
> die Trace FIFO übergelaufen ist. Man sieht dann auf der Ausgabe Sprünge
> in der Nummer.

Einen Cycle Counter gibt es. Nur die short Trices verzichten ďarauf.

[Thomas H. (rokath)]

Hartmut schrieb:
> Von der GitHub-Seite:
>
>

> 
> Or build trice from Go sources
> 
>     Install Go.
> 
>

>
> Hole ich mir damit die Schnüffler von Google auf den Hals?

Go ist komplett OPEN-SOURCE.

[Thomas H. (rokath)]

Hans W. schrieb:
> Ich frage mich, warum da alle immer alles selber instrumentieren wollen.
> Der GCC kann das doch automatisch... siehe "-finstrument-functions"
>
Es gibt viele Kriterien und Wege. Compiler Unabhängigkeit, Speed, 
Minimainstrumentierung und Einfachheit in der Anwendung sind mir wichtig 
gewesen.

[Thomas H. (rokath)]

Klaus H. schrieb:
> UniqueIDs hätten u.a. den Vorteil dass man bei der Ausgabe danach
> filtern könnte.
>
Ist ja eingebaut. Nur muss es explizit  eingeschaltet werden. Siehe 
Update switch -sharedIDs
>
> Nachteil: Dein Tool muss halt nach (Id)123 statt Id(123) suchen.
>
Gute Gedanken zum Nachdenken aber besser wird es anscheinend nicht, nur 
anders.

> Und ich vermute es wird dann zu unübersichtlich.
>
Ich nenne INFO, ERR und Co. Kanäle und sie sind Teil der Formatstrings. 
Das trice Tool könnte kanalspezifisch die IDs vergeben, etwa ERR 
10000-19999 und INFO 40000-49999. Wenn es ID Range abhängig möglich wäre 
die TRICE Makros Code generieren zu lassen oder nicht wäre das THEMA VOM 
TISCH.

>> Und im übrigen bin ich nun ein Go Fan. Das trice Tool hatte ich in C++
>> angefangen und zum Glück hatte ich einen Tip bzgl. Go bekommen, sonst
>> wäre nicht das geworden was jetzt da ist.
> Ich gebe zu, dass ich auch damit liebgeäugelt habe. Nette Sprache.
> Aber allein... es fehlt die Zeit...
>
Leicht erlernbar, hoch performant und produktiv.

>> Danke für Deine Kritik!
> Gerne, aber Kritik würde ich das nicht bezeichnen.

Doch, es ist konstruktive Kritik und genau die ist wichtig.

[Thomas H. (rokath)]

Habe soeben v0.26.1 released. Da sind die variadic Macros als nutzbare 
Option umgesetzt, man kann also auf die Suffixe _1, _2, ... verzichten, 
wenn man möchte.

TRICE16( Id( 59976), "rd:%d, %d, %d, %d\n", 1, 2, 3, 4 );
TRICE32( Id( 64745), "rd:%d\n", 1 );
TRICE32( Id( 56533), "rd:%d, %d\n", 1, 2 );

Danke Klaus für den sehr hilfreichen Hinweis diesbezüglich!!!

Per default werden nun unique IDs generiert und shared IDs nur mit 
entsprechendem Schalter.

Eine Referenzliste von jeder ID in den Source Code lässt sich relativ 
einfach bauen nur habe ich noch keine klare Vorstellung wie man eine 
solche effektiv nutzen kann. Auch ist bei unterschiedlichen 
Firmwareversionen diese Info entsprechend zu verwalten.

Es wäre auch möglich die jeweils erste ID am Zeilenanfang optional 
auszugeben, was vielleicht ausreicht zur schnellen Lokalisierung im 
Code.

Falls jemand TRICE einsetzt freue ich mich über Rückmeldung. Es sollte 
weitgehend hardwareunabhängig nutzbar sein

[Thomas H. (rokath)]

Eine optionale Ausgabe der Trice IDs ist jetzt ab v0.29.3 möglich.

  -showID string
        Format string for displaying first trice ID at start of each line. Example: "debug:%7d ". Default is "". If several trices form a log line only the first trice ID is displayed.

Übrigens sind die Zahlen an den Zeilenenden des Screenshots der jeweils 
aktuelle Prozessorclock. Der Abstand 12 oder 13 bedeutet bei einer 48 
MHz Taktrate eine Zeitdifferenz von ca. 250ns. Licht schafft es in 
dieser Zeit etwa 80m weit.
Ja, und Trice hat nun ein Gesicht Dank meinem Töchterchen.
Hie nochmal der Link: https://github.com/rokath/trice

[Thomas H. (rokath)]

Habe die Schalter -pick und -ban eingeführt um einzele oder Gruppen von 
Kanälen zu selektieren oder auszusperren. Etwa

trice l -port COM7 -ban "debug,diag"

 unterdrückt die Ausgabe aller Debug- und Diagnose- Trices.

[funky (Gast)]

Bin gerade durch den Beitrag bei Interrupt drauf gestoßen. Sieht sehr 
interessant aus. Werde ich mal ausprobieren