Konzept um systemweiten Fehlern

[Ludo (Gast)]

Hallo zusammen

Ich arbeite zurzeit an einem C++ embedded Projekt, bin aber mit unserem 
Errorkonzept nicht zufrieden. Wegen der limitieren Ressourcen ist die 
Verwendung von try/catch vom Kompiler nicht unterstützt.

Also ich bin auf die Suche nach einem bewährteten Konzept um 
systemweiten Fehler abzufangen und signalisieren.

Hat jemand ein Ansatz?

Vielen Dank

[Peter II (Gast)]

Ludo schrieb:
> Hat jemand ein Ansatz?

die Frage ist was bei einem fehler passieren soll. Soll das Programm 
weiter laufen oder im Fehlerstatus stehen bleiben?

C in werden dafür gerne longjumps eingesetzt.

Oder halt so wie in C überlich, bei jeder funktion erkennt man an return 
ob ein fehler aufgetreten ist.

[Ludo (Gast)]

Hallo Peter

Das Programm soll weiter laufen aber der fehler protokolliert werden 
(Ein Logging-Module ist bereits vorhanden)

Ich möchte gerne Fehlernummer herausgeben, welche die Herkunft (also 
welches Module) und die genaue Fehler identifiziert.

Was ich verhindern möchte ist eine reisen Fehlercodeliste verwalten zu 
müssen, dies soll programmiertechnisch gelöst sein.

[Peter II (Gast)]

Ludo schrieb:
> Ich möchte gerne Fehlernummer herausgeben, welche die Herkunft (also
> welches Module) und die genaue Fehler identifiziert.

> Was ich verhindern möchte ist eine reisen Fehlercodeliste verwalten zu
> müssen, dies soll programmiertechnisch gelöst sein.

ist das nicht ein wiederspruch in sich? Du willst Fehlernummer ausgeben 
aber keine Liste pflegen?

reicht dir nicht ein Makro?

#define ERROR( x )  sendError( x, _FUNTION_, _FILE_ );
enum ecodes {
  ERROR_INVALID_LEN
}

ERROR( ERROR_INVALID_LEN )

[adsf (Gast)]

Ludo schrieb:
> Was ich verhindern möchte ist eine reisen Fehlercodeliste verwalten zu
> müssen, dies soll programmiertechnisch gelöst sein.

Was soll das System dann "programmiertechnisch" machen? automatisch 
Fehlercodes zuweisen und die Liste erstellen?

[Agent_P (Gast)]

So ein kleiner 8-Bitter hat genug damit zu tun sein Programm abzuspulen, 
das übrigens schon debuggt sein sollte (dafür gibt es genügend Tools).
Fehler sollten kurz, einfach und mit wenig Aufwand 
ausgegeben/gespeichert  werden. Die Ermittelung des Moduls kostet schon 
Aufwand, den man nicht einfach übrig hat. Lange "prints" kosten z.B. auf 
dem UART tierisch Zeit.

Fehler nur als Kodenummern ausgeben und über Tabelle extern 
entschlüsseln. Wenn ich mehr haben will kann ich mir auch nen 
"richtigen" Rechner hinstellen.

Meine Meinung.

Agent_P

[adsf (Gast)]

Naja, da kann ja einiges zur Compile-Time passieren, das Programm gibt 
dann nur Zahlen aus und die Liste wurde beim kompilieren mit erzeugt.

[Ludo (Gast)]

Ich verwende ein 16 bit uC mit viel Ressoucend und OS, wenn man mit so 
ein system arbeitet kommt man um eine detailliertes Fehlerlogging. 
Deshalb meine Anfrage.

[Ludo (Gast)]

Ja, ich möchte durch definitionen und strukturen, dass ich mich nur auf 
die Fehler pro Module kummern muss, den Rest soll zur Kompilirungszeit 
erfolgen.

[Ludo (Gast)]

Hallo Peter

Ja, die Lösung mit dem Macro ist ein Ansatz.

Duch unseren Kodrichtinen (MISRA, usw.) sind Macro aber nicht erlaubt. 
Ich suche eher eine Lösung auf C++ basis.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Wie ich das gelöst habe:

Bei jedem Aufruf einer Funktion wird der aktuelle ProgramCounter (PC) in 
einer Liste gespeichert. Die Liste ist 20 Elemente groß und so sehe ich 
maximal 20 letzte Funktionsaufrufe.
Ich nutze einen STM32. Wenn nun da z.B. eine Hard-Fault Exception kommt, 
so wird alles gesperrt und per serieller Debug-Schnittstelle diese Liste 
ausgegeben. Nun kann ich im MAP File nachschauen welche 
Programm-Funktionen da aufgerufen werden und so den Fehler einkreisen.

Klappt ganz gut und hat mir schon einige Stunden Fehlersuche erspart.

Bei C++ mit Objekten müsste man vermutlich nicht nur die Speicheradresse 
sonder vielleicht besser der Name der Funktion in die Liste speichern.
Beim PC (in Pascal) mache ich es so, dass bei jedem Funktionsaufruf der 
Funktionsname mittels ADD() in eine TStringList gespeichert wird und 
wenn die Funktion verlassen wird mittels DELETE() das letzte Element 
wieder gelöscht wird. Somit ist in der Liste die ganze Aufrufhierarchie 
gespeichert.
Kommt nun eine Exception in der Applikation so wird ein globaler 
Errorhandler aufgerufen und diese Liste in das Log geschrieben.
Ist ebenfalls super einfach und man kann genau nachvollziehen was 
passierte.

Beide Möglichkeiten müssen natürlich extra programmiert werden, 
benötigen Rechenleistung und beim zweiten darf niemals ein DELETE() 
vergessen werden (z.B. bei einem Return vor dem Ende), sonst überläuft 
die Liste.

Die zweite Variante habe ich hier drin:
Beitrag "EleLa - Elektronik Lagerverwaltung ab V2.0"
Und ich kann jederzeit einem User helfen, da mir das Log den Fehler 
immer mit der entsprechenden Programmposition zeigt.

[Ludo (Gast)]

Hallo Markus

Dein Konzept scheint mir sehr passend, ich werde es genauer studieren.

Danke an alle für eure Beiträge!