Guten Tag, Ich bin gerade dabei eine Ampel Steuerung zu planen, und Programieren, komme jedoch so langsam an meine grenzen mit dem gelernten aus der Schule. Meine Ampelsteuerung in den Phasen funktioniert. Jetzt habe ich jedoch eine Feuerwehr ausfahrt. Wenn die Feuerwehr ausrücken muss, sollen die anderen Ampeln auf Rot springen. Mein Problem ist jetzt, das ich nicht genau weiß wie ich einen Schalter permanent abfrage. Kenne bis jetzt nur die Möglichkeit über eine If-Abfrage zu gehen, aber da brauche ich ja zig If-Schleifen, was das ganze Programm mega unübersichtlich machen würde. Würde mich sehr über nen schlauen tipp freuen. mfg Markus
Hallo, das Stichwort heißt : Pinchange Interrupt oder externer Interrupt.
Schreiberling schrieb: > Hallo, > > das Stichwort heißt : Pinchange Interrupt oder externer Interrupt. Der Interrupt wird aber doch auch nur Abgefragt wenn ich es ins Programm schreibe, und nicht permanent oder vertuhe ich mich jetzt da?
Markus K. schrieb: > Der Interrupt wird aber doch auch nur Abgefragt wenn ich es ins Programm > schreibe, und nicht permanent oder vertuhe ich mich jetzt da? Da vertust du dich. Ein Interrupt ist wie eine Unterfunktion in deinem Programm. Stellst du nun die Pinchange Notification oder externer Interrupt an, springt dein uC in diesen Teil des Programms, sobald der Zustand am Pin sich wechselt. In dem Sinne kannst du einen Interrupt nicht "Abfragen", dieser Programmteil wird von alleine ausgeführt, sobald irgendetwas einen Interrupt auslöst. Ist dieser Programmteil vorbei, läuft das Programm dort weiter, wo es unterbrochen wurde. In der Art ein kleiner Boxenstop. Deswegen solltest du auch darauf achten, den Code in deiner Interruptfunktion möglichst kurz zu halten. Delay's usw. haben dort nichts zu suchen!
Markus K. schrieb: > If-Schleifen http://www.if-schleife.de/ Schreiberling schrieb: > das Stichwort heißt : Pinchange Interrupt oder externer Interrupt. Bei einem Schalter würde ich eher über das Timer Interrupt gehen, da ein mech. Schalter prellt, siehe Entprellung.
Markus K. schrieb: > Der Interrupt wird aber doch auch nur Abgefragt wenn ich es ins Programm > schreibe, und nicht permanent oder vertuhe ich mich jetzt da? Interrupts werden nicht abgefragt, sondern "passieren" einfach. Oder anders formuliert: sie werden – vereinfacht gesagt – mit jedem CPU-Takt des Mikrocontrollers "abgefragt". Hier ist das Thema gut beschrieben: AVR-Tutorial: Interrupts
Ich denke hier helfen keine Interrupts weiter. Eine Ampelsteuerung sollte man als State-Maschine umsetzen. Dann gibt es genau 1 Schleife und in dieser kann man per IF den Eingang Abfragen.
Peter II schrieb: > Ich denke hier helfen keine Interrupts weiter. > > Eine Ampelsteuerung sollte man als State-Maschine umsetzen. Dann gibt es > genau 1 Schleife und in dieser kann man per IF den Eingang Abfragen. Zu dem Thema, hier direkt ein Beispiel einer Ampelsteuerung: http://www.mikrocontroller.net/articles/Statemachine Halte ein Interrupt trotzdem für richtig. Gerade im Stadium des lernens kann es nicht schaden, sich einmal damit zu beschäftigen. Da sich der TO offensichtlich nicht damit auskennt, ist es auf jedenfall keine verschwendete Zeit, denn früher oder Später kommt er nicht drum herum. Ausserdem sind solche "Ampel-Programme" oft Aufgaben von der Schule/dem Lehrmeister. Diese Programme werden öfters behandelt und erweitert. Als ich vor 2 Jahrenim zweiten Lehrjahr war, mussten wir das selbe machen. Jedesmal wenn wir das Ziel der Aufgabe erreicht hatten, kam eine neue Erweiterung dazu. Zu beginn hatten wir auch alles mit State Machine gemacht, irgendwann mussten wir auch auf Interrupts wechseln weil die Applikation zu kompliziert wurde. Keine Ahnung wofür der TO es braucht, aber Interrupts sind hier nicht falsch. Falls es eine Schulaufgabe ist kommst du zudem schlau rüber, wenn du vielleicht sogar als einziger das ganze mit einem Interrupt löst. ;)
:
Bearbeitet durch User
Danke, ja hatte bei Interrupts im kopf, das sie auch immer nur am durch eine Abfrage gucken, ob ein Taster gedrück wurde oder nicht. Wie eben bei einem Fußgängerübergang ;) werde mir jetzt aber man die ganzen Ideen angucken, und gucken was ich machen kann :) Fakt ist, ich bin jetzt erstmal dabei einen Interrupt einzubauen.
Markus K. schrieb: > werde mir jetzt aber man die ganzen Ideen angucken, und gucken was ich > machen kann :) Fakt ist, ich bin jetzt erstmal dabei einen Interrupt > einzubauen. Immer wieder ulkig, wenn sich Anfaenger von Anfaengern beraten lassen. Dein Code ein Organisationsproblem, da hilft auch kein Interrupt. Am Ende musst du den Schalterzustand doch wieder in deiner Statemachine erfassen.
Quack+ schrieb: > Immer wieder ulkig, wenn sich Anfaenger von Anfaengern beraten lassen. > Dein Code ein Organisationsproblem, da hilft auch kein Interrupt. Am > Ende musst du den Schalterzustand doch wieder in deiner Statemachine > erfassen. Wieso sollte hier ein Interrupt keine abhilfe schaffen? Schalter wird gedrückt = Feuerwehr fährt los = Alle Ampeln Rot. Wo ist hier nun das Problem? Da Interrupt-On-Change auf steigende und fallende Flanke reagieren, könnte man also am Anfang des Interrupts den Ampelzustand speichern und sobald der Schalter zurückgestellt wird, diese wieder "laden." Auch wenn der Rest der Ampel in einer State Maschine Programmiert wäre, kann ein Interrupt immernoch eine abhilfe schaffen. Eine reine State-Maschine wäre auch eine Lösung, in dem Fall vielleicht sogar die bessere. Davon ausgehend dass er was lernen will, spielt es aber keine grosse Rolle.
:
Bearbeitet durch User
San Lue schrieb: > Wieso sollte hier ein Interrupt keine abhilfe schaffen? > > Schalter wird gedrückt = Feuerwehr fährt los = Alle Ampeln Rot. > > Wo ist hier nun das Problem? bis dahin gibt es noch kein Problem, aber wie geht es dann weiter? Schalter nicht mehr gedrückt, einfach dort weitermachen wo es aufgehört hat? - sehr dumme Idee.
Peter II schrieb: > Schalter nicht mehr gedrückt, einfach dort weitermachen wo es aufgehört > hat? - sehr dumme Idee. Kommt auf die Aufgabenstellung draufan. Verrate uns doch mal, wie du weitermachen würdest? :) Sehe das Problem nicht so da weiterzumachen, wo man aufgehört hat. Stelle mir das Feuerwehrauto genau gleich wie ein Interrupt vor. Es kann jederzeit kommen, sobald es vorbei ist soll alles ganz normal weiterlaufen. Wo ist da das Problem?
San Lue schrieb: > Kommt auf die Aufgabenstellung draufan. Verrate uns doch mal, wie du > weitermachen würdest? :) komplett in einer State-Maschine, wenn die IF-Bedingung erfüllt ist, wird ein einen besonderen Status gewechselt. Dann wird kontrolliert von state 1 neu begonnen. > Sehe das Problem nicht so da weiterzumachen, wo man aufgehört hat. > Stelle mir das Feuerwehrauto genau gleich wie ein Interrupt vor. Es kann > jederzeit kommen, sobald es vorbei ist soll alles ganz normal > weiterlaufen. Wo ist da das Problem? Das dann Ampeln unkontrolliert umschalten? Also einfach Von Rot auf Grün, und 1/2 sekunde später wieder auf Gelb, weil die zeit schon abgelaufen ist?
Ähh, es geht natürlich nach "alles rot" von da weiter. Also eine Richtung ordnungsgemäß auf grün schalten. Von "eine Richtung grün" ein Sprung auf "alles rot" ist schon blöde genug, das muss sauber in den Zustand geleitet werden. Und andersherum ist's natürlich genauso blöde. Wenn kurz vor "alles rot" gerade eine Richtung auf "gelb vor rot" war und hinterher wieder dahin springt...
Peter II schrieb: > Das dann Ampeln unkontrolliert umschalten? Also einfach Von Rot auf > Grün, und 1/2 sekunde später wieder auf Gelb, weil die zeit schon > abgelaufen ist? Okay, verstehe was du meinst. Falls die Ampel in einer State-Maschine Programmiert ist könnte man in der ISR auch einfach die state-Variable zurücksetzen auf den Beginn. Setzt natürlich voraus dass die State-Maschine so programmiert wurde, dass man davon ausging dass beim Start alle Ampeln auf Rot sind. So hätte er ene State-Maschine und einen Interrupt, grösserer Lerneffekt. Spielt ja nun keine Rolle mehr. Es handelt sich hierbei um eine theoretische Aufgabe und ich denke darüber zu diskutieren was denn nun die bessere Variante sei, ist sinnlos.
Also nochmal für das Verständnis einiger: Ich habe zwei Ampeln. Die Ampel-Phasen habe ich alle fertig. Wenn jetzt aber Ampel_1 auf Grün ist, und der Notschalter der FW umgelegt wird, muss die Ampel erst auf gelb dann auf Rot gehen. Ampel_2 ist hier ja schon auf Rot, daher kein Problem. und dann Blinkt eine andere Lampe. Das gleiche ist natürlich auch umgekehrt, wenn Ampel_2 grün ist, muss diese über Gelb nach Rot gehen. Wenn ich den Schalter also betätige, muss das Programm ersteinmal erkennen, welche Ampel gerade welchen zustand hat, und diese dann auf Rot fahren. Wenn der Taster zurück gelegt wird, kann das Programm von mir aus von vorne anfangen. mfg
Markus K. schrieb: > Also nochmal für das Verständnis einiger: > Ich habe zwei Ampeln. > Die Ampel-Phasen habe ich alle fertig. aber WIE ist die große Frage? Alles als code mit vielen Warteschleifen?
Ich denke, die Ampelsteuerung ist doch das Paradebeispiel für eine State Machine. Einfach und klar definiert. Und vor allem ohne delays und solche Unarten :-)
npn schrieb: > Ich denke, die Ampelsteuerung ist doch das Paradebeispiel für eine State > Machine. Einfach und klar definiert. Und vor allem ohne delays und > solche Unarten :-) Ein mindestens ein Delay bzw. einen Timer kommst du nicht herum.
Ich glaube der TO hat die Begründung gefunden, warum man die delay Funktion besser meidet.
Ich möchte dazu auch einwerfen, dass Interrupts und endliche Automaten sich keineswegs widersprechen. Das Eintreten eines Interrupts ist ja letztendlich auch nur ein möglicher Auslöser für einen Zustandsübergang, genau wie ein Timer.
San Lue schrieb: > npn schrieb: >> Ich denke, die Ampelsteuerung ist doch das Paradebeispiel für eine State >> Machine. Einfach und klar definiert. Und vor allem ohne delays und >> solche Unarten :-) > > Ein mindestens ein Delay bzw. einen Timer kommst du nicht herum. Nur einen Timer, der die state machine periodisch im gleichen Zeitraster aufruft, damit man auch definierte Zeiten bestimmen kann. Aber ein delay braucht man da nicht. Ich denke, du hast "entweder/oder" gemeint. Dann würde ich auf jeden Fall den Timer vorziehen.
npn schrieb: > Ich denke, du hast "entweder/oder" gemeint. Dann > würde ich auf jeden Fall den Timer vorziehen. Ja war so gemeint. "bzw." war wohl nicht der beste Ersatz für das Wort, aber immerhin hat man verstanden was ich meine. :P npn schrieb: > Dann würde ich auf jeden Fall den Timer vorziehen. Sollte man theoretisch sowiso in fast allen Fällen.
Gregor Ottmann schrieb: > Ich möchte dazu auch einwerfen, dass Interrupts und endliche > Automaten > sich keineswegs widersprechen. Das Eintreten eines Interrupts ist ja > letztendlich auch nur ein möglicher Auslöser für einen Zustandsübergang, > genau wie ein Timer. Richtig, genauso ist es. Wobei man für eine simple Tastenabfrage keinen Interrupt braucht, wenn das Zeitraster klein genug ist, z.B. 10ms. Wenn es allerdings um Ereignisse geht, die auch kürzer sein können, dann könnte man mit einem PinChange arbeiten und das Ereignis für die state machine speichern, bis wieder ein Zyklus dran ist.
Peter II schrieb: > Markus K. schrieb: >> Also nochmal für das Verständnis einiger: >> Ich habe zwei Ampeln. >> Die Ampel-Phasen habe ich alle fertig. > > aber WIE ist die große Frage? > > Alles als code mit vielen Warteschleifen? Ja, alles in einem Code, das ist ja mein großes problem: A1=rot 10 sek A1=gelb 5sek A1=grün 30sek . . . immer so weiter. deswegen kann dazwischen auch never nen Interrupt eingreifen :( versuche gerade alles etwas aufzuteilen
Markus K. schrieb: > immer so weiter. deswegen kann dazwischen auch never nen Interrupt > eingreifen :( Ein Interrupt kann jederzeit eingreiffen. Ich glaube, du solltest erst noch einmal lesen gehen was ein Interrupt ist.
Markus K. schrieb: > immer so weiter. deswegen kann dazwischen auch never nen Interrupt > eingreifen :( Dann hast du nicht verstanden, was ein Interrupt ist... Vielleicht hilft dir das: http://www.sprut.de/electronic/pic/int/int.gif
Markus K. schrieb: > Ja, alles in einem Code, das ist ja mein großes problem: > A1=rot 10 sek > A1=gelb 5sek > A1=grün 30sek > . > . > . > > immer so weiter. deswegen kann dazwischen auch never nen Interrupt > eingreifen :( doch kann er, aber so wird das nichts werden. lösche alles, und sieh es als Lernlektion an. den 2. Versuchst machst du wie hier beschrieben http://www.mikrocontroller.net/articles/Statemachine
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.