Hallo, bisher hatte ich viel mit 8 Bit PICs zu tun und konnte die meisten Steuer-Register der verschiedenen Controller-Funktionen im Betrieb reinitialisieren (mit den Initialiserungswerten) ohne ihre Funktion zu beeinflussen. Zur Zeit programmiere ich den ATtiny841. An welchen Steuer-Registern darf ich hierbei im Betrieb eine Reinitialisierung vornehmen, ohne die Funktion des Controllers zu beeinflussen, bzw. an welchen Registern darf ich das nicht? Für alle Tipps sage ich schon einmal herzlichen Dank.
Ungar schrieb: > An welchen Steuer-Registern > darf ich hierbei im Betrieb eine Reinitialisierung vornehmen, ohne die > Funktion des Controllers zu beeinflussen, bzw. an welchen Registern darf > ich das nicht? Das verrät dir das Datenblatt. So ganz verstehe ich den Sinn deiner Reinitialisierung aber nicht...
Ungar schrieb: > An welchen Steuer-Registern darf ich hierbei im Betrieb eine > Reinitialisierung vornehmen, ohne die Funktion des Controllers zu > beeinflussen, bzw. an welchen Registern darf ich das nicht? Steuerregister sind speziell dafür da, Funktionen des µC zu beeinflussen. Welche willst du denn da genau "reinitialisieren", ohne dass diese "Reinitialisierung" etwas bewirken oder beeinflussen soll?
:
Bearbeitet durch Moderator
Ingo Less schrieb: > So ganz verstehe ich den Sinn deiner > Reinitialisierung aber nicht... Wenn durch EMV, Höhenstrahlung, Hard- oder Softwarefehler usw. plötzlich eine der Funktionen im µC anders als gewünscht funktioniert, dann kann das gerade bei Systemen mit langen Zeiten bis zum nächsten Neustart sehr negative Auswirkungen haben. Eine zyklische Reinitialisierung kann das in vielen Fällen verhindern.
Lothar M. schrieb: > Welche willst du denn da genau "reinitialisieren", ohne > dass diese "Reinitialisierung" etwas bewirken oder beeinflussen soll? Möglichst alle, denn jede Funktion die eigentlich ausgeschaltet bleiben sollte kann im eingeschalteten Zustand unerwünschte Effekte erzeugen.
Für jedes IO-Register steht ganz ausführlich im Datenblatt, ob und welche Einschränkungen es gibt. Z.B. gibt es für manche Änderungen ein Freigabebit, welches zuerst gesetzt werden muß, um dann die Änderung für 4 CPU-Zyklen freizuschalten. Und manche Bits müsen mit 1 beschrieben werden, um sie auf 0 zu setzen.
Ungar schrieb: > Wenn durch EMV, Höhenstrahlung, Hard- oder Softwarefehler usw. plötzlich > eine der Funktionen im µC anders als gewünscht funktioniert, Sag doch gleich das du einen Sateliten baust...
Ungar schrieb: > Eine zyklische Reinitialisierung kann das > in vielen Fällen verhindern. Das ist ganz großer Quatsch. Wenn Du HW- oder SW-Fehler machst, dann suchen gefälligst den Fehler und verschleiere ihn nicht. Ein MC muß jahrelang ohne Neuinitialisierung laufen können, sonst bist Du nicht der Richtige für diesen Job.
Peter hat Recht. Wenn sich Register "zufällig" selber verändern, dann ist das in >>99,99% der Fälle ein Softwareproblem. Und das gehört behoben. Ungar schrieb: > Wenn durch EMV, Höhenstrahlung, Hard- oder Softwarefehler usw. plötzlich > eine der Funktionen im µC anders als gewünscht funktioniert, dann kann > das gerade bei Systemen mit langen Zeiten bis zum nächsten Neustart sehr > negative Auswirkungen haben. Welches dieser Probleme hast du tatsächlich? > Eine zyklische Reinitialisierung kann das in vielen Fällen verhindern. Man "kann" auch sonst noch viel machen, wie z.B. einen zweiten µC laufen lassen, um den ersten zu überwachen. Letztlich ist es aber so, dass die allermeisten Fehler eben nicht duch Fehlfunktionen, sondern durch Programmierfehler und falsche Annahmen des Programmierers passieren. Ein sehr beliebter Fehler ist das mehrfache direkte Abfragen eines Portpins in einer "Hauptschleife":
1 | if (PinA == 1) then { |
2 | tu_was(); |
3 | alter_Zustand_vom_PinA = PinA; |
4 | }
|
Denn ein einfahcer Störimpuls auf dem PinA wird dafür sorgen, dass zwar tu_was() ausgeführt wird, aber beim zweiten Einlesen vom PinA dort schon wieder 0 ist. Das kann dann woanders eigenartige Effekte hervorrufen.
:
Bearbeitet durch Moderator
Peter D. schrieb: > Ein MC muß jahrelang ohne Neuinitialisierung laufen können, sonst bist > Du nicht der Richtige für diesen Job. Du scheinst etwas härtere Anwendungsfälle aus der Praxis nicht zu kennen. Besitzt Du eigentlich einen PC, der nie einen Neustart benötigt?
Ungar schrieb: > Wenn durch EMV, Höhenstrahlung, Hard- oder Softwarefehler usw. plötzlich > eine der Funktionen im µC anders als gewünscht funktioniert Und wie sorgst du dafür, dass die Werte nicht unterwegs auf dem Prozessorbus, Prozessorregistern, Flash, RAM kaputt gehen? Oder dass die entsprechenden Speicher-Instruktionen ("OUT", "ST") im Programm sich ändern? Viele Register haben Zusatzfunktionen, die durchs Beschreiben ausgelöst werden (z.B. UART-Sende-Register - Beschreiben bewirkt Absenden), da macht das kaum Sinn. Außerdem haben viele Peripheriemodule interne "unsichtbare" Zustände; nur weil die Peripherieregister die selben Inhalte haben, sind die internen Zustände noch lange nicht gleich. Wenn man also "blind" die Register wiederherstellt kann sich die Peripherie in einem komplett anderen Zustand befinden und dann Unsinn machen.
Hallo, Ist das eventuell ein erster Aprilscherz Beitrag?
Lothar M. schrieb: > Wenn sich Register "zufällig" selber verändern, dann ist das in >>99,99% > der Fälle ein Softwareproblem. Und das gehört behoben. Du meinst, bei Deinen Geräten liegt die mittlere Fehlerwahrscheinlichkeit bei 10.000 Stunden? Danach darf es dann rauchen?
Dr. Sommer schrieb: > Wenn man also "blind" die Register wiederherstellt kann sich die > Peripherie in einem komplett anderen Zustand befinden und dann Unsinn > machen. Richtig. Genau das möchte ich vermeiden. Deshalb frage ich nach den möglichen Registern für diese Aktion.
Ungar schrieb: > Du scheinst etwas härtere Anwendungsfälle aus der Praxis nicht zu > kennen. Doch. Ich hatte z.B. den Fall, daß ein AVR bei Überschlägen im 15kV-Teil seinen Flash teilweise vergaß. Ursache war eine fehlerhafte Masseführung. Den Strompfad von Transzorbdioden am Filamentanschluß sollte man besser nicht über DGND des MC führen. Nach Korrektur der Platine waren Überschläge in der Röntgenquelle kein Problem mehr.
Ungar schrieb: > Du meinst, bei Deinen Geräten liegt die mittlere > Fehlerwahrscheinlichkeit bei 10.000 Stunden? Schon wieder eine Aussage falsch interpretiert. Passiert dir das öfter? Ungar schrieb: > Besitzt Du eigentlich einen PC, der nie einen Neustart benötigt? Meinst du, die Software auf deinem PC wäre auch nur annähernd "fehlerfrei"? Oder meinst du, es würde ausreichen, die nicht benötigten Systemregister des PCs ab&zu zu "reinitialisieren"? Ungar schrieb: > Deshalb frage ich nach den möglichen Registern für diese Aktion. Wenn du es unbedingt willst, kannst du bedenkenlos all die Register auf ihren Initialwert zurücksetzen, von denen du die dahinterstehende Funktion nicht brauchst. Der Witz ist aber, dass du mit deiner "Reinitialisierung" im Zweifelsfall sowieso zu spät dran ist, weil der µC bis dahin ja schon eine Fehlfunktion hatte und deine "Reinitialisierungsroutine" deshalb gar nicht mehr aufgerufen wird. Ich habe µCs am Laufen, die ganz ohne Reinitialisierung über Jahre hinweg unter Spannung die ihnen zugedachte Funktion erfüllen. Deren Programme sind aber auch wirklich einfach. Da passt schon fast kein Fehler rein... ;-) Welches der von dir angesprochenen Szenarien hast du tatsächlich?
Ungar schrieb: > Du meinst, bei Deinen Geräten liegt die mittlere > Fehlerwahrscheinlichkeit bei 10.000 Stunden? Wie kommst Du auf diese Zahl? Ein SW-Fehler kann sich nach Sekundenbruchteilen oder auch erst nach Jahren auswirken. Daher gehört er behoben.
Lothar M. schrieb: > Welches der von dir angesprochenen Szenarien hast du tatsächlich? - EMV-Beeinflussung deutlich über den üblichen Anforderungen (d.h. Norm) - ggf. Rauch
Ungar schrieb: > Deshalb frage ich nach den möglichen Registern für diese Aktion. Das dürften so wenige sein, dass man es auch gleich lassen kann. Viel sinnvoller wäre es, Plausibilitätsprüfungen und Feedbacks einzubauen - z.B. schauen ob ankommende ADC-Werte das typische Rauschen aufweisen oder "eingefroren" sind, Kommunikation (UART, SPI, I²C) sollte man sich grundsätzlich bestätigen lassen, eine PWM könnte man per Hochpassfilter prüfen usw. Wenn ein Fehler festgestellt wird, resettet man die entsprechende Peripherie und startet sie komplett neu (inkl. Anschwingphasen, Kalibration, und was da jeweils noch zu gehört), anstatt blind die Registerwerte neu zu schreiben. Die nächste Stufe sind dann mehrere Kanäle mit unterschiedlichen uC.
Dr. Sommer schrieb: > anstatt blind die Registerwerte neu zu schreiben. Es ist klar, das dies nur ein Teil der benötigten Maßnahmen ist. Dafür ist es aber sehr einfach und liefert deutlich messbare Ergebnisse, z.B. beim Burst-Test der Schaltung.
Hallo, Ungar schrieb: > Peter D. schrieb: >> Ein MC muß jahrelang ohne Neuinitialisierung laufen können, sonst bist >> Du nicht der Richtige für diesen Job. > > Du scheinst etwas härtere Anwendungsfälle aus der Praxis nicht zu > kennen. Deine Anwendungsfälle kenne ich nicht, bei meinen läuft es, durchaus auch jahrelang wenn es sein muß. > Besitzt Du eigentlich einen PC, der nie einen Neustart benötigt? Ja. Sogar einen Windows-PC. Dazu noch mehrere in einer kleinen Firma, wo auch nur bei Stromausfällen oder bei von mir durchgeführten Windows/Software-Updates ein Neustart gemacht wird. 2 RasPi's könnte ich auch noch dazuzählen, einige AVR und ESPs durchaus auch. Gruß aus Berlin Michael
Ungar schrieb: > Dafür ist es aber sehr einfach und liefert deutlich messbare Ergebnisse, > z.B. beim Burst-Test der Schaltung. Weil du dann messen kannst dass z.B. die I²C-Peripherie abstürzt weil du im falschen Moment unpassende Werte in die Register schreibst und dann gar nichts mehr geht?
Ungar schrieb: > Es ist klar, das dies nur ein Teil der benötigten Maßnahmen ist. > Dafür ist es aber sehr einfach und liefert deutlich messbare Ergebnisse, > z.B. beim Burst-Test der Schaltung. Ich hatte mit Reinitialisierung noch nie messbare Ergebnisse. Wenn Fehler bei der Schutzbeschaltung oder Masseführung gemacht wurden, dann hilft auch nur, diese zu beheben. Ich hoffe mal ehrlich, daß ich keine Geräte kaufen oder benutzen muß, die Du entwickelt hast.
:
Bearbeitet durch User
Dr. Sommer schrieb: >> Dafür ist es aber sehr einfach und liefert deutlich messbare Ergebnisse, >> z.B. beim Burst-Test der Schaltung. > > Weil du dann messen kannst dass z.B. die I²C-Peripherie abstürzt weil du > im falschen Moment unpassende Werte in die Register schreibst und dann > gar nichts mehr geht? Ich spreche hier von Messreihen mit genormtem Messaufbau. Michael U. schrieb: >> Du scheinst etwas härtere Anwendungsfälle aus der Praxis nicht zu >> kennen. > Deine Anwendungsfälle kenne ich nicht, bei meinen läuft es, durchaus > auch jahrelang wenn es sein muß. Dafür kenne ich die Ergebnisse von direkten Vergleichen mit Wettbewerbsprodukten mit normgerechtem Messaufbau.
Peter D. schrieb: > Ich hoffe mal ehrlich, daß ich keine Geräte kaufen oder benutzen muß, > die Du entwickelt hast. Zumindest indirekt wirst Du mit hoher Wahrscheinlichkeit mit diesen Geräten schon in Kontakt gekommen sein.
Mir stellt sich gerade zusätzlich folgende Frage: Nehmen wir mal an, du hast wirklich so besondere Anforderungen und Umgebungen, die bspw. ein (oder mehrere) Bit(s) in einem (oder mehreren) Register(n) kippen lassen können. Wie stellst du denn sicher, dass die Variable, welche bei der Re-Initialisierung in das Register geschrieben wird denn nicht auch in Mitleidenschaft gezogen wurde? - Oder, dass das Register ursprünglich einen korrekten Inhalt HATTE, aber jetzt einen fehlerhaften Wert bekommt?
Ungar schrieb: > Ich spreche hier von Messreihen mit genormtem Messaufbau. Aha, und was hat das mit einer verkehrten Neu-Initialisierung zu tun? Was bringt ein sinnloses Überschreiben von Peripherieregistern bei einem Messaufbau?
Stefan S. schrieb: > Wie stellst du denn sicher, dass die Variable, welche bei der > Re-Initialisierung in das Register geschrieben wird denn nicht auch in > Mitleidenschaft gezogen wurde? - Oder, dass das Register ursprünglich > einen korrekten Inhalt HATTE, aber jetzt einen fehlerhaften Wert > bekommt? Auch dieses Problem kann weitgehend gelöst werden, ist aber kein Teil meiner Frage. Dr. Sommer schrieb: > Aha, und was hat das mit einer verkehrten Neu-Initialisierung zu tun? Wieso verkehrt? Die Reinitialisierung soll korrekt initialisieren. Ich würde mich nach wie vor über Antworten freuen, die meine Eingangsfrage berücksichtigen.
Ungar schrieb: > Ich würde mich nach wie vor über Antworten freuen, die meine > Eingangsfrage berücksichtigen. Wie schon gesagt, die Antwort steht im Datenblatt. Manche Bits sind nur lesbar oder nicht auf 1 setzbar. Ungar schrieb: > an welchen Registern darf > ich das nicht? Es gibt da keine weiteren Einschränkungen.
:
Bearbeitet durch User
Ungar schrieb: > Dafür ist es aber sehr einfach und liefert deutlich messbare Ergebnisse Deshalb wäre es wohl das einfachste, mal ein Programm zu machen, das überprüft, ob der Rauch oder die ESD-Pulse überhaupt was an diesen Registern ändern. Also einfach mal den gesamten Registersatz nach einem Reset nur einlesen und gegen das Datenblatt vergleichen (ggfs. an undefinierten Bits ausmaskieren). Und dann mit dem ESD draufkloppen und schauen, ob sich diese "unbeschriebenen" Register mit diesem Puls ändern. Im selben Zug kannst du dann auch das RAM 1x mit einem Testmuster beschreiben und während des ESD-Puls-Tests nur noch lesen und z.B. gegen das Flash vereichen. Ich würde mal mit einem durch Erfahrung begründeten "educated guess" behaupten: bei einem anständig layouteten und geblockten µC passiert da nichts. Und wenn doch, dann kannst du dir weiter Gedanken machen, ob eine Reinitialisierung da in irgendeiner Weise irgendwas gut machen könnte.
:
Bearbeitet durch Moderator
Ungar schrieb: > Wieso verkehrt? Die Reinitialisierung soll korrekt initialisieren. Und wie soll das gehen? Wie bereits erläutert, ist ein simples Überschreiben der Register eben nicht korrekt und führt wahrscheinlich zu Fehlverhalten. Dr. Sommer schrieb: > Außerdem haben viele Peripheriemodule > interne "unsichtbare" Zustände; nur weil die Peripherieregister die > selben Inhalte haben, sind die internen Zustände noch lange nicht > gleich.
Lothar M. schrieb: > Und dann mit dem ESD draufkloppen und > schauen, ob sich diese "unbeschriebenen" Register mit diesem Puls > ändern. > Im selben Zug kannst du dann auch das RAM 1x mit einem Testmuster > beschreiben und während des ESD-Puls-Tests nur noch lesen und z.B. gegen > das Flash vereichen. Versuche in dieser Richtung haben bestätigt, dass sich RAM-Inhalte durch äußere Einflüsse ändern lassen und dass eine Reinitialisierung Software deutlich stabiler machen kann.
Dr. Sommer schrieb: > Ungar schrieb: >> Wieso verkehrt? Die Reinitialisierung soll korrekt initialisieren. > > Und wie soll das gehen? Wie bereits erläutert, ist ein simples > Überschreiben der Register eben nicht korrekt und führt wahrscheinlich > zu Fehlverhalten. > > Dr. Sommer schrieb: >> Außerdem haben viele Peripheriemodule >> interne "unsichtbare" Zustände; nur weil die Peripherieregister die >> selben Inhalte haben, sind die internen Zustände noch lange nicht >> gleich. Bei den meisten 8-Bit-PIC-Controllern muss man nur die UART/USART/EUSART von diesen Maßnahmen auslassen. Bei allen anderen Registern ist es (von wenigen Ausnahmen abgesehen) absolut unkritisch. Ich höre aus dieser Aussage heraus, dass sich PICs wohl etwas definierter verhalten als Tinys.
Dr. Sommer schrieb: > Dr. Sommer schrieb: >> Außerdem haben viele Peripheriemodule >> interne "unsichtbare" Zustände; nur weil die Peripherieregister die >> selben Inhalte haben, sind die internen Zustände noch lange nicht >> gleich. Bei den ATmega kann sich die interne Statemaschine des I2C auch ganz ohne Störungen verhaken, z.B. im Multimasterbetrieb macht sie das gerne (und häufig). Da man diese aber nicht direkt auslesen kann, geht das nur indirekt über ein Timeout festzustellen. Dann muß man das I2C disablen, um es zurück zu setzen. https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html
Ungar schrieb: > Bei den meisten 8-Bit-PIC-Controllern muss man nur die UART/USART/EUSART > von diesen Maßnahmen auslassen. Wenn du das doch weißt (woher?), wieso fragst du dann... Es fällt mir schwer zu glauben, dass z.B. Timer, I²C, ADC kein einziges Flipflop haben, das nicht per Register zugänglich ist. Dazu kommt, dass die Peripherie die Register-Inhalte ja "live" bearbeitet. Wenn man da jetzt stumpf aus der Software gleichzeitig drüber bügelt, bekommt man Race Conditions und es geht unvorhersehbar durcheinander. Wer sagt denn, dass nach Reinitialisieren des 2. Registers das 1. nicht schon wieder geändert wurde? Bei der normalen Initialisierung schreibt man alle Werte und startet dann die Peripherie; bei deiner Reinitialisierung greift man auf Register zu, die gerade in Verwendung sind. Wenn man schon so besondere Anforderungen an die Zuverlässigkeit erfüllen muss, sollte man vielleicht einen weniger naiven Ansatz wählen. Peter D. schrieb: > Dann muß man das I2C disablen, > um es zurück zu setzen. Aha, genau sowas mein ich!
Ungar schrieb: > Versuche in dieser Richtung haben bestätigt, dass sich RAM-Inhalte durch > äußere Einflüsse ändern lassen Welches Wirkprinzip war da zuständig? Das können wohl nur Einkopplungen über die Versorgung gewesen sein, oder beamst du da mit Mikrowellen drauf? > Versuche in dieser Richtung haben bestätigt ... > dass eine Reinitialisierung Software deutlich stabiler machen kann. Welche Register reinitialisierst du denn dann da, damit die Software hinterher stabiler läuft? Und wie bewertest du die "Stabilität" der Software?
Dr. Sommer schrieb: > Wenn du das doch weißt (woher?), wieso fragst du dann... Es fällt mir > schwer zu glauben, dass z.B. Timer, I²C, ADC kein einziges Flipflop > haben, das nicht per Register zugänglich ist. Ich habe nach dem Tiny gefragt, nicht nach den PICs, wo z.B. allgemein gilt: Timer = unkritisch I2C = rücklesen der Spannungen am jeweiligen Port beachten, somit nicht unkritisch und nur bedingt möglich ADC = unkritisch ...
Ungar schrieb: > Timer = unkritisch > ADC = unkritisch Eine starke Aussage, ist das bei Microchip offiziell so angegeben?
Lothar M. schrieb: > Und wie bewertest du die "Stabilität" der > Software? Eigenes Gerät: Stürzt z.B. bei direkter Einkopplung von 4 kV-Burst im Schnitt nach 10 Minuten ab. Fremdgerät: Stürzt z.B. bei direkter Einkopplung von 4 kV-Burst im Schnitt nach 20 Sekunden ab.
Dr. Sommer schrieb: >> Timer = unkritisch >> ADC = unkritisch > > Eine starke Aussage, ist das bei Microchip offiziell so angegeben? Es gab dazu einige Gespräche mit Applikationsingenieuren von Microchip, ansonsten sind diese Aussagen mit dem Datenblatt konform.
Ungar schrieb: > Eigenes Gerät: Stürzt z.B. bei direkter Einkopplung von 4 kV-Burst im > Schnitt nach 10 Minuten ab. > Fremdgerät: Stürzt z.B. bei direkter Einkopplung von 4 kV-Burst im > Schnitt nach 20 Sekunden ab Bei sonst gleicher Hardware (gefragt war ja die Stabilität der Software)? Und wie ist ein "Absturz" definiert? > bei direkter Einkopplung von 4 kV-Burst Wie koppelst du einen Burst "direkt" ein?
Ungar schrieb: > Es gab dazu einige Gespräche mit Applikationsingenieuren von Microchip, > ansonsten sind diese Aussagen mit dem Datenblatt konform. Steht das da so klar? Wenn nicht, müssen die Register und Hardware-Interna schon sehr exakt definiert sein und es muss eindeutig sichtbar sein, dass da keine versteckten Flip-Flops sind. Die Ableitung einer solchen Aussage ist schon kompliziert, da kann man sich leicht vertun. Frag die Applikationsingenieure doch einfach auch nach AVR... Was spricht nochmal genau gegen eine saubere Neu-Initialisierung der jeweiligen Peripherie?
Dr. Sommer schrieb: > Was spricht nochmal genau gegen eine saubere Neu-Initialisierung der > jeweiligen Peripherie? Dass die Applikation nicht neu startet, sondern bereits läuft. Lothar M. schrieb: > Bei sonst gleicher Hardware (gefragt war ja die Stabilität der > Software)? > Und wie ist ein "Absturz" definiert? > >> bei direkter Einkopplung von 4 kV-Burst > Wie koppelst du einen Burst "direkt" ein? Es waren wie bereits gesagt Messreihen, aus dehnen verschiedene Aussagen ablesbar waren. Trotzdem nochmal zu meiner eigentlichen Frage: An welchen Steuer-Registern darf ich beim ATtiny841 im Betrieb eine Reinitialisierung vornehmen, ohne die Funktion des Controllers zu beeinflussen, bzw. an welchen Registern darf ich das nicht?
Ungar schrieb: > Dass die Applikation nicht neu startet, sondern bereits läuft. Du musst die Applikation nicht neu starten, um eine Peripherie neu zu initialisieren. Ungar schrieb: > An welchen Steuer-Registern darf ich beim ATtiny841 im Betrieb eine > Reinitialisierung vornehmen, ohne die Funktion des Controllers zu > beeinflussen Das kann dir niemand außer den Atmel(Microchip)-Leuten beantworten, welche die Schaltpläne haben. Wahrscheinlich sind das nur ganz wenige Register.
Ungar schrieb: > I2C = rücklesen der Spannungen am jeweiligen Port beachten, somit nicht > unkritisch und nur bedingt möglich Nun, der ATtiny841 hat nur ein Slave-I2C, also ist das unkritisch. Das SPI kann durch Störungen am /SS-Eingang in den Slavemode wechseln, aber dafür gibt es ein Statusbit, um es zu erkennen. Gerne gemachter SW-Fehler, erst das SPI als Master setzen und danach /SS als Ausgang.
Peter D. schrieb: >> I2C = rücklesen der Spannungen am jeweiligen Port beachten, somit nicht >> unkritisch und nur bedingt möglich > > Nun, der ATtiny841 hat nur ein Slave-I2C, also ist das unkritisch. Beim PIC kann sich die SDA-Leitung sowohl beim Slave, als auch beim Master verhaken, sobald man irgendwo auf das Port zugreift, zu dem die SDA-Leitung gehört. Da ich in meiner Tiny-Applikation aber keinen I2C benötige, ist das absolut egal, solange die I2C-Funktionen ausgeschaltet bleiben.
Ungar schrieb: > Eigenes Gerät: Stürzt z.B. bei direkter Einkopplung von 4 kV-Burst im > Schnitt nach 10 Minuten ab. Nun, dann muß man eben die Ursache ermitteln. Als erstes liest man im Startup-Code das MCUSR aus, welche Quelle den Reset verusacht hat. Ist kein Bit gesetzt, dann liegt ein SW-Problem vor und das Programm ist einfach in 0x0000 hinein gelaufen. Typisch sind dafür Pointerprobleme, z.B. überschriebene Arrays und Variablen. Eine häufige Möglichkeit ist auch, daß die Störungen externe Interrupts in sehr hoher Folge triggern und damit Pufferüberläufe verursachen. Aber das ist ursächlich auch ein SW-Fehler, daß Pufferüberläufe nicht abgefangen werden. Sämtliche Signale von außen können beliebig gestört sein und müssen auf Konsistenz geprüft werden. Sie dürfen nie die interne Statemaschine (Mainloop) aus dem Tritt bringen können. Wo koppelst Du überhaupt was ein? Bei mir ist kein MC-Pin von außen direkt zugreifbar. Mindestens sind Vorwiderstände mit Transzorbdiode dran oder Optokoppler. Ungar schrieb: > Fremdgerät: Stürzt z.B. bei direkter Einkopplung von 4 kV-Burst im > Schnitt nach 20 Sekunden ab. Sowas habe ich schon in der Schule nicht gemocht: "Herr Lehrer, der Karl hat ja auch nicht seine Hausaufgaben gemacht!"
:
Bearbeitet durch User
Peter D. schrieb: > Sie dürfen nie die interne Statemaschine > (Mainloop) aus dem Tritt bringen können. Die kann ich aber außer Tritt bringen, wenn ich den Burst kapazitiv direkt in den Chip einkopple. Dazu wird eine Prüfsonde (Kondensatorplatte mit Burst) direkt mittig auf das Chip-Gehäuse gelegt, die Gegenelektrode ist der Tisch mit der Metallplatte unter der Platine. Wenn der Burst sehr feinfühlig eingestellt wird, dann lässt sich die Software damit leicht anticken. Mit dieser Anordnung und etwas Intuition ist vieles aufzuspüren, wo die Software hängen bleiben kann oder merkwürdige Dinge macht. Mit jedem so erkanntem und behobenen Softwareproblem wird die Software ein wenig stabiler, d.h. sie läuft auch bei stetig größer eingestelltem Burst immer besser. Am Ende stehen dann die normgerechten Messungen, wo dann häufig die Wettbewerbsprodukte im Vergleich sehr alt aussehen.
Ungar schrieb: > Dazu wird eine Prüfsonde > (Kondensatorplatte mit Burst) direkt mittig auf das Chip-Gehäuse gelegt, > die Gegenelektrode ist der Tisch mit der Metallplatte unter der Platine. Wozu soll sowas gut sein? Das ist bestimmt nicht im Rahmen der Spezifikationen von Microchip. Ist Dein Gerät für den Betrieb mit offenem Gehäuse vorgesehen?
Ich weiß ja nicht, ob du absichtlich eine gewisse Spannung aufbaust - von welcher Norm reden wir eigentlich? Bzw. in welchem Produktsegment befinden wir uns da, dass die Wahrscheinlichkeit hoch ist, persönlich von der Konkurrenz betroffen zu sein? Ein Attiny grenzt die Komplexität des machbaren wohl ein. Mein Tip wäre meine blöde Fernbedienung oder was am Auto? Ich hoffe du fühlst dich nicht zu sehr attackiert, aber dass du beharrlich Stillschweigen warst, außer von den massiven Problemen beim Mitbewerb zu reden, generiert Neugier und macht mich ein wenig stutzig. Wenn die Norm den Killer Test vorschreibt und die Konkurrenz macht da in Sekunden die Grätsche: wie können die die Norm dann erfüllen? Und einige Leute hier haben auch schon mehr gesehen als man denkt und vielleicht Ideen...
Ungar schrieb: > Mit dieser Anordnung und etwas Intuition > ist vieles aufzuspüren, wo die Software hängen bleiben kann oder > merkwürdige Dinge macht. Mit jedem so erkanntem und behobenen > Softwareproblem wird die Software ein wenig stabiler, d.h. sie läuft > auch bei stetig größer eingestelltem Burst immer besser. Wenn überhaupt, dann kann das nur bei extrem einfachen Programmen irgendeinen Effekt haben. Komplexe Programmabläufe müssen sich darauf verlassen können, daß Register, RAM und Flash nicht einfach nach Lust und Laune ihren Inhalt ändern. Die Strukturgrößen der IO-Register dürften auch deutlich größer sein, als die der RAM- oder Flashzellen. D.h. bei direkter Störbestrahlung der CPU dürften sie als letztes umkippen.
Peter D. schrieb: > Komplexe Programmabläufe müssen sich darauf verlassen können, daß > Register, RAM und Flash nicht einfach nach Lust und Laune ihren Inhalt > ändern. Je besser Deine Hardwaremaßnahmen sind, desto seltener passiert etwas. Aber gegen Höhenstrahlung (sie lässt etwa alle zwei Wochen ein Bit in Deinem PC kippen) oder gegen extrem starke Störquellen (z.B. Flughafenradar, defekte Bremswiderstände an FUs, Funkenüberschläge in µC-Nähe) hast Du keine Chancen. Die Effekte sind umso deutlicher, je größer Deine Serie ist oder je sicherer Deine Applikation arbeiten muss, weil z.B. mit einer Fehlfunktion ein großer Schaden verbunden sein kann. Dann kann es schon etwas bringen, die Empfindlichkeit Deiner Schaltung mit recht geringem Aufwand um 50...95% zu verringern.
Ungar schrieb: > Funkenüberschläge in > µC-Nähe) hast Du keine Chancen. Mit Überschlägen habe ich schon reichlich Erfahrungen gemacht. Z.B. setze ich die AVRs in Stromversorgungen für Röntgenquellen (15kV, 1kW) ein. Im Vakuum kann es da gerne mal zu Überschlägen kommen. Ich setze da auf Schutzbeschaltung der IO-Pins, der VCC und auf überlegte Masseführung. Vorherige Stromversorgungen waren ohne MCs aufgebaut, die sind schnell mal ausgestiegen und mußten auch oft repariert werden. Mit den AVRs hat sich dann die Zuverlässigkeit deutlich erhöht. Bei Überschlägen erfolgt nun ein automatischer Wiederanlauf und erst ab einer bestimmten Überschlagsrate eine Abschaltung. Eine direkte ESD-Befeuerung des MCs habe ich nicht geprüft und wird auch nicht beim EMV-Test geprüft. Unsere Geräte werden nur bei geschlossenem Gehäuse (Schroff) in Betrieb genommen, was bei 15kV/1kW auch angeraten ist. Beim EMV-Test erfolgt nur außen eine ESD-Test, der kann schonmal das LCD (Kaufteil) an der Frontplatte zum Absturz bringen. Daher wird das LCD in regelmäßigen Abständen neu initialisiert.
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.