• Bin da wohl durch meinen Beruf und die über viele Jahre gemachten Erfahrungen ein wenig geprägt :).

    Aber ja ich bleib drann !!!

    By the way, hast Du Erfahrung mit diesem Teil : BQLZR Red 240 x 320 Aufloesung 2.8""SPI TFT-LCD-Farb Touch Panel Serial Port-Modul mit PBC ILI9341?


    Gruss Frank.

  • Es gibt ja kein richtig oder falsch.... aber man kann es sich beim Programmieren leicht machen und auch schwer. Meines Erachtens sollte es das Ziel sein, einen Code möglichst leicht verständlich und nachvollziehbar zu erstellen (der dann aber trotzdem der Aufgabe gerecht wird). Ich verstehe Deine Intention. Aber ich denke, die ist zu kompliziert gedacht.


    Wenn Du dir die Musterlösung anschaust, dann ist die Starttaste schon durch die Flagvariable "aktiv" abgefangen. Einmal Start betätigt, läuft die Zeitmessung los. Danach kann die Taste so oft gedrückt werden wie ein Igel Stacheln hat... es spielt keine Rolle mehr, solange nicht per Stopptaste die Zeitmessung beendet wird.

    Aufgabe war es, mit einer weiteren Taste eine Zwischen- und eine Etappenzeit zu stoppen. In der Musterlösung wurde der Einfachheit halber angenommen, dass man die Taste nicht länger drückt als eine Sekunde. Im Prinzip kann das aber auch ebenfalls mit einer Flagvariable für den Zwischenzeittaster geregelt werden.

    Diese Flagvariable ist so lange gesetzt, solange die Taste gedrückt wird. Weil ihr Initialisierungswert aber ungesetzt (False) ist, wird beim Tastendruck die Ermittlung de Zwischenzeit ausgeführt und die Flagvariable auf True gesetzt. Weil auch in der Schleife überprüft wird ob die Taste auch mal losgelassen wurde (dann wird die Flagvariable wieder zurückgesetzt) erreicht man auch, dass man die Taste so lange drücken kann wie man will, es hat keinen Einfluss mehr auf die Zeitmessung und Zeitanzeige.


    Das sähe dann wie folgt aus:



    Das erscheint mir wesentlich verständlicher als Deine Lösung mit dem gleichen Ergebnis. Nur mit dem Unterschied, dass die Stopptaste bei der Musterlösung sofort wirkt. Hast Du bei deiner Lösung mal die Stoptaste gedrückt gehalten? Die Zeit hält erst an, wenn man die Taste loslässt.


    Was das "Entprellen" betrifft. Das ist ein physikalischer Effekt, den Du mit Deinem Programm so wie es geschrieben ist, nicht kompensieren kannst.

    Wenn der Taster so stark prellt, dass der Pegel unter die Spannung geht, die der Controller für "HIGH" hält, wird der Aufruf taster.value() ein False liefern obwohl die Taste gedrückt ist und es wird eine andere IF Bedingung wahr obwohl man den Taster nie losgelassen hat. Schon ist die Flanke dahin.....


    Ist also auch nicht besser als in der Musterlösung.


    Das ist ja kein Paket, dass ein paar Sekunden an einer Lichtschranke vorbeizuckelt, sondern ein Taster der mehrmals innerhalb von Mikrosekunden abgefragt wird.


    Verstehe mich nicht falsch .. ich finde es interessant mich mit Deinem Ansatz zu beschäftigen und will auch jetzt nicht die von mir gepostete Miniergänzung zu René's Musterlösung als DIE Richtige hinstellen. Kann gut sein dass da auch ne Macke drin ist, die mir nicht aufgefallen ist.


    Bleib drann :)


    Gruß Kai

  • Hallo Kai,

    Du kannst jede Taste solange betätigen wie Du magst, es wird immer nur der erste Programmzyklus ausgewertet. Es wird also eine Signaländerung erfasst und nicht das dauerhafte betätigen des Tasters. Erst wenn der Taster wieder gelöst wurde ist es möglich den Taster wieder abzufragen. So lassen sich die Taster auch sehr einfach verriegeln. In meiner Lösung kann die Stoppuhr nicht falsch bedient werden. Stoppen geht zum Beispiel nur wenn auch gestartet wurde. Um neu zu starten muss gestoppt worden sein. Ebenso verhällt es sich mit dem Taster für die Zwischenzeit, der kann nur während der Laufzeit betätigt werden. Das Prellverhalten wird bei der Flankenauswertung ebenfalls berücksichtig.


    if taster_1==True and flanke_t1==False :

    flanke_t1=True #---Taster 1 war für einen Zyklus 1

    if taster_1==False and flanke_t1==True:

    flanke_t1=False



    Bei einem Taster gibt es insgesamt 4 theoretische Zustände:

    1. war nicht gedrückt und ist nicht gedrückt

    2. war nicht gedrückt und ist gedrückt (steigende Flanke)

    3. war gedrückt und ist immer noch gedrückt

    4. war gedrückt und ist nicht mehr gedrückt (fallende Flanke)


    Diese einzelnen Zustände lassen sich jetzt bequem abfragen/durchlaufen. Die Entprellung geschieht dabei durch die ganze Laufzeit des Programms.


    In der Tasterauswertung liegen auch die schwächen in der Musterlösung.


    Hab mal ein sehr bildliches Beispiel eingefügt :

    Zitat
    • An einer Förderbandanlage ist eine Lichtschranke angebracht, die das Signal 1 gibt, wenn die Lichtschranke unterbrochen wird (Schließer). Es soll eine Aktion ausgelöst werden, sobald ein Paket an der Lichtschranke ankommt und die Lichtschranke unterbricht, z.B. Paketaufkleber kleben. Sobald das Paket die Lichtschranke berührt, wechselt das Signal von 0 auf 1, denn vorher war noch kein Paket da und die Lichtschranke hatte das Signal 0. Es liegt also eine Signalveränderung vor.
    • Wenn man die auszuführende Aktion, z.B. Paketaufkleber kleben, nicht an die Signalveränderung koppeln würde, sondern lediglich anweisen würde, den Paketaufkleber zu bewegen, wenn die Lichtschranke das Signal 1 gibt, dann würde der Paketaufkleber mehrmals bewegt werden, zumindest solange, bis das Paket die Lichtschranke wieder verlassen hat und das Signal 0 ist.
    • Da ein Paket eine gewisse Länge hat, die Lichtschranke also weiterhin das Signal 1 liefert, obwohl bereits der Paketaufkleber 1x bewegt wurde, muss eine Möglichkeit her, den Paketaufkleber an ein Signalwechsel der Lichtschranke, in diesem Fall von 0 auf 1, zu koppeln.
    • In diesem Fall würde der Paketaufkleber nur 1x bewegt werden, nämlich nur dann, wenn ein Paket an der Lichtschranke ankommt und somit das Signal der Lichtschranke von 0 auf 1 ändert. Ob danach die Lichtschranke weiterhin das Signal 1 gibt, interessiert den Paketaufkleber nicht mehr. Denn der Paketaufkleber wird nur tätig, bei Signalveränderungen und nicht nur bloß, weil die Lichtschranke das Signal 1 liefert.
    • Solche Steuerungen lassen sich mit Flankenauswertungen realisieren.
  • Hallo Frank,


    ich weiß ja nicht ob Du Dir die Lösung von René inzwischen mal angeschaut hast .... Wenn ja , dann würde es mich echt interessieren was du gedacht hast, als du den gesehen hast ;).


    Ich frage mich bei unserem Austausch, auch bei Lektion 4, was ist für Dich eigentlich eine Flanke?

    Mit den bis Lektion 6 vorgestellten Programmiermitteln kann man doch nur feststellen ob eine Taste "gedrückt" oder "nicht gedrückt" ist. Also nur den Wert HIGH (3,3V) oder LOW (0V) ermitteln.


    Flanken, ob egal positiv (steigend) oder negativ (bzw. fallend weil < 0V wird es nicht) spielen doch gar keine Rolle.


    Diese Flankengeschichte machen den Code wirklich sehr schwer verständlich und unnötig kompliziert.



    Gruß Kai

  • Hallo zusammen,

    die Lektion Stoppuhr habe ich nun auch gelöst.

    Habe besonderen Wert auf die Taster gelegt ( positive Flanke ).

    So richtig einfach fand ich die Lektion nicht aber durch Hilfe hier im Forum und durch die Videos von Rene konnte ich die Aufgabe lösen.

    Das war mein erstes Programm in Python bzw. mein erster Kontakt zu einem Mikrocontroller.

    Danke an alle ich werde am Ball bleiben.


    Gruss Frank.


  • Hallo Frank,


    nein, normalerweise nicht. Der primäre Takt wird durch den Quarz bestimmt. Ein Teiler rechnet den Takt auf die gewünschte Einheit (z. Beispiel Millisekunden) herunter. Dabei entstehen zwei Fehler:


    - Der Quarz hat eine beschränkte Genauigkeit. Bei einem guten Quarz ist dieser Effekt aber sehr klein.

    - Durch die Berechnung entstehen Rundungsfehler. Als Teilerfaktoren sind nur Zweierpotenzen möglich und so wird man nie exakt 1 ms erreichen.


    Ein weiterer Faktor liegt beim Programmierer. Die Zeitzählung wird mit Hilfe von Interrupts durchgeführt. Wenn der Programmierer selbst Interrupts verwendet, kann es sein, dass zwischendurch mal ein Timer - Interrupt verloren geht.


    Für eine Stoppuhr, die im Bereich von Minuten oder wenigen Stunden arbeitet, genügt normalerweise die Genauigkeit. Für Uhren, die über lange Zeit exakt laufen sollen, kann ein externer RTC - Chip verwendet werden. Oder falls die Schaltung sowieso mit dem Internet verbunden ist, kann regelmässig eine Korrektur durch Synchronisation mit einem Zeitserver erfolgen.


    Gruss

    René

  • Hallo René


    Ich schliesse mich der Meinung von AnFi voll und ganz an.


    Die Aufgabe aus Lektion 6 habe ich abgeschlossen. Ich habe sie (notgedrungen) so gelöst, dass kein Steckboard erforderlich ist und nur der interne Druckschalter verwendet wird (als Stepper). Dabei habe ich festgestellt, dass der "Prellt", also beim Drücken mehrfach auslöst (Meine Lösung dazu: Zeit messen, die seit dem letzten Drücken (steigende Flanke) vergangen ist).

    Dann wollte ich meine bisher gewohnten globalen Variablen einsetzen und bin dann nach langem Suchen im Internet fündig geworden.

    Dabei habe ich zur Kenntnis genommen, dass globale Variablen mit Python "schlechter Stil" sei (mit Ausnahmen bin ich damit einverstanden).

    Ich freue mich auf die weiteren Lektionen und bedanke mich für Deine hervorragende Arbeit.

    Gruss

    Raymond

  • Das ist eigentlich auch der Sinn der Reihe. Sobald es dann um Kommunikation im Internet und Webserver geht, werden die Vorteile von Micropython ersichtlich. Ausserdem gibt es auf Youtube kaum ausführliche deutschsprachige Tutorials zu Micropython. Für mich ist es spannend mal etwas Neues zu machen und ich hoffe einfach, dass die Zuschauer da mitziehen.

  • Aus meiner Sicht bist du mit deiner ESP32/MicroPython-Tour auf dem richtigen Weg. Sowohl bezüglich Level wie auch didaktisch. Lasse dich von den Zappern nicht entmutigen, die Langzeitwirkung des Projektes ist nachhaltig. Dieser Exkurs ausserhalb der Arduinoumgebung mit ESP und mit dem Kennenlernen einer neuen Programmiersprache eröffnet mir neue Perspektiven und vermittelt neue Impulse. Danke - bitte weiter so!

    Andreas

  • Mal schauen, ob wir im Kurs so weit kommen. Vom Standpunkt der Genauigkeit her ist es eher ungünstig, wenn mehrere Prozessoren gleichzeitig synchron laufen sollten. Momentan habe ich auch noch keine Ahnung, wie man das am Vernünftigsten realisiert.


    Gruss

    rené

    Vom Verständnis her: Also die Zwischen und Ziel-Esps brauchen ja nur das Signal der Lichtschranke zu senden - die Zeit auf dem ESP, der die Zeit misst, läuft ja für sich allein. Es sollen sozusagen nur die Tastersignale ersetzt werden.

    Ja, das tönt sehr vernünftig. Vermutlich ist es dann nicht einmal notwendig, an jeder Stelle einen ESP32 zu verwenden.

  • Mal schauen, ob wir im Kurs so weit kommen. Vom Standpunkt der Genauigkeit her ist es eher ungünstig, wenn mehrere Prozessoren gleichzeitig synchron laufen sollten. Momentan habe ich auch noch keine Ahnung, wie man das am Vernünftigsten realisiert.


    Gruss

    rené

    Vom Verständnis her: Also die Zwischen und Ziel-Esps brauchen ja nur das Signal der Lichtschranke zu senden - die Zeit auf dem ESP, der die Zeit misst, läuft ja für sich allein. Es sollen sozusagen nur die Tastersignale ersetzt werden.

  • Ich habe es bereits mit Arduino per cc+ hinbekommen. Da läuft schon alles per UDP, was wohl besser als TCP geeignet sein soll.(Wlan ist ja beides - denke ich)


    Nun aber, möchte ich gern alles per Python hinbekommen und es richtig verstehen. Das Arduino Projekt habe ich mehr durch Zufall und Paste/Copy hinbekommen :-)


    VG Hardy

  • Hallo Hardy,


    dein Vorschlag ist wirklich interessant, aber würde dann sicherlich auf einer WLAN-Verbindung der ESP-Rechner untereinander und im selben WLAN voraussetzen. Ansonsten müsste man die Verbindung der ESP-Rechner untereinander im lokalen Netzwerk (LAN) realisieren. Dabei müssten dann die drei ESP-Rechner im LAN über USB-Kabel als LAN-Client ins Netz gehen.


    WLAN wäre dann wohl die komfortablere Lösung. Aber wenn ich das richtige sehe, bräuchte man für die WLAN-Clients mit den ESPs noch einen WLAN Hotspot im Sinne eines WLAN-Access-Points.


    Diesbezüglich nehme ich an, dass das Thema mit dem WLAN früher oder eher später auf einem YouTube-Video vom Hobbyelektroniker René behandelt wird.


    Gruß


    Dieter

  • Gratuliere zu den gefundenen Lösungen. Eine weitere Lösungsmöglichkeit werde ich heute im Video von 19:00 vorstellen.

    Supi! Ich hätte da noch einen "kleinen" Wunsch :-) Könntest Du auch ein Video machen, wo 2 oder mehrere esp32 per UDP verbunden sind und die Pinzustände senden? (wäre für mein Projekt: Lichtschranke/Stoppuhr, welches ich bisher nur als Kabelvariante geschafft habe)


    In etwa so:

    Board1ist die Stoppuhr.

    Board2 ist die Zwischenzeit

    Board3 die Zielzeit.


    UDP soll da recht schnell sein.


    Das wäre echt prima.


    VG Hardy