Wie könnte man übliche Pin-Funktionen (IO, Pull-Ups, ADC, PWM) durch den selben Controller prüfen? Alle Pins miteinander verbinden, jeweils einen auf Ausgang (opt. Pull-R) schalten und mit den anderen messen? Die Ergebnisse im RAM ablegen und dann mit dem Debugger auslesen. Zweiter Fall: wäre so ein Selbsttest auch in "der" Schaltung möglich?
So ein Selbstest geht im Prinzip, aber ein Fehler der gleichzeitig beim der Ausgabe und der Eingabe auftritt wird übersehen. Info schrieb: > wäre so ein Selbsttest auch in "der" Schaltung möglich? Ich würde lieber die "das" Schaltung nehmen :-)
Wie du selbst schon gemerkt haben dürftest, brauchst du dazu eine Aussenbeschaltung. Das beißt sich aber damit, dass der µC ja auch was sinnvolles tun soll, d.h. es gibt eine Aussenbeschaltung die auch etwas 'vernünftiges' tut. Deine 'Test'-Schaltung muss sich also nur auf Bedarf zuschalten. Aber nur mal angenommen, du hättest so was: woher weißt du, dass ein eventueller Fehler dann auf tatsächlich fehlerhafte µC-Pins (oder allgmein auf Fehler im µC) zurückzuführen ist und nicht auf eine fehlerhafte Testschaltung? Du bräuchtest dann eine Testschaltung für die Testschaltung. Die natürlich ebenfalls fehlerhaft sein kann. ad infinitum. Das ganze lässt sich zusammenfassen mit: Wer prüft eigentlich die Prüfer? Conclusio: Lass es. Das lohnt nicht. Letzten Endes ist das Aufwand, von dem du so gut wie nichts hast. Irgendeine Annahme musst du treffen, die da lautet: der Teil funktioniert so wie er soll. Sichere lieber deine Aussenbeschaltung so ab, dass im Fehlerfall nichts schlimmes passiert.
:
Bearbeitet durch User
Info schrieb: > Wie könnte man übliche Pin-Funktionen (IO, Pull-Ups, ADC, PWM) durch den > selben Controller prüfen? Nen Kondensator an den Pin hängen und über Output auf- und entladen. Damit die anderen Funktionen prüfen > Die Ergebnisse im RAM ablegen und dann mit dem Debugger auslesen. oder Softserial > Zweiter Fall: wäre so ein Selbsttest auch in "der" Schaltung möglich? Ja, per Port dazuschalten, aber der Port muss dann ja dann auch getestet werden ;-).
>woher weißt du, dass ein eventueller Fehler dann auf tatsächlich >fehlerhafte µC-Pins (oder allgmein auf Fehler im µC) zurückzuführen ist >und nicht auf eine fehlerhafte Testschaltung? Du bräuchtest dann eine >Testschaltung für die Testschaltung. Die natürlich ebenfalls fehlerhaft >sein kann. ad infinitum. ganz einfach: erkennt man am ausschuß. oder wer überprüft den professor der die klausur überprüft?
Karl Heinz schrieb: > Du bräuchtest dann eine > Testschaltung für die Testschaltung. Das Argument ist nicht stichhaltig. Tritt kein Fehler auf, ist sowohl das System als auch die Testschaltung ok, wenn diese korrekt entworfen ist (Testabdeckung). Wenn nicht muss das Gerät überprüft werden, egal wo der Fehler liegt. Der Selbsttest bringt also sehr wohl einen Gewinn an Zuverlässigkeit. Gruss Reinhard
Wozu brauchst du das? Musst du eine bestimmte Zuverlässigkeit nachweisen? Eventuell ist eine diskrete Fail-Safe-Schaltung außenrum der bessere Weg?
Ich brauche das nicht zwingend, aber z.B. fliegen irgendwo in der Restekiste Controller rum, deren Status unbekannt ist. Der Aufwand, für jeden x-beliebigen Controller ein Testprogramm zu schreiben, ist natürlich indiskutabel(*), und zuverlässig ist ein defekter Controller dann auch nicht mehr. Aber 'drüber Nachdenken kann man ja mal. Ausserdem wäre es natürlich auch bei perfekt (?) geschützten Geräten eine tolle Debugging-Hilfe, um Fehlerursachen auszuschließen. Und bei der industriellen Gerätefertigung in Großserie werden sicher auch Testfunktionen genutzt https://de.wikipedia.org/wiki/JTAG https://de.wikipedia.org/wiki/Boundary_Scan_Test https://de.wikipedia.org/wiki/In-Circuit-Test (*) Evtl. könnte man aber aus Headerdaten bzw. sonstigen Device-Infos solche Testprogramme generieren?
Info schrieb: > Und bei der industriellen Gerätefertigung in Großserie werden sicher > auch Testfunktionen genutzt Das sind Tests mit externen Geräten. Es ist aber auch immer sinnvoll, einen Power On Self Test (POST) durchzuführen, soweit das mit vernünftigen Mitteln möglich ist - ich prüfe z.B. immer das RAM durch, meistens erzeugt man auch eine Prüfsumme des Programms, ob es noch korrekt ist, das geht ja recht einfach. Nicht undumm ist auch die Überprüfung von Versorgungsspannungen, oder ob sich Lüfter drehen, wie das ja im PC üblich ist. Hat man ADC-Eingänge übrig. kann man auch den ADC testen, usw. usw. Zusätzlich kann man auch Manufacturing Tests einbauen, die nur bei Inbetriebnahme aufgerufen werden (oder im Fehlerfall vom Service), die können auch etwas Zusatzhardware erfordern. Ich habe z.B. Kurzschlussstecker erstellt, mit denen sich die seriellen und parallelen Schnittstellen per eingebauter Software testen lassen. Gruss Reinhard
Da stimme ich voll zu. Einfache Selbstests nach dem Einschalten würde ich immer dann machen, wenn es wichtig ist Fehler frühzeitig zu erkennen und eventuell bereits das Ergebnis des Selbsttests anzuzeigen. Für Speicher sind immer Prüfsummen sinnvoll(Quersumme und Adressensummierung), die CPU schieben und rechnen lassen, sowie die I/O-Port durch Ausgabe und zurücklesen, im Wechsel mit "Low" und "High". Allerdings sollte die externe Pheripherie dies abkönnen. In der externen Schaltung kann man auch einfache Testmöglichkeiten vorsehen um offene Leitungen oder Kurzschlüssen zu erkennen(wie z.B. hier beschrieben: http://www.ichaus.de/upload/pdf/EInfo_H6_2005_EA_Fehlerueberwachung_in_industriellen_Maschinensteuerungen.pdf )
kopfkratz Eine "ultimative" externe Testschaltung ist genauso unmöglich wie "42" zu "bestimmen" ... Wenn Du unterschiedliche Controller hast und feststellen willst was davon noch OK ist mußt Du immer die jeweiligen Besonderheiten berücksichtigen. Ein PIC XYZ hat andere Eigenschaften als ein AVR XYZ oder ein STM XYZ oder oder ... Egal ob Du nun via "Testbeschaltung" die Funktion überprüfen willst oder direkt in der endgültigen Schaltung mußt Du für jeden einzelnen µC ein zum Typ passendes Testprogramm schreiben. In der FAB werden die DIEs einem Prüfmarathon ausgesetzt, der ist aber wieder für jeden einzelnen Typ individuell ... Wenn der Käfer unter 10,- Teuronen liegt dürfte ein Neukauf sinnvoller sein als sich tagelang mit Testschaltung und dazu passender Programmierung herumzuärgern !
Was mich interessieren würde: Wenn man beim AVR einen Pin als Output schaltet (per DDR-Register), bekommt man dann, wenn man anschließend PINx liest als Ergebnis den Soll- oder weiterhin den Istwert?
Angehängte Dateien:
-
attiny.png
60 KB
magic smoke schrieb: > Was mich interessieren würde: > Wenn man beim AVR einen Pin als Output schaltet (per DDR-Register), > bekommt man dann, wenn man anschließend PINx liest als Ergebnis den > Soll- oder weiterhin den Istwert? Ich würde bei jeden Controller davon ausgehen, dass man den Istwert erhält. Im Anhang ein Beispiel von einem ATtiny-Datenblatt. Dort ist es auf jeden Fall so. Man könnte offene Pins ermitteln indem man den Pin bei externen Pull-Down auf High schaltet und danach wieder Low zurück misst. Bei externen Pull-Up entsprechend anders rum. D.h. wenn die Schaltung es her gibt. Pins die offen sein müssen (z.B. wenn direkt ein FET-Gate ohne Pull-Widerstände angeschlossen ist) kann man auf High schalten, danach High zurück messen und dann nochmal auf Low schalten und Low zurück messen. Das Rückmessen erfolgt dann über die Pin-Kapazität und die Kapazität von den sonstigen am Pin angeschlossenen Bauteilen (z.B. das FET-Gate).
Naja, wenn das so ist kann man damit schon so eine kleine Selbstdiagnose durchführen. Wenn PORTn!=PINn -> Problem!
> durchführen. Wenn PORTn!=PINn -> Problem!
Dabei muss man je nach MCU aber berücksichtigen, dass es einen oder
mehrere Zyklen Verzögerung zwischen dem Setzen des Registers und dem
elektrischen Flankenwechsel geben kann.
Karl Heinz schrieb: >> Du bräuchtest dann eine Testschaltung für die Testschaltung. Reinhard Kern schrieb: > Das Argument ist nicht stichhaltig. Tritt kein Fehler auf, ist sowohl > das System als auch die Testschaltung ok, wenn diese korrekt entworfen > ist (Testabdeckung). "Tritt kein Fehler auf" ist aber keineswegs eine objektive, unanzweifelbare Tatsache, denn auch diese Schlussfolgerung kann (genau wie das Erkennen eines Fehlers) sehr wohl auf einem Fehler beruhen. Soft- oder Hardwarefehler können ja durch andere Soft- oder Hardwarefehler verdeckt oder vorgetäuscht werden. Dabei spielt es auch keine Rolle, ob es sich um technische Systeme handelt oder um Menschen ("Die LED hat kurz geleuchtet" - Wirklich? Zu viel Kaffee getrunken, Drogen, bisher unerkannte Hirnerkrankung, ...?). Da hier ein logisches Problem vorliegt, nicht nur ein technisches, kann man diese Möglichkeit - zumindest in unserem Universum - unmöglich ausschließen. Man kann lediglich die Wahrscheinlichkeit von "False Positives" und "False Negatives" verringern, z.B. durch mehrfache Tests, Testvariationen etc. > Der Selbsttest bringt also sehr wohl einen Gewinn an Zuverlässigkeit. Ja. Wobei du dir hier in gewisser Weise selbst widerspricht ("ist ok" = ist fehlerfrei; "Gewinn an Zuverlässigkeit" = geringere Wahrscheinlichkeit eines Fehlers). Ich bin durchaus deiner Meinung und als Softwareentwickler haben Tests für mich eine hohe Priorität, aber deine Aussage (erstes Zitat) ist etwas missverständlich.
Das ist genau wie mit den CRCs... Die garantieren dir auch keine 100%-ige Fehlerfreiheit, nur ist die Wahrscheinlichkeit sehr gering. Bei den Schutzschaltungen heißt es doch immer halbwegs pragmatisch: "...must prevent any single error condition and any probable combination of multiple error conditions to cause harmful effects..." Die meisten mehrfachen Fehlerbedingungen werden doch durch "engineering judgement" von vornherein als zu unwahrscheinlich ausgeschlossen, als dass man sie näher betrachten müsste.
:
Bearbeitet durch User
Oliver Döring schrieb: > Fehlerbedingungen werden doch durch "engineering > judgement" von vornherein als zu unwahrscheinlich ausgeschlossen z.Beispiel in Harrisburg, Tschernobyl und Fukushima. Da ist überall was passiert, was gänzlich ausgeschlossen war. Bei einer Aquarienheizung ist die Beurteilung wahrscheinlich nicht besser, bloss die Folgen sind weniger schlimm (ausser für die Fische). Gruss Reinhard
Blödsinn. Die Atomunfälle waren allesamt menschliches Versagen. Hätte beim TMI-Unfall niemand eingegegriffen, hätte sich die Anlage selbst gerettet, der Tschernobyl-Unfall war ein fehlgeschlagener Sicherheitstest bei gröbster Missachtung der Vorschriften und seit Fukushima ist hoffentlich niemand mehr so blöde, dermaßen wichtige Notstromgeneratoren an einer Tsunami-gefährdeten Küste in den unverbunkerten Keller zu stellen.
magic smoke schrieb: > und seit > Fukushima ist hoffentlich niemand mehr so blöde, dermaßen wichtige (OT) Deinen Optimismus teile ich nicht! $$$ und gesunder Menschenverstand schliessen sich aus.
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.