www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR 8-Bit Software


Autor: Skittler Bruce (skittler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe eine Frage bezüglich den AVR 8 Bitern.
Sollte man in der Mainschleife gegebenenfalls Backups von wichtigen 
Registern anlegen um so Störungen festzustellen?

Stellt euch vor Ihr habt ein Programm geschrieben das die Main dauern 
abarbeitet. Nun kommt eine Störung (Spannungsspitze, Blitzschlag, keine 
Ahnung) Und es verändert sich ein Registerzustand.
Kann sowas passieren?

Das Programm würde eventuell nicht mitbekommen das ein Register falsche 
Werte angenommen hat. Ich seh das gerad kritisch.

Für Vorschläge, Erfahrungen und Denkanstöße bin ich dankbar.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Skittler Bruce schrieb:

> Das Programm würde eventuell nicht mitbekommen das ein Register falsche
> Werte angenommen hat. Ich seh das gerad kritisch.

Wer sagt dir denn, dass dein Blitzschlag nicht den Wert vom 
Backup-Register verändert hat, und dein Hauptregister eigentlich richtig 
wäre?

Was machst du dann?

Machst du 2 Kopien und einen Mehrheitsentscheid? Oder 5 Kopien? Oder 15?

Wer sagt dir, dass der Blitzschlag nicht das Flash so verändert hat, 
dass die Überprüfroutine fehlerhaft ist?

Irgendwann besteht dein Programm dann nur noch aus Kopien von einem 
Register und elends viel Code, der versucht festzustellen ob dieses eine 
Register noch den richtigen Wert hat.

> Für Vorschläge, Erfahrungen und Denkanstöße bin ich dankbar.

Du machst dir zuviele Gedanken.
Letztendlich läufst du immer in das gleiche Problem rein: Wer überwacht 
die Überwacher?

Autor: Gastofatz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sollte man in der Mainschleife gegebenenfalls Backups von wichtigen
>Registern anlegen um so Störungen festzustellen?

Nein. Du kannst und musst Dich darauf verlassen, dass wenigstens die 
"unterste Ebene" perfekt fehlerfrei funktioniert. Das schließt alles, 
was sich im Controller-IC befindet, ein. Insbesondere darfst Du davon 
ausgehen, dass Flash-, SRAM-, EEPROM-Zellen und Register ihren Zustand 
nicht von selbst ändern, und dass die Instruktionen eines µCs so 
ausgeführt werden, wie es im Datenblatt beschrieben ist. Natürlich unter 
der Voraussetzung, dass der µC innerhalb seiner zulässigen Grenzen 
betrieben wird (VCC, Temperatur etc.).

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ausschließen kann man ein Kippen der Bits im SRAM, Flash oder EEPROM 
nicht, nur meistens sind die Ursachen dafür bekannt, wie zum Beispiel 
ungenügend stabilisierte oder zusammenbrechende Betriebsspannung, 
radioaktive Teilchen und dergleichen mehr. Trägt man Sorge, daß diese 
Ursachen nicht stattfinden, sind die Controller sehr zuverlässig. Dafür 
wurden sie gebaut. Nicht der Controller verursacht Probleme, Programme 
tun dies.

Autor: MarioT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du kein Windows drauf spielts, passiert da nicht viel.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MarioT schrieb:
> Wenn Du kein Windows drauf spielts, passiert da nicht viel.

Das gilt aber auch für Linux...

...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und für Unix.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. schrieb:
> Und für Unix.

Stimmt, auch dafür ist der 8-Bit-AVR ein bissel zu klein...

...

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Du machst dir zuviele Gedanken.

Nun ja, ganz so von der Hand zu weisen ist die Frage nicht. Allerdings 
bezog sich die Frage spezifisch auf die Hauptschleife des Programms.

In sicherheitskritischen Anwendungen wird oft verlangt, dass 
langlebige Daten (z.B. write-once Daten wie Konfiguration, usw.) 
entsprechend gesichert werden, da hier das Zeitfenster für eine 
kritische Auswirkung eines Fehlers  besonders groß ist.

Gegenbeispiel: Wenn ich jede Millisekunde meine Ports einlese, um sie 
anschließend zu entprellen, und das Ergebnis in main() 
weiterzuverarbeiten, ist es nicht sinnvoll die gespeicherten Daten zu 
sichern, da sie sofort wieder aufgefrischt werden und sich sporadische 
Störungen vermutlich ohnehin nicht so dramatisch bemerkbar machen.

Je nach Größe des Bereichs und Rechenleistung legt man aber keine Kopie 
an, sondern bildet eine CRC über den Speicherbereich. Periodisch (also 
typischerweise nicht vor jedem Zugriff) wird die CRC verglichen und ggf 
ein Fehler gemeldet.

--
Marcus

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du schonmal ein (funktionierendes) Programm für einen 
Mikrocontroller geschrieben? Vermutlich nicht.

Selbstverständlich werden Konfigurationen in einem nichtflüchtigen 
Speicher (EEPROM beim AVR) gesichert, damit sie nach einem Reset neu 
geladen werden können. Und selbstverständlich nutzt man die 
Versorgungsspannungsüberwachung (BOD bei aktuellen AVRs) zum Auslösen 
eines Resets bei instabilen Verhältnissen. Somit wird nach dem 
Blitzschlag das Ding neu gestartet, falls es noch leben sollte. Und es 
gibt auch den Watchdog, der einen Reset auslöst, falls das Programm sich 
mal verheddert. Der ist aber in der Entwurfsphase tabu, da sich 
Programme meist durch Fehler verheddern, fast nie durch EMV.

...

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich fürchte Du hast nicht verstanden von welcher Art von Anwendungen
die Rede war.

Hannes Lux schrieb:
> Selbstverständlich werden Konfigurationen in einem nichtflüchtigen
> Speicher (EEPROM beim AVR) gesichert, damit sie nach einem Reset neu
> geladen werden können.

"Nicht-flüchtig" heißt ja nicht, dass Information auf gar keinem Weg
verloren gehen könnte. Das Ding muss ja schließlich auch zum
Programmieren verändert werden.

Man schützt ja auch oft den Programmcode mit CRC, und der liegt auch
in einem nicht-flüchtigen Speicher. Warum?

Außerdem kann ich mir in o.g. Anwendungen eine Konfiguration nach dem
Reset nicht einfach so aus einem Speicher laden (egal welchen
Typs). Wer weiß was mit den Daten zwischenzeitlich geschehen ist. Die
Konfiguration wird nach mehr oder weniger aufwändigem Selbsttest neu
ermittelt.

> Und es gibt auch den Watchdog, der einen Reset auslöst, falls das
> Programm sich mal verheddert.

Für die Fragestellung zwar irrelevant, aber in bestimmten
Sicherheitsbereichen sind interne Watchdogs nicht ausreichend für
solche Zwecke.

--
Marcus

Autor: bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich fürchte Du hast nicht verstanden von welcher Art von Anwendungen
die Rede war.

Aber du?
Der Fragesteller hat dazu nichts gesagt, du kannst das also garnicht 
wissen- es sei denn, du bist das selbst unter anderem Namen.
Dann aber würde ich die Finger von sicherheitsrelevanten Anwendungen 
lassen.

Autor: MarioT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:
> Man schützt ja auch oft den Programmcode mit CRC, und der liegt auch
> in einem nicht-flüchtigen Speicher. Warum?

Auf einem AVR?

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bensch schrieb:
>> Ich fürchte Du hast nicht verstanden von welcher Art von Anwendungen
> die Rede war.
>
> Aber du?

Der Fragesteller hat ausdrücklich um "Vorschläge, Erfahrungen und 
Denkanstöße" gebeten. Da es neben sinnlosen Beiträgen (bezüglich Linux, 
Windows, Unix) hauptsächlich solche gab, die die in diesem Zusammenhang 
zugegebenermaßen etwas einfache Vorstellung des Fragestellers abgewiesen 
haben, denke ich, dass der Hinweis auf tatsächlich genutzte 
Sicherungsmechanismen angebracht war.

--
Marcus

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MarioT schrieb:
> Auf einem AVR?

Warum nicht?

Autor: MarioT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ha

Marcus Harnisch schrieb:
> MarioT schrieb:
>> Auf einem AVR?
>
> Warum nicht?
>
>
>
>
>
>     Beitrag melden | Bearbeiten | Löschen |

Hast Du zufallig mal ein Beispiel?
Würde mich interisieren(die Vorgehensweise von so einem Programm)
Danke.

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieh es mal so:

1. Die Wahrhscheinlichkeit, dass ein Bit im Speicher kippt ist um 
Grössenordnungen kleiner als diverse andere Störungsmöglichkeiten. Merze 
zunächst mal all diese aus...

2. Selbsttests für die Fehlfunktion eines Controllers, die in diesem 
Controller selbst laufen, bringen eh nichts: Wenn irgendwo ein Bit 
kippt, ist die Wahrscheinlichkeit nämlich sehr gross, dass der 
Controller Amok läuft und damit auch die Selbtsttests nichts mehr 
bewirken.

Wenn es sicher sein soll, dann:
- einfachst möglich programmieren
- Hardware sauber aufbauen (Schutz von Versorungsspannung, IO)
- Fail-safe bauen: Wenn etwas ausfällt, dann fällt es automatisch in 
einen sicheren Zustand
- Wenn irgend eine Prüflogik, dann auf jeden Fall extern

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MarioT schrieb:
>> Auf einem AVR?
> Hast Du zufallig mal ein Beispiel?
> Würde mich interisieren(die Vorgehensweise von so einem Programm)

Ach so, hat ein bisschen gedauert :-) Das wird bei einem AVR 
natürlich schwierig. Ich hatte Deine Frage zuerst in Richtung "kleiner 
µC=>wenig Flash=>wozu testen" gedeutet.

Aber es ging ja eben um die Aussage von Hannes, dass das Speichern von 
Informationen in einem nicht-flüchtigen Speicher irgendwie sicherer sei.

--
Marcus

Autor: MarioT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:
> Aber es ging ja eben um die Aussage von Hannes, dass das Speichern von
> Informationen in einem nicht-flüchtigen Speicher irgendwie sicherer sei.

Ich hatte Hannes Aussage aber auch so verstanden, das der Aufwand und 
Nutzen die Daten zu prüfen in einem µC nicht passt. Nicht das die Daten 
richtig sicher wären.

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Marcus: Hast du diese Vorgehensweise bei einem AVR schon mal 
praktiziert und dazu Code-Beispiele?

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte ja eigentlich nichts mehr dazu sagen, aber ich wurde 
namentlich angesprochen und mir wurde dabei das Wort im Munde 
verdreht...

Marcus Harnisch schrieb u.A.:
> Aber es ging ja eben um die Aussage von Hannes, dass das Speichern von
> Informationen in einem nicht-flüchtigen Speicher irgendwie sicherer sei.

Unter "nicht-flüchtigen Speicher" versteht man üblicherweise einen 
Speicher, der bei Ausfall der Versorgungsspannung seinen Inhalt behält. 
Das heißt noch lange nicht, dass der Inhalt nicht (gewollt) per 
Programmierung oder per Software verändert werden kann.

>
> --
> Marcus

Ich habe den Eindruck, Du hast (zumindest mit 8-Bit-Controllern) noch 
keine realen Werte geschaffen und betätigst Dich eher als eine Art 
Unternehmensberater. Siehe: Youtube-Video "Volker Pispers - Berufsgruppen die diese Welt nicht braucht"

...

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MarioT schrieb:
> Ich hatte Hannes Aussage aber auch so verstanden, das der Aufwand und
> Nutzen die Daten zu prüfen in einem µC nicht passt. Nicht das die Daten
> richtig sicher wären.

Wenn der Nutzen ist, dass Dir eine Institution ein von Dir begehrtes
Zertifikat ausstellt (alternativ: verweigert), dann ist so ziemlich
jeder Aufwand recht :-)

In einer konkreten Anwendung mit einem 8 Bit µC (nicht AVR), an deren 
Entwicklung ich aktiv beteiligt war (nur um weiteren Vermutungen 
vorzubeugen) haben wir mal grob abgeschätzt, dass weit mehr als die 
Hälfe der verfügbaren Rechenleistung für Selbsttests verbraucht wurde. 
Der Rest stand der eigentlichen Applikation zur Verfügung.

--
Marcus

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux schrieb:
> Ich wollte ja eigentlich nichts mehr dazu sagen, aber ich wurde
> namentlich angesprochen und mir wurde dabei das Wort im Munde
> verdreht...

Nun ja, ich hatte darauf hingewiesen, dass man Konfigurationsdaten 
absichert und Du hast mir entgegnet:
> Selbstverständlich werden Konfigurationen in einem nichtflüchtigen
> Speicher (EEPROM beim AVR) gesichert, damit sie nach einem
> Reset neu geladen werden können.

Ich bin daher davon ausgegangen, dass Du davon ausgehst, die Daten 
seien dort sicherer aufgehoben und bedürften keiner Úberprüfung. Diese 
Annahme wäre falsch.

> Ich habe den Eindruck, Du [...] betätigst Dich eher als eine Art
> Unternehmensberater. Siehe: Youtube-Video "Volker Pispers - Berufsgruppen die diese Welt nicht braucht"

Wie Du meinst.

--
Marcus

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klaus schrieb:
> Sieh es mal so:
>
> [...]

Dein Wort in Gottes (des TÜV Prüfers) Ohr. Aber Du hast die 
allerwichtigste Regel vergessen:

0. Wenn Dir die Prüfinstitution eine Maßnahme empfiehlt, diskutiere 
nicht,
   schlage die Hacken zusammen und implementiere sie!

Glaube mir, ich hatte diese Diskussionen. Kostet nur Zeit und die hat 
ein Entwickler bekanntermaßen nicht.

Ich habe hier einen Auszug aus dem BIA Handbuch 29, "Fehlererkennende 
Maßnahmen in Mikroprozessoren". Dort findet man interessante Anregungen 
zum Thema. Speichertests gehören da noch zu den sinnvolleren Maßnahmen.

Was die Wahrscheinlichkeit von Fehlern angeht, musst Du beachten, das 
manche Industrieanlagen "ewig" laufen, ohne abgeschaltet zu werden. 
Selbst ein Ereignis mit geringer Häufigkeit kann sich da bemerkbar 
machen.

--
Marcus

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute macht die Läden dicht, die Schwarzmaler sind im Land.

Man hat ja sonst nichts zu tun (Hand vor den Kopf klatsch...).

Vielleicht glaubst Du´s nicht, aber ich habe -zig Controllerprojekte 
seit mehreren Jahren unabgeschaltet laufen und da ist noch nie ein Bit 
gekippt. Bugs, die auftraten, waren vorher eindeutig hineinprogrammiert 
worden. Inzwischen habe ich sie fast alle. Ich weiß ja nicht, was 
Mancher hier sich so anmaßt, aber die Leute, die µC bauen, sind in der 
Regel keine Warmduscher. Die Teile gurken sogar im Weltraum ´rum, also 
lehnt euch mal entspannt zurück!

Autor: frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich darf hier mal das Datenblatt vom ATmega32A zitieren:
4. Data Retention
Reliability Qualification results show that the projected data retention failure rate is much less
than 1 PPM over 20 years at 85°C or 100 years at 25°C.
Je nachdem wie sicherheitskritisch die Anwendung ist, muss man dann auch 
den Aufwand treiben, herauszufinden, ob man nun die "6 Richtigen" 
gezogen hat. Ich denke da z.B. an tonnenschwere Maschinen, die nicht 
anhalten wollen.
Frank

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1ppm ist 1 Bit auf eine Million Bit. Bei 128kByte Flash erreicht man die 
eine Million Bits gerade so. Wenn mir da in 100 Jahren eins kippt? Da 
pell ich mir ´n Ei drauf!

Bei dem Zitat aus dem DB ist von Flash die Rede. Die OP-Anfrage betraf 
Registerwerte und die liegen im SRAM. SRAM kippt nicht ohne Grund 
irgendwelche Bits, weil das sind bistabile FlipFlops.

So what?!

Autor: nüüü (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1 Controller pro 1 Mio. Controller denke ich mal, nicht Bit

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.