Hi, ich habe mal eine eher strukturelle Frage. Ich habe so eine billige Ampelsteuerung programmiert, die letztens Endes aber viel mehr Ausgangs- und Eingangsports bedienen soll. Allerdings möchte ich gesichert dafür sorgen, das das Gesamtsystem im Notfall in einen definierten Zustand übergeht. Nun habe ich mir gedacht, und das auch schon programmiert: Ich nutze jetzt einen IRQ, um in jedem Zustand zum Beispiel ein Notaus zu haben. Das finde ich wesentlich effektiver, als nur einen Eingabeport zur Kontrolle abzufragen, was meint ihr? Nun aber der eigentliche Punkt, das ist gerade noch Zukunftsmusik, aber das ist mein übernächstes Ziel: Automaten, verteilt über mehrere Controller. Ich versuche mich bissi in I2C einzufuchzen. Nehmen wir einen "einfachen" Fall: Controller 1 hat seinen Automaten bis zum Endzustand durchlaufen, er übergibt diesen Zustand an den nächsten Controller 2. Habt ihr einen Tipp, was ich mir hierzu durchlesen sollte, wie ich das strukturell aufbaue? Nun aber mal eine ganz technische Frage, denn als Theoretiker bekomme ich die Programmierung irgendwie hin... ich schiebe ja gerade meinen Code simplest über die ISP-Schnittstelle auf mein Pollinboard, fein... aber wenn ich nun zum Beispiel 2 AVRs habe, wie soll ich die Dinger dann programmieren? Ich kann ja kaum immer irgendwelche Boards umstöpseln? Und dann debuggen? Null Ahnung, danke für ein bisschen Tipps zur Zukunftsmusik! LG Jens
J. W. schrieb: > Ich > nutze jetzt einen IRQ, um in jedem Zustand zum Beispiel ein Notaus zu > haben. Das finde ich wesentlich effektiver, als nur einen Eingabeport > zur Kontrolle abzufragen, was meint ihr? schau dir mal den watchdog an > Code simplest über die ISP-Schnittstelle auf mein Pollinboard, fein... > aber wenn ich nun zum Beispiel 2 AVRs habe, wie soll ich die Dinger dann > programmieren? > Ich kann ja kaum immer irgendwelche Boards umstöpseln? Und dann > debuggen? Null Ahnung, danke für ein bisschen Tipps zur Zukunftsmusik! ein paar stichworte: bussystem, bootloader, modellbasierte-softwareentwicklung, matlab, simulink, matlab-embedded coder
J. W. schrieb: > Ich > nutze jetzt einen IRQ, um in jedem Zustand zum Beispiel ein Notaus zu > haben. Das finde ich wesentlich effektiver, als nur einen Eingabeport > zur Kontrolle abzufragen, was meint ihr? Wenn Du hier schon etwas länger mitliest, sollte Dir die Antwort klar sein. Solche Fragen erscheinen im Schnitt täglich (gefühlt micro-sekündlich). Eine Ampel muß nicht innerhalb 1µs umschalten, das sieht kein Mensch. Entprellen+Störunterdrückung ist dagegen immer sehr nützlich.
J. W. schrieb: > Nehmen wir einen "einfachen" Fall: Controller 1 hat seinen Automaten bis > zum Endzustand durchlaufen, er übergibt diesen Zustand an den nächsten > Controller 2. Aufgaben, die spielend ein MC erledigen kann, auf mehrere MCs aufzuteilen, ist niemals "einfach". Um den erheblichen Software-Mehraufwand zu rechtfertigen, muß es schon gewichtige Gründe geben. Z.B. daß die MCs voneinander weit entfernt sind und daher möglichst wenige Leitungen oder Funk verwendet werden sollen.
@ J. W. (ontheway) >sorgen, das das Gesamtsystem im Notfall in einen definierten Zustand >übergeht. Dann nutze für diese Überwachung möglichst wenig bis keine Software sondern einfache, robuste, zuverlässige Hardware. Ein Watchdog ist ein einfacher Ansatz, aber bei weitem nicht alles. >Nun habe ich mir gedacht, und das auch schon programmiert: Ich >nutze jetzt einen IRQ, um in jedem Zustand zum Beispiel ein Notaus zu >haben. Das finde ich wesentlich effektiver, als nur einen Eingabeport >zur Kontrolle abzufragen, was meint ihr? Das ist ein Irrtum. Eine normale statemachine läuft so oder so mit festem Zeitraster. Und ehe du einem Mikrocontroller mit einer komplexen Steuerung einer Ampel oder auch deutlich größeren Anlage auslastest, muss du schon EXTREM viel machen. Sicherheitskritische Sachen macht man anders. Aber das ist eine kleine Wissenschaft für sich. Redundanz, Diversität, Failsafe, um mal ein paar Stichworte zu nennen. >Nun aber der eigentliche Punkt, das ist gerade noch Zukunftsmusik, aber >das ist mein übernächstes Ziel: Automaten, verteilt über mehrere >Controller. Mach erstmal einen AUtomaten auf EINEM Controller WIRKLICH gut und wasserdicht. Dann sehen wir weiter. >Nun aber mal eine ganz technische Frage, denn als Theoretiker bekomme >ich die Programmierung irgendwie hin... Theoretisch ;-) >aber wenn ich nun zum Beispiel 2 AVRs habe, wie soll ich die Dinger dann >programmieren? Umstecken? Probleme eines Theoretikers . . . >Ich kann ja kaum immer irgendwelche Boards umstöpseln? Warum nicht? Oder einfach einen 2. COM/USB Port nutzen. Und du willst verteilte Automaten entwerfen? > Und dann >debuggen? Null Ahnung, danke für ein bisschen Tipps zur Zukunftsmusik! Siehe Fehlersuche
Andi D. schrieb: > J. W. schrieb: > schau dir mal den watchdog an Okay, verstehe ich nicht. Was nutzt mir der Watchdog als Eingabeport? Das geht doch garnicht? Der ist doch noch ein "Reset-Timer" oder so? > > ein paar stichworte: > bussystem, bootloader, modellbasierte-softwareentwicklung, matlab, > simulink, matlab-embedded coder Was nutzt mir Matlab, wenn ich auf der Hardwareebene mehrere Controller verstöpsel? So wie es ausschaut, produziert mir das zig IFs und ELSES und SWITCHES, die ich dann nicht mehr verstehe... ich möchte mich nicht so abhängig machen, zumindest am Anfang nicht... und ich wüsste nicht, wie mir Matlab hilft, wenn ich die Dinger auf Hardwareebene beschreiben möchte?! Aber ich bin da ja noch Anfänger, sorry.
@J. W. (ontheway) >Okay, verstehe ich nicht. Was nutzt mir der Watchdog als Eingabeport? >Das geht doch garnicht? Der ist doch noch ein "Reset-Timer" oder so? Ja. Der Watchdog macht einen Reset, wenn deine Software sich nicht mehr innerhalb einer bestimmten Zeit definiert meldet, sprich, den Watchdog periodisch zurücksetzt. Aber ein Watchdog ist kein Allheilmittel und er allein stellt auch keinen sicheren Zustand her. Er ist nur ein billiger Rettungsanker.
Falk Brunner schrieb: > Ein Watchdog ist ein > einfacher Ansatz, aber bei weitem nicht alles. Er ist vor allem völlig untauglich gegen konzeptionelle Fehler oder fehlerhafte Programmablaufplanung. Für ne Spielzeugampel braucht man keinen Watchdog.
Falk Brunner schrieb: > @J. W. (ontheway) > > Aber ein Watchdog ist kein Allheilmittel und er > allein stellt auch keinen sicheren Zustand her. Er ist nur ein billiger > Rettungsanker. Genau Falk, das meinte ich. Mir geht es doch auch garnicht um eine Spielzeugampel, ich möchte verstehen, wie ich komplexe Automaten baue und wie ich dann noch diese Koppel. Das empfinde ich als hochgradig anspruchsvoll. Mangels Erfahrung.
Peter Dannegger schrieb: > Aufgaben, die spielend ein MC erledigen kann, auf mehrere MCs > aufzuteilen, ist niemals "einfach". > Um den erheblichen Software-Mehraufwand zu rechtfertigen, muß es schon > gewichtige Gründe geben. Ganz wichtig zu beachten. Und zum "Automatenentwurf": solange das Automatenmodell noch sinnvoll ist (im Sinne man kann überblicken was da abgeht und hat nicht nur irgendwas aus einer anderen Beschreibung generiertes) kannst du einfach immer eine größere CPU nehmen wenns knapp wird... Verteilen auf mehrere Systeme bringt da nix. Und wenn nimmt man da kommunizierende Automaten und nicht einen verteilten. (Wie immer: es gibt Spezialfälle und Ausnahmen, auf erheblich höheren Ebenen oder für theoretische Betrachtungen kann das schonmal vorkommen. Aber da redet keiner über uCs)
J. W. schrieb: > ich möchte verstehen, wie ich komplexe Automaten baue > und wie ich dann noch diese Koppel. Das empfinde ich als hochgradig > anspruchsvoll. Mangels Erfahrung. Teile und herrsche: Alles, was komplex ist, läßt sich in einfachere Teile herunterbrechen. Ein komplexer Automat läßt sich in mehrere einfache Automaten teilen. Das strukturierte Aufteilen und das klare Kapseln dieser Teilen ist das A&O einer systematischen Softwareentwicklung. Beispiel:
1 | main() |
2 | {
|
3 | switch(Tageszeit) |
4 | {
|
5 | case MORGENS: |
6 | // Hier einen Subautomaten für Morgens abarbeiten
|
7 | Morgens_Automat(); break; |
8 | case MITTAGS: |
9 | ...
|
10 | }
|
11 | }
|
12 | |
13 | void Morgens_Automat(void) |
14 | {
|
15 | switch(Ablauf) |
16 | {
|
17 | case AUFSTEHEN: |
18 | Aufstehen_Automat(); break; |
19 | case RASIEREN: |
20 | Rasieren_Automat(); break; |
21 | case ZÄHNEPUTZEN: |
22 | ...
|
23 | }
|
24 | }
|
Am besten erst mal überlegen bzw. definieren wie der gefahrlose bzw sicher Zustand aussieht und wie er (durch konstruktion mechanisch, elektrisch ereicht werden kann, wenn z.B. der Strom ausfällt) erreicht werden kann (eigensicher wäre auch ein Begriff den du mal Gugeln kannst). Für nen Geldschrak wärs doof wenn die Tür bei Stromausfall aufgeht, fürn nen Kaufhaus sollte sie schon aufgehen, bei ner City toliette kann man sich streiten.
Wachhund vs. Interrupt Ein Wachhund hilft nur gegen Blockaden (Endlosschleifen oder Funktionen die ewig Zeit verbrauchen). In einem sicherheitsrelevanten System hilft Dir das nur Beschränkt weil ein Reset meist die schlimmste Lösung ist und das Feststellen, ob Kollege Zufall oder Kollege Kaputt der Verursacher ist... Unterbrechungen kommen auch nicht immer an z.B. weil eine amoklaufende Sequenz ihn desaktiviert haben kann. Auch ist die Unterbrechung auch nur ein Signal, welches dann nach seiner Ursache untersucht werden muss. Siehe vorher. Unter dem Strich kommst Du nicht darum herum jeweils alles im Auge zu behalten. Dann fängt aber die Frage nach dem Sinn eines Wachhundes oder der Unterbrechung an.
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.