Hallo Mich würde mal interessieren, ob man sich auch für längere Zeit auf die Beständigkeit von Registerinhalten verlassen kann. Beispiel: In einem Programm, dass im Dauerbetrieb eine Maschine überwacht, werden verschiedene Stati per Bitsetzen/-löschen in einem Register "Status" gespeichert. Kann man sich darauf verlassen, dass auch über Tage oder Monate kein Bit in einem solchen Register unbeabsichtigt "kippt", oder sollte man so ein Statusbyte besser in SRAM, EEPROM oder sonstwo speichern und bei Bedarf erst "frisch" in ein Register laden ? Was meint Ihr ? Grüße Torsten
Und wie sieht das mit Bitfehlern im "Sonstwo" aus? Ich denke, daß dieser "Status" viel eher durch Softwarefehler verfälscht wird als durch Hardwarefehler. In welchem Stadium befindet sich denn das Projekt? Bernhard
Hi Bernhard Das ist ja im Grunde meine Frage. Wo speichert man so ein Statusbyte am besten. Wenn mit Stromausfall gerechnet werden muss, nimmt man am besten einen nicht flüchtigen Speicher (EEPROM) klar. Jeder Neustart würde jedoch auch gleich wieder den Urzustand herstellen. Ich habe nur Bedenken, in der Laufzeit den "Faden zu verlieren" und dann irgendwo im Nirvana mit meinem Status zu stehen. Gegen Softwareeingriffe sollte in Register doch geschützt sein, wenn ich es schon Status nennen und nur ganz speziell darauf zugreife, oder ? Das Projekt ist bisher noch in den ersten Gedankenschritten. Ich würde es jedoch gere gleich richtig anfangen. Deshalb die Frage hier. Grüße Torsten
Register sind auch nur SRAM. Speicher den Status doch in 2 Registern. Dann kannst Du vor der Benutzung erst mal überprüfen, ob noch alles ok ist. Was kann denn ein Bit in deiner Umgebung kippen? Kosmische Strahlung? .. EMV? .. verursacht durch Motoren? .. Straßenbahn? .. Also gut abschirmen und dafür sorgen, daß Interfaces keine Störungen einkoppeln. Lässt man den uC in Ruhe werkeln gibt es sicher keinen Grund für ein spontanes Kippen.
Torsten B. schrieb: > Hi Bernhard > > Das ist ja im Grunde meine Frage. Wo speichert man so ein Statusbyte am > besten. Wenn mit Stromausfall gerechnet werden muss, nimmt man am besten > einen nicht flüchtigen Speicher (EEPROM) klar. Logisch. Irgendetwas nicht flüchtiges. > Jeder Neustart würde jedoch auch gleich wieder den Urzustand herstellen. Was meinst du mit Urzustand? Bei einem Neustart sieht man dann eben im EEPROM nach und holt sich den Wert von dort. Beim allerersten mal muss man halt dafür sorgen, dass da ein vernünftiger Wert drinn steht, aber ansonsten ist das nicht weiter ein Problem. > Ich habe nur Bedenken, in der Laufzeit den "Faden zu verlieren" und dann > irgendwo im Nirvana mit meinem Status zu stehen. Den Faden verlierst du in 99.999999% aller Fälle durch einen Softwarefehler. Sprich: Du hast einen Bug im Programm. > Gegen Softwareeingriffe sollte in Register doch geschützt sein, wenn ich > es schon Status nennen und nur ganz speziell darauf zugreife, oder ? Nicht wirklich. Wenn dein Sklave alles tut, was du ihm aufträgst und dein Auftrag lautet "Spring aus dem Fenster" dann kann dein Sklave noch so gut 'geschützt' sein. Auftrag ist Auftrag. > Das Projekt ist bisher noch in den ersten Gedankenschritten. Ich würde > es jedoch gere gleich richtig anfangen. Deshalb die Frage hier. Du machst dir an dieser Stelle unnütze Gedanken. Sieh zu, dass dein Programm fehlerfrei wird. Dann wird es viele Tage, Monate, Jahre laufen, ohne dass durch irgendein kosmisches Teilchen ein Bit ganz von alleine kippt. Die Wahrscheinlichkeit, dass das tatsächlich zu einem Problem werden könnte ist so gering, dass du den Fall getrost ignorieren kannst.
"Register gegen Softwareeingriffe schützen". Wenn nicht durch software, wodurch wird denn der Zugriff auf die Register sonst gesteuert? Aber hier kommt es auf die Prozessor-Architektur an. Harvard <-> von Neumann ... Bei Harvard sind natürlich die Register ein wenig besser geschützt, da sich das Programm in einem anderen Bereich befindet, als die Daten. Währen der Laufzeit wird sich ein Programm in der Regel nicht selbst ändern. Bei von Neumann ist das etwas anders. Hier gibt es keinen Unterschied zwischen Programm und Daten-Speicher. Natürlich kann hier ein Programm-Fehler z.B. auch dazu führen, daß man andere Teile vom Programm überschreibt - und dann vielleicht doch ein eigentlich "geschütztes" Register an ungewollter Stelle überschreibt. Auch bei Harvard muss man natürlich dem Compiler sagen, daß er genau dieses eine Register nicht beliebig verwenden kann. Bei Assembler liegt es in der Macht des Programmierers das nicht zu tun. Ist allerdings dann auch als Programmierfehler zu werten, wenn man genau das z.B. in einer ISR vergisst umzusetzen.
Hallo Torsten, ich spreche hier nicht von vorsätzlichen Software-Manipulationen, sondern von den allgemein üblichen Design- und Programmierfehlern (Experten: ca. 1 Fehler / kLoc bei Auslieferung des Produkts). Im übrigen hatte ich befürchtet, daß das Produkt schon kurz vor der Auslieferung stehe, und nachträgliches "Hineinflicken" von Qualität geht meistens ganz gewaltig in die Hose. Ich denke, daß das Register eine sinnvolle Stelle für diese Variable ist. Für den Restart-Fall nach Ausfall sollte vielleicht ein permanenter Speicher mit einer Untermenge des Status - sinnvoller Restart-Status - benutzt werden. Bernhard
@Torsten B.: >Mich würde mal interessieren, ob man sich auch für längere Zeit >auf die Beständigkeit von Registerinhalten verlassen kann. Ich verstehe deine Bedenken, da ich diese ebenfalls mal hatte. In den Anfangszeiten, wo ich mit Mikrocontrollern zu tun hatte, frischte ich noch zyklisch die SFR auf, aber das ist verrückt. Im Grunde könnte man ja dann keinem einzigen bit aus der Software mehr vertrauen. Die SFR in einem Controller sind ebensolche RAM-Zellen, wie die Stelle, wo man ein Statusbyte speichert. Für den Codespeicher kann man z.B. mal eine zyklische Checksummenüberprüfung während der Laufzeit, in die Software einbauen, oder sonstige Redundanztests, da gibt es ausreichend Möglichkeiten, wenn man das möchte. Solange man keine groben Schnitzer in der Software hat, sollte es in integrierten Halbleiterschaltungen möglich sein, ein Statusbit bis in alle Ewigkeit (Stromausfall) in einem Register zu behalten. Integrierte Halbleiterschaltungen haben intern die höchsten elektrischen Feldstärken, die in der Elektrotechnik vorkommen. Allein von daher sind sie sehr robust gegen äußere Einflüsse. Industrielle Steuerungen, auch sicherheitskritische, laufen über Jahre hinweg, bis man den Strom abschaltet. Ich bin sicher, dir fallen da einige Anwendungen in deiner Umgebung ein. Man mag sich ja nicht vorstellen, daß mal alle Ampeln an einer Kreuzung auf grün stehen... Ansonsten gibt es da batteriegepuffertes SRAM oder EEPROM für wichtige Betriebsparameter, die über einen Ausfall hinweg gerettet werden müssen. ESD und EMV z.B. stören natürlich ab einem bestimmten Maß. Da sind selbstverständlich die entsprechenden Vorkehrungen zu treffen.
Das ist alles eine Frage der Wahrscheinlichkeiten und des Risikos im
Fehlerfall.
Das regelmäßige Auffrischen von Variablen verkürzt das Zeitfenster, in
der eine Störung einen Fehler verursachen kann.
Viel wichtiger als die Vermeidung ist es aber, einen Fehler zu
erkennen. Dazu kann man den Status z.B. über eine Prüfsumme oder
auch CRC absichern. Man macht das üblicherweise nicht für jeden Wert
einzeln, sondern über eine Datenstruktur, die mehrere Variablen
enthält. Diese Prüfsumme wird dann möglichst zeitnah vor dem Auswerten
der Daten mit dem Istwert verglichen.
Da ein erkannter Fehler zumeist eine Fehlerroutine aufruft, sinkt die
Verfügbarkeit des Systems. Das kann ebenfalls kritisch sein. Die
Verfügbarkeit könnte mittels ECC erhöht werden, wobei natürlich das
Auftreten des Fehlers in einem Log registriert werden sollte.
> Register sind auch nur SRAM.
Nun ja, im Allgemeinen nicht. Das spielt hier aber keine Rolle.
Gruß
Marcus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.