Mikrocontrollerprojekt: Assertion bei Fehlerfall

Gast #2377235
Lesenswert?

Ich habe für meinen Controller eine assert.h Datei gefunden:
1
#undef assert
2

3
#ifndef  _STDIO_H
4
#include <stdio.h>  /* prototype for 'printf' */
5
#endif  /* _STDIO_H */
6

7
#ifndef  _STDLIB_H
8
#include <stdlib.h>  /* prototype for 'abort' */
9
#endif  /* _STDLIB_H */
10

11
#ifndef NDEBUG
12

13
#define assert(_expr)                \
14
  ((void) (!(_expr) ?              \
15
    printf("Assertion failed: (" #_expr ") file %s, line %d\n",    \
16
       __FILE__, __LINE__), abort() : (void) 0      \
17
  ))
18

19
#else
20

21
#define  assert(_expr)    ((void) 0)
22

23
#endif  /* NDEBUG */

Wie setzt man so eine Funktionalität in einem Hauptprogramm richtig ein 
?
Gast #2377243
Lesenswert?

> ich möchte in meiner Applikation (Ansi C) einen Assertion auslösen.

Dann hast du bereits ein laufendes printf mit einem Ausgabemedium fuer 
stderr?

> Wie setzt man so eine Funktionalität in einem Hauptprogramm
> richtig ein?

Ich sag mal man setzt es garnicht ein weil man besser seinen Debugger 
anwirft wenn man Probleme hat. Und notfalls wenn man armer Schuele ist 
oder anderweitig benachteiligt <BG> dann tut es wohl auch ein einfach 
printf oder eine LED an einem Port.

Olaf
#2377251
Lesenswert?

Assert sind gut aber auf einem kleinen µC nicht so sinnvoll. Denn: Wie 
und wo lässt du dir denn deine Assert Meldung ausgeben?

Prinizpiell geht es so, dass man sich im Code immer wieder Bedingungen 
überlegt, die erfüllt sein müssen. Und diese Bedingungen setzt man in 
eine Assertion. Wenn dann zur Laufzeit, in der Debug Version, diese 
Bedingung nicht erfüllt ist, dann 'meldet' sich diese Assertion und 
weist einen frühzeitig darauf hin, das eben diese Bedingung nicht 
erfüllt war.

Assertions sind ein reines Debug-Hilfsmittel. Im Auslieferungscode sind 
sie dann nicht mehr enthalten.
Gast #2377352
Lesenswert?

Karl Heinz Buchegger schrieb:
> Assertions sind ein reines Debug-Hilfsmittel. Im Auslieferungscode sind
> sie dann nicht mehr enthalten.

Dass machen ich seit Jahrzehnten anders. Die bleiben bei fast allen 
PC-Anwendungen drin. Zwar fliegt dem Kunden eventuell die Anwendung um 
die Ohren, aber sie rechnet nicht mit falschen Daten weiter.

Bei Embedded-Anwendungen habe ich keine assert()s. Allerdings triggere 
ich schon mal einen Reset, wenn eine kritische Bedingung nicht mehr 
gegeben ist. Wenn möglich wird zuvor noch ein Fehlercode ins EEPROM 
geschrieben.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren