mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Mikrocontroller Fehler "provozieren" + workarounds


Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits

Ich bin gerade dabei, einen Mikrocontroller (ATmega2560) im Rahmen eines 
Universitätsprojektes auf verschiedene Fehler hin zu untersuchen und wie 
man diese softwaremäßig (z.B. mithilfe eins watchdogs) minimieren 
kann...
(Es geht um AVR-Mikrocontroller, die in einem mechanischen Systemen 
eingesetzt werden sollen, das sehr zuverlässig funktionieren soll, da es 
kritischen Umgeungen eingesetzt wird.)
Z.Zt. habe ich hauptsächlich einige analoge Servos und mehrere Joysticks 
an den Microcontroller angeschlossen...  Besonders Sicherheitskritisch 
sind hierbei die Signale zu den Servos.

 Da sicherlich auch die Community hier davon profitieren würde, lade ich 
zum mitmachen ein...

Ich wäre besonders froh über Vorschläge, und Erfahrungen, was schonmal 
"schiefgelaufen" ist (auch simple Sachen, wie Stecker falschrum 
einstecken, GND mit VCC verbinden, oder sonstige Kurzschlüsse 
ausgelöst.)
Hat schonmal jemand Erfahrungen mit EMV gesammelt? (z.b. daß die PWM 
Signale zu den Servos irgendwie verändert wurden)
Vielleicht kann ich auch Tests machen, die ihr euch nicht zurtraut, weil 
ihr euren Mikrocontroller damit beschädigen würdet etc etc....

Ich werde meinerseits dann versuchen, möglichst viele Ergebnisse hier zu 
posten...

Grüße, Thomas

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas wrote:
> Ich bin gerade dabei, einen Mikrocontroller (ATmega2560) im Rahmen eines
> Universitätsprojektes auf verschiedene Fehler hin zu untersuchen und wie
> man diese softwaremäßig (z.B. mithilfe eins watchdogs) minimieren
> kann...

Es ist ein weit verbreiteter Irtumm, daß ein Watchdog ein Gerät 
zuverlässiger mache, das ganze Gegenteil ist der Fall.

Insbesondere, wenn der Watchdog schon zu Beginn der Entwicklung 
verwendet wird, macht er das System extrem unzuverlässig, da er 
sämtliche Fehler im Softwareablauf oder EMV kaschiert.

Wenn es aber darum geht, Fehler in der externen Hardware zu erkennen, 
z.B. ob der Motorstrom über eine bestimmte Zeit hinaus zu hoch ist 
(Überlast), dann macht man diese Überwachungsprozesse mit den ganz 
normalen Timern direkt im Programm in Kombination mit AD-Wandlern.
Die Zuverlässigkeit wird dadurch zwar nicht gesteigert, aber 
Folgeschäden (z.B. durchgebrannte Motoren) können verhindert werden.
Und es können Diagnosemeldungen ausgegeben werden.


Wenn überhaupt ein Systemwatchdog verwendet werden soll, dann darf er 
erst ganz zum Schluß hinzugefügt werden, nachdem alle Funktionen 
einwandfrei laufen.

Ist eine Funktionserweiterung zu entwickeln, muß der Watchdog natürlich 
zuerst deaktiviert werden, damit man die dabei gemachten Fehler wieder 
erkennen kann.


Peter

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hat Peter durchaus recht, ähnlich ist es z.B. mit "asserts" in 
C-Code. Die macht man für die Release-Version am besten auch nicht raus, 
obwohl das vielerorts so praktiziert wird...
Währe wie ein Autohersteller, der die Airbags wieder ausbaut, weil "die 
ja auf der Testfahrt auf dem Firmengelände auch nicht gebraucht 
wurden"...

Beim Watchdog wäre evtl folgendes Sinnvoll:
Nach dem Reset MCUCR prüfen, wenn vom Watchdog ausgelöst:

Alle Ausgänge in "sicheren" Zustand bringen, und danach in 
Endlosschleife gehen, Warnled blinken lassen.
So sieht der Endanwender wenigstens, dass mit seinem Gerät was nicht in 
Ordnung ist, und er ihm besser nicht mehr 100%ig vertrauen sollte.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hängt ein bischen davon ab, wozu das entwickelte Teil gut ist. Wenn 
beim Ausfall einer Steuerung im Winter die Wasserrohre einfrieren, weil 
das Modul zwecks Warnung des nicht anwesenden Entwicklers fröhlich 
streikend vor sich hinblinkt, dann ist damit niemandem gedient.

Dass Watchdogs Fehler verdecken können stimmt. Aber das ist auch ein 
bischen der Sinn der Sache. Denn die Vorstellung, dass man in einem 
nicht trivialen Controllersystem innerhalb der Entwicklungsphase 
wirklich alle Fehler findet, ist etwas gewagt.

Und dann wären da noch jene Fehler, die man schlecht kontrollieren kann. 
Hardwarefehler, Stromunterbrechungen, strunzdämliche Bedienung, ...

Also: Auf das Problem hinweisen ist richtig. Deshalb gleich den Betrieb 
einzustellen oft nicht.

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ACK @  Ernst Bachmann

"asserts" -> in VB "On Error Goto Next"

für die Basic MitBürger

Gruß Fred

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um ein paar "EMV"-Erfahrungen zu sammeln kannst Du mit einem 
Piezo-Gasanzünder Hochspannung in Deine Schaltung einkoppeln.

Oder nehme ein Relais ohne Entstörschaltung und schalte den Öffner der 
Relais in seine Zuleitung. Dann hast du einen einfachen Störgenerator.

1.Grundsätzliche EMV-Bedingungen einhalten. z.B. Geschirmtes Gehäuse
2.Einkoppelung in die Versorgungsleitungen
3.Einkoppelungen in die I/O-Leitungen die aus dem Gerät herausführen.

Geht was bleibend kaputt >> Hardwareschutz verbessern. 
>>>Schutzdioden/Schutzkondensatoren/Varistoren

fällt die Software/Hardware nur während der Störung aus >> Auch 
Hardwareschutz verbessern. Störungen "wegfiltern"

"Hängt" sich die Software bleibend auf >> Dann kommt der Watchdog oder 
Systemreset.

In EMV-Laboren gibt es dafür spezielle Geräte die das qualitativ und 
quantitativ besser können. Wenn Du kein Zugang zu einem EMV-Labor hast 
musst Du die Störungen selber erzeugen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten wrote:
> ACK @  Ernst Bachmann
>
> "asserts" -> in VB "On Error Goto Next"
>
> für die Basic MitBürger
>
> Gruß Fred

Naja. Nicht wirklich.
http://de.wikipedia.org/wiki/Assert

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok ok  Simon K.

>Durch die Formulierung einer Zusicherung bringt der Entwickler eines >Programms 
seine Überzeugung über bestimmte Bedingungen während der Laufzeit >eines Programms 
zum Ausdruck und lässt sie Teil des Programms werden. Er >trennt diese 
Überzeugungen von den normalen Laufzeitumständen ab und nimmt >diese Bedingungen 
als stets wahr an. Abweichungen hiervon werden nicht >regulär behandelt, damit die 
Vielzahl möglicher Fälle nicht die Lösung des >Problems vereitelt, denn natürlich 
kann es während der Laufzeit eines >Programms dazu kommen, dass 2+2=4 einmal nicht 
gilt, z.B. weil Variablen >durch Programmfehler im Betriebssystem überschrieben 
wurden.

>Damit unterscheiden sich Zusicherungen von der klassischen Fehlerkontrolle >durch 
Kontrollstrukturen oder Ausnahmen (Exceptions), die einen Fehlerfall >als 
mögliches Ergebnis einschließen. In einigen Programmiersprachen wurden 
>Zusicherungen auf Sprachebene eingebaut, häufig werden sie als Sonderform >der 
Ausnahmen verwirklicht.


On Error Goto <Marke>

Carsten

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.