mit Arduino API Funktionen (millis, delay) geht das doch wirklich noch 1000mal einfacher....!
Druckbare Version
mit Arduino API Funktionen (millis, delay) geht das doch wirklich noch 1000mal einfacher....!
Wenn man kein retriggerbares Monoflop braucht, geht natürlich auch delay().
Sobald der Trigger ausgelöst ist, wird das stur abgearbeitet.Code:// Digispark Mini, ATtiny85, USB
// Test 1 - Feste Zeiten mit Delay
void setup() {
pinMode(0, INPUT);
pinMode(1, OUTPUT);
}
void loop() {
int trigger = digitalRead(0);
if (trigger <> 0)
{
digitalWrite(1, HIGH);
delay(1000); //1 Sekunde an
digitalWrite(1, LOW);
delay(10000); //10 Sekunden aus
digitalWrite(1, HIGH);
delay(1000); //1 Sekunde an
digitalWrite(1, LOW);
}
}
Ob währenddessen ein zweiter Trigger kommt, der den Zyklus verlängern soll, wird nicht registriert.
Bei Retriggerbarkeit, wird der erste 1 Sekunden Puls erzeugt, wenn während oder nach dem Impuls ein neuer Trigger kommt wird die Zeit für das Monoflop zurückgesetzt und die Gesammtzeit ist dann die schon verstrichene Zeit plus die Zeit auf die der Timer eingestellt ist. Wie bei einem Treppenhauslicht kann man damit die Zeit bis zum zweiten 1 Sekunden Puls beliebig verlängern, wenn mann innerhalb der Zeit immer wieder neu triggert.
Es kommt halt auf die exakte Aufgabenstellung an, was man benötigt.
genau, zum Retriggern verwendet man nicht delay sondern stoppt/überwacht millis() in einer eigenen while() loop:
zum Retriggern wird einfach vorher die Systemzeit millis gestoppt,
dann wird ein Zielwert der gestoppten Zeit + 10000 milli-sek (oder was auch immer) zwischengespeichert.
In der while-Schleife wird dann solange geloopt, bis millis den Zielwert erreicht oder überschritten hat.
In der Loop wird parallel weiterhin trigger=digitalRead(0) abgefragt, und wenn ein Tastendruck erfolgt ist, wird erneut der Zielwert um 10000milli-sek erhöht.
Die Version mit delay sieht doch recht überschaubar aus. Wenns damit erst mal klappt, kann man doch weiter experimentieren.
Ganz so einfach ist das nicht.
Der erste 1 Sekunden Puls soll ja nur einmal ausgeführt werden und darf sich auch nicht verlängern.
Und der zweite 1 Sekunden Puls soll auch nur einmal kommen, am Ende kommen und darf sich auch nicht verlängern.
Also muß durch Verriegelung verhindert werden das erneute Trigger diese Impulse mehrfach erzeugen oder verlängern.
Und der zweite 1 Sekunden Puls muß ein Retriggern verhindern während er läuft.
Man muß sich halt klar machen, das selbst bei kurzen Ereignissen, die Programmschleife x mal durchlaufen wird und ohne Verriegelungen und Zustandsmerker, der ganze Ablauf durcheinander kommen kann.
Nachdem der Vorgang gestartet worden ist, kann es zum erneuten Triggern kommen
1- während der erste Puls läuft
2- Zwichen den Pulsen
3- während der zweite Puls läuft
4- nach dem der Zyklus beendet ist.
Bei 1- darf sich nur die Zeit verlängern.
Bei 2- darf sich nur die Zeit verlängern.
Bei 3- darf gar nichts passieren.
Bei 4- wird der Zyklus neu gestarted.
und wie könnte das programmtechnisch aussehen?
Merkervariablen!
Für jeden Zustand eine Abfrage, ob die Startedingungen erfüllt sind und noch kein entsprechender Merker gesetzt ist. Wenn ja, dann kann die Start Sequenz für den Zustand durchgeführt werden. (Merker setzen, Timerwert in Variable übernehmen und z.B. Ausgangspegel ändern).
Wenn die Startbedingungen erfüllt sind und der Merker gesetzt ist, dann wird die Schlußsequenz durchlaufen.
Also prüfen ob der Timerwert vom Start plus der Wert der zu verstreichenden Zeit gleich oder größer ist als die aktuelle Zeit.
Wenn nicht ist das Sequenzende erreicht und es werden die Ausleitenden Maßnahmen getroffen.
Ggf. einen Merker setzen, das diser Abschnitt bereits ausgeführt wurde (ob dieser Merker nicht gesetzt ist, wäre dann eine der Startbedingungen), den Mekrer das dieser Abschnitt grade durchlaufen wird wieder löschen und ggf. Ausgangspegel ändern.
Man hat also für jeden Abschnitt im Zyklus zwei Sequenzen. Eine zum starten und eine zum Ausführen und beenden.
Und man hat (bei dieser Aufgabenstellung) 4 erlaubte Systemzustände.
Man erstellt eine Wahrheitstabelle und zeichnet ggf. zur Visualisierung mal die Pegel von Eingang, Ausgang, und dem Monoflop1 (lange, variable Zeit, nicht die Pulse) auf.
Dann fängt man an den Eingangsimpuls zu verlängern und erneut zu senden. und schaut, ob man immer noch das gewollte Ergebniss bekommt, oder ob sich dann z,B der 1S Puls am Start verlängert oder wärend des Zyklus wiederhohlt.
Fügt einen Merker ein und schaut ob man durch dessen Setzen das Fehlverhalten unterbindet.
Dann prüft man wann der Merker wieder gelöscht werden muß, damit man damit nicht in einem Zustand gefangen ist oder beim nächsten Durchlauf des Gesamtzyklus nicht mehr funtionsfähig ist.
Am Ende hat man eine Liste mit Merkern und wo (wann) man sie setzen und löschen muß damit das Programm immer sauber funktioniert.
Das dann in Code abzubilden ist eine reine Sache des Wissens über die Möglichkleiten der Zielsprache (hier C++).
Bei einem Programm dieser Größenordnung macht man das im Kopf oder auf dem Papier.
Bei komplexeren Programmen werden dann Unittests (der Programmierer selbst) oder Modultests (jemand fremdes als Tester) geschrieben.
Der Test bzw. die Begutachtung durch Dritte ist nicht verkehrt, damit man bei einem systematischen Fehler, seitens des Programmierers, nicht hängen bleibt.
viel einfacher ist es, das für mehrere Taster mit verschiedenen Verzögerungen per Multithreading zu lösen.
Jede Taster-Abfrage kommt in einen eigenen Thread (== eine eigene loop).
Multithreading für Arduino gibt es als Scheduler Libs, in verschiedenen Ausführungen nur für M0 und Due (sehr stabil) oder auch für AVR und ARM gemeinsam (etwas "shaky"):
http://www.mindstormsforum.de/viewto...p=66188#p66188
Multithreading birgt allerdings auch ein paar Fallstricke für absolute Neulinge, die man erst durch etwas Einarbeitung und wachsende Erfahrung in den Griff bekommt - aber dann läuft's perfekt! 8)
ach so, das hatte ich falsch verstanden, ich dachte er wollte mehrere Ausgänge mit mehreren Tastern simultan und jeweils zeitverzögert steuern.
Nein, dann ist es ja so einfach, wie ich schon hier geschrieben habe:
https://www.roboternetz.de/community...l=1#post643431