uC-Programmierung: Endlosschleifen befürchten?

Hans-Georg Lehnard schrieb:

Hatte ich auch mal: Beim Wechsel vom 5 zum 4 Gang und dementsprechend Auskuppeln ging der Motor auf 7000 U/min und nach ca. 1s (zum Glück!) auf

2. Danach lief das ganze seltsamerweise wieder, der Fehler hat sich dann aber innerhalb der nächsten 14 Tage doch nochmal wiederholt, so dass ich da lieber zur Werkstatt gefahren bin. Ergebnis: Poti vorne an der Einspritzpumpe kaputt, hatte in der Nähe der Vollgasstellung ziemlichen Kontaktabbrand, und hat sich dort dann verschweißt, inklusive des Gaszuges.

Sollte deine Tochter vielleicht auch mal nachgucken lassen.

(Unverschämt fand ich aber den Preis dieses offensichtlich falsch dimensionierten Bauteils: 30 Euro *ohne* Einbau!)

Achja, und bevor mich jemand als hemmungslosen Raser bezichtigt: Ich fahr 'nen Opel mit läppischen 75PS. Ich brauche manchmal Vollgas, sonst zischen die 40tonner nur so an mir vorbei...

Mit freundlichem Gruß

Jan

Außer, der Teil des Chips ist durch EMV oder sonstwas in einen undefinierten Zustand geraten.

Ich denke, es kommt sehr auf die Applikation an, ob man das abfangen will/muß oder nicht. Bei unkritischen Anwendungen würde ich den hängenden UART dem Watchdog überlassen - bei externer Peripherie, gerade bei I2C, sollte IMHO aber passende Fehlerbehandlung rein.

Es kommt auch noch darauf an, was man in dem Fall, daß man den Fehler erkannt hat, machen kann: wenn der UART essentiell für die Funktion des Gerätes ist, kann man versuchen, den neu zu initialisieren - mit etwas Pech braucht der aber eh einen Reset, um sich zu berappeln, dann kann man das auch gleich dem Watchdog überlassen, wenn dadurch kein sonstiger Schaden entsteht.

cu Michael

Jan Kandziora schrieb:

Hallo Jan,

das Auto war neu und kam direkt anchließend in's Smart-Center. Angeblich ist Wasser durch die Heckklappe eingedrungen und nach vorne gelaufen vorne wieder hoch und in die Elektronik .. wer's glaubt. Ist aber bis jetzt nicht wieder aufgetreten.

Ich fahre einen alten VW-Bus ohne Elektronik und OBD. Da kann man keinen Laptop anschliessen, der einem sagt wo der Fehler ist. Und das überfordert eine heutige moderne Werkstatt ;-)

Gruß

Hans-Georg

Stell dir vor, deine Brandmeldeanlage bleibt bei einem Fehler einfach hängen ohne die Störung zu melden.

Das ist Quatsch, i der realen Welt kann eine Steuerung nicht einfach klammheimlich hängen bleiben.

Da kommt doch bestimmt der clevere Programmierer auf die Idee einen Timer zu starten und mit dem Timerinterrupt den Watchdog zurücksetzen. Hatten wir alles schon ;-) Da kann das Hauptprogramm hängen bleiben wie es will.

Die meisten Fehler sind keine Hardwareausfälle, sondern "Runtime Errors" und einen Rechenfehler muss nicht unbedingt zum Ansprechen des Watchdog führen. Siehe Ariane 5.

Gruß Hans-Georg

Hans-Georg Lehnard schrieb:

Eine Brandmeldeanlage, die immer wieder mal gestört ist, ohne dass man es merkt, ist auch nicht sehr viel besser.

Meine Rede war "Watchdog", nicht "hängen bleiben lassen". Und wenn ein Watchdog im laufenden Betrieb auslöst, kann das ein Controller durchaus separat bearbeiten (Fehlermeldung, Neuanmeldung, oder einfach neuer Versuch), aber in einer wirklich sicherheitsrelevanten Anwendung sollte so etwas einen Hardware-Not-Aus auslösen und menschliche Beurteilung anfordern. Wie schon gesagt - bekannte und vorhersagbare Probleme kann man per Software abfangen, aber nach unvorhergesehenen Störungen kann man IMHO nicht einfach davon ausgehen, dass der Controller insgesamt in einem definierten Zustand ist. Vor allem sollte man nie einfach weitermurksen, sondern die ursächlichen Probleme lösen, also die Störungen beseitigen, statt sie zu tolerieren.

ja, aber inwiefern vertraust du einem µC noch, bei dem manche internen module nicht mehr nach spec funktionieren? vielleicht wird ja die ADC-konvertierung nicht fertig, weil die timer-mimik schon was abbekommen hat, wodurch auch die PWM nicht mehr sauber rennt, was du aber nicht wirklich mitbekommst, bis es kracht.

außerdem hat der OP IMHO das pferd von der falschen seite her aufgezäumt: ob und wie ich den fehler µC-seitig behandle, darüber denk ich erst nach, wenn ich festgestellt habe, daß ich ihn dort überhaupt behandeln will -- und das kommt ganz auf die anwendung an, kann ja sein, daß eine temperatursicherung, die die versorgungsspannung kappt, die angemessene (und billige) lösung ist, oder ich hab eh 3 verschiedene µC-systeme und eine entscheidungslogik dahinter, dann verwend ich den WDT und stell mich nach watch dog reset tot und laß die anderen weitermachen...

(soweit jedenfalls meine theoretischen überlegungen, mein einziges µC-projekt, in dem fehler wirklichen schaden verursachen könnten, ist ein raumthermostat, und in dem gibt's [noch] keine fehler und keine fehlerbehandlung).

ciao,

cm.

Wie wäre es denn konzeptionell mit:

while (1) { if (Peripherie_1_fertig) { Behandle_neue_Daten(1); Aendere_Zustand(1); } if (Peripherie_2_fertig) { Behandle_neue_Daten(2); Aendere_Zustand(2); } if (sonstnixzutun) { Rechne_jetzt_denn_du_hast_Zeit(); } ... }

Nur mal so als Tipp, die Warterei auf _ein_ Device macht embedded Systeme ziemlich langsam, besser ist es, die CPU zwischendurch anderweitig zu beschäftigen.

Und dann kannst Du immer noch festlegen, was passiert, wenn über irgendeine Schnittstelle keine Daten kommen oder gehen wollen und deshalb ein Puffer leer oder vollläuft.

Vorallem: Dann hängt das System nicht, sondern der Teil, der davon unabhängig ist, funktioniert weiter.

Gruß Oliver

Thomas Rachelschrieb: "

Naja die Beispielprogramme sollen sicher nur als Anhaltspunkt dienen. Programmieren würde ich so nicht und auch eine Spec. kann mal falsch (verstanden) sein. Solche while-Schleifen mögen für simpelste Programme noch akzeptabel sein, inzwischen hat man aber herausgefunden, das ein Event-orientierter Ansatz meist der bessere ist. Die Einen machen es, weil mehrere ext. und interne Events unverhersehbar auftreten können, die Anderen weil sie den Controller während des "Leerlaufs" in Standby schicken. Solche while-Schleifen widersprechen dem Echtzeitgedanken, weil Du nicht vorhersagen kannst, wann spätestens die anderen Programmteile wieder abgearbeitet werden können. Wie schon erwähnt funktioniert das nur bei simpelsten Progammen und wird dazu führen, dass Du dieses Konzept wegwerfen mußt, sobald Du irgendwas ändern willst, oder eine neue Anforderung hinzugefügt werden soll. Tips:

- Schau Dir doch mal die Beispiele zur Interrupt-Verarbeitung an.

- Baue dir eine Art HAL (Hardware-Abstraction-Layer) zusammen, den Du immer wieder auf diesen oder ähnlichen Controllern verwenden kannst.

- Entwickle Dir Mailboxen und Semaphoren um auf einem höheren Abstraktionslevel Deine Software zu entwickeln

- Schau Die mal Treiber auf anderen Systemen an, Da gibt es immer Funktionen wie Init, Open, Read, Write, Close. Versuche sowas zu implementieren und Deinen Code zu kapseln (am besten in einer Library).

MfG Dirk

Hallo Edzard,

du redest von Controllern und ich von Systemen. Der Watchdog ist doch nur eine Notlösung, weil man sich über Fehlerbehandlung nicht so gerne Gedanken macht. Und genau weil der Zustand des Systems nach dem Zuschlagen des Watchdog nicht mehr eindeutig ist, kann der MC nicht mehr viel machen. Menschen sind zum Entscheiden nicht immer verfügbar oder zu langsam. Der Hauptprozessor der Ariane 5 hat die Selbstzerstörung ausgelöst, weil die redundanten Antriebs-Controller gesagen haben, Houston wir haben ein Problem. Ok, das war jetzt kein hängenbleiben sondern ein Überlauf. Da wurde richtigerweise nicht im Kontrollzentrum nachgefragt und der Spass hat ein paar Euronen gekostet.

Ich habe viel mit medizinischen Geräten und den dazugehörigen Prüfsystemen zu tun. Es darf unter keinen Umständen ein fehlerhafter Prüfling in die freie Wildbahn geraten, sonst steht im Schadensfall in .de der Staatsanwalt oder bei Export Geräten die FDA vor der Tür und macht den Laden dicht.

So ein Prüfling darf so defekt sein und sich benehmen wie er will und die Bediener sind Anlernkräfte. Weiterhin befinden sich mehrere Prüflinge gleichzeitig im Test.

Welchen Menschen soll ich da bitte fragen ?

Was soll ich da mit einem Watchdog ? Die Produktion haut mir auf die Finger, wenn ich ein alle Prüflinge für fehlerhaft erkläre weil sich einer davon nicht gemeldet hat.

Fazit: und darauf können wir uns bestimmt einigen ;-)

Für Hobbyanwendungen kann jeder machen was er will. Für Leute, die was lernen wollen und Berufsanfänger ist dies ein wunderbares Forum um mal über den Tellerrand zu schauen.

Es gibt keinen Königsweg.

Und man sollte immer nach Lösungen für Probleme und nicht nach Problemen für fertige Lösungen suchen.

Gruß

Hans-Georg

Oliver Bartels schrieb:

Hallo Oliver,

du hast vollkommen recht, unnötig Zeit vertrödeln und dann über die ineffektivität von C++ schimpfen das hab ich gerne ;-))

Behandle_neue_Daten() ist aber etwas vereinfacht .. Der Aufruf macht evtl. keinen Sinn mehr, weil zu spät oder die Daten sind schon überschrieben, weil zu spät abgeholt.

Gruß

Hans-Georg

Ich vertraue ihm nicht mehr. Aber es ist besser, mit etwas Muffensausen noch aufs trockene zu kommen als gleich alles nach dem Motto "Ist eh alles verloren" explodieren zu lassen.

In Med, Aero und anderen Bereichen geht das Top Down. Vor der Hazard Analysis faengt man das Design gar nicht an.

Na denn, druecken wir alle die Daumen ;-)

Koennte er schon. Z.B. koennte der WD-Haendler versuchen herauszufinden, was alles noch funktioniert. Oder an einen alternativen Prozess uebergeben. Oder das beste draus machen, nach dem Motto "Ok, den ADC und Timer A hat's wohl zerschossen, aber kann ich nicht ueber eine Variation der Druckventils und die Reaktion der Druckschalter genug rausbekommen, um nach Hause zu humpeln?"

Das muss man automatisieren und nur den ins Reject-Koerbchen tun, der fehlerhaft ist. Batch Rejects kann man nur bei wirklicher Massenware machen.

In Medizin, Mil, Aero und solchen Gebieten muss man auch letzteres tun. Nennt sich bei uns Hazard Analysis und Failure Mode and Effects Analysis FMEA.

Thomas Rachel schrieb:

Vorsicht ist möglicherweise hierbei gegeben. Je nach (nicht) dranhängender Peripherie kann eine bestimmte I²C-Bus-Bedingung in der Tat schon mal nicht eintreten. Ist dann die Frage, wenn vom (Nicht-)Funktionieren eines einzelnen I²C-Geräts die gesamte Funktion deines Geräts ohnehin abhängt, ist das sicher egal, ansonsten willst du u. U. den Controller nicht verklemmen und wenigstens den Rest noch bedienen können (und sei's, um eine Fehlerausschrift über den verklemmten I²C zu bringen).

All deine anderen Beispiele dürften welche sein, die nur interne Geräte des Controllers betreffen. Das erinnert mich dann immer an:

Steinbach's Guideline for Systems Programming: Never test for an error condition you don't know how to handle.

(Quelle: fortune(6))

Falls dein Controller einen HCF-Befehl hat, könntest du natürlich diesen im Fehlerfall ausführen. ;-)

Joerg Wunsch schrieb: ...

Da fe lt ein ;-)

Das schreit geradezu nach "Murphy's response to Steinbach's Guideline": "Never expect that an impossible Error will not to happen".

"Das kann nicht passieren" ist bei kritischen Systemen eine gefährliche Spekulation.

Falk

Falk Willberg schrieb:

Dachte ich früher auch.

Nein, das fehlt nicht. Lass es dir nochmal auf der Zunge zergehen.

Wenn du weißt, wie du auf eine bestimmte Fehlerbedingung reagieren kannst und solltest, dann trifft sein Satz ja schon nicht mehr zu. Wenn du es nicht weißt -- nun, was hilft es dir dann, den Fehler erkannt zu haben? (Falls du jetzt antwortest: ,,geordneten Rückzug antreten'' -> du bist wieder beim ersten Teil, du weißt nämlich, wie du darauf reagieren solltest.)

Joerg Wunsch schrieb:

Schmeckt mir nicht...

Ok, ich ergänze um: "Du sollst _immer_ wissen, wie Du einen Fehler behandelst." Jedenfalls auf Systemen, bei denen ein unvorhersehbares Verhalten schädlich sein kann.

Wenn es nur darum geht, ob sich ein DVD-Player aufhängt, ist es egal. Spätestens wenn Menschenleben davon abhängen, eben nicht.

Wie immer: Es kommt darauf an.....

Falk P.S.: Dürfte ich davon ausgehen, daß die Umgebung fehlerfrei ist, könnte ich manches in 1/10 der Zeit fertig haben.

In Koelle daet ma dat su saje: Et is noch emma joot jejange.

Falk Willberg schrieb:

Ja, keine Frage für solche Systeme.

Eben. Und dann nützt dir der Fehlertest eben auch nix.

Hallo Thomas,

was spricht denn dagegen, das ganze nochmal sauber mit Interrupts zu programmieren? Die einzige Schleife ist dann die Endlosschleife im Hauptprogramm, die durch die einzelnen Interrupts unterbrochen wird. So wird auf jeden Fall verhindert, dass eine Komponente den gesamten Controller lahm legt.

Zusätzlich könntest Du noch einen Timer hinzufügen, der für jedes Peripherieelement einen Zähler erhöht. Die Zähler werden durch die entsprechenden Interrupts zurückgesetzt. Damit kannst Du prüfen, ob ein Peripherieelement ungewöhnlich lange hängt und ggf. eine Meldung absetzen. Währenddessen können die anderen Komponenten aber unbeeindruckt weiterlaufen.

Schöne Grüße, Björn