Derzeit ist es nicht so ohne weiteres möglich an den M5Stck C aber auch an die ATOM’s Units über einen PaHUB anzuschließen. Ich hoffe, dass sich das in einer der nächsten Versionen der UIFlow-IDE ändern wird. Ich habe jedenfalls darum gebeten.
Die Reaktion darauf in der Comunity erfolgte sehr schnell. Noch am selben Tag wurde die Änderung angekündigt und als ich 2 Tage später wieder in der UIFlow-IDE nachsah war sie tatsächlich schon Realität! Ich habe mich sehr darüber gefreut. Außerdem wurde mir mitgeteilt, dass auch die Möglichheit die I2C-Adressen zu verändern implementiert werden soll. Das lässt hoffen und erzeugt bei mir eine große Vorfreude.
Der folgende Teil dieses Beitrages ist jetzt nicht mehr erforderlich (20.03.2021)
Bei der Unitauswahl für die Core Geräte ist es möglich den PaHUB-Kanal anzugeben an dem die Unit angeschlossen ist. Dann funktioniert alles problemlos mit den bereitgestellten Blöcken. Beim Core2 soll es in Firmware Version 1.7.2 auch Probleme geben.
Beim Stick C/plus und ATOM wird die Möglichkeit einen PaHUB-Kanal anzugeben nicht angeboten. Wenn man die Units trozdem anschließt gibt es eine Fehlermeldung beim Start des Programms.
Unitauswahl beim Core
Unitauswahl beim Stick C
Für das oben erwähnte Problem beim Core2 habe die folgende Lösung, oder besser den Workaround gefunden:
Die Möglichkeit in der UIFlow-IDE den „Führe Code aus:“ Block einzusetzen bietet sehr viele Möglichkeiten die Einschränkungen bei den Blöcken zu umgehen. Hier wird die Initialisierung der Units hinter dem PaHUB nicht durch die UIFlow-IDE, sondern durch das Programm vorgenommen, inden der entsprechende Python-Code in den „Führe Code aus:“ Block eingetragen wird. Damit entfällt aber auch die Möglichkeit diese Units mit Blöcken anzusteuern. Diese stehen jetzt nicht zur Verfügung. In diesem Fall muss die Abfrage der Spannungs- und Stromwerte dann auch mit Python-Code in „Führe Code aus:“ Blöcken erfolgen. Deshalb ist dieser Weg für mich auch ein Workaround und keine Lösung!
Dieses Konzept lässt sich auch beim Stick C anwenden. Da die beiden Units VMeter und AMeter um die es mir hier geht in der Pythondokumentation bisher noch nicht aufgeführt sind habe ich einmal die dafür zur Verfung stehenden Blöcke eingesetzt und die Pythonübersetzung gegenübergestellt. Damit kann ich jetzt arbeiten.
Die Blöcke für die 3 Units …
… und die Python Übersetzung
Nun bleibt noch auszuprobieren, ob das auch wirklich funktioniert. Deshalb habe ich den kurzen Codeschnipzel produziert. Die PaHUB-Unit wird durch die IDE eingebunden. Das funktioniert ja. Die VMeter- und AMeter-Unit habe ich per Programm eingebunden.
Dieser Programmschnipzel funktioniert.
…und siehe da, es gibt keine Felermeldung! So kann man das Problem also umschiffen.
Einige aber nicht alle M5-Geräte sind mit einem AXP192 als Powermanagementsystem ausgestattet. Dieses IC biete viele Möglichkeiten zur Überwachung und Steuerung der Stromversorgung. Hier stelle ich ein Blockly Programm vor, dass die interessantesten Daten auf dem Bildschirm ausgibt.
Ich habe das Programm auf einem M5Stick C plus entwickelt. Mit entsprechender Anpassung der grafischen Oberfläche läuft es auch auf einem M5Stick C und einem M5Stack Core2. Nur diese 3 Geräte haben derzeit einen AXP192 als Powermanager.
Das Programm kann dauerhaft auf des Gerät geladen und bei Bedarf gestarte werden.
Das Bild oben zeigt, was alles angezeigt wird. Zur Zeile Ladestrom ist noch eine Erklärung nötig. Für den M5Stick C/plus gibt es diverse Hats mit einem eigenen Akku. Der kat keine eigene Ladeelektronik, sondern wird einfach parallel zum eingebauten Akku geschaltet. Diese Akkus haben eine Kapazität von 700 – 750mAh. Die Voreinstellung für den Ladestrom liegt bei 100mA. Da kann sich jeder selbst ausrechnen wie lange es dauert bis der Akku voll ist. Bei dem eingebauten mit 90mAh dauert es nur eine Stunde.
Deshalb habe ich eine Ladestrom Umschaltung mit Taster B eingebaut. Voreingestellt sind weiterhin 100mA. Ein Druck auf Taster B schaltet den Ladestrom auf 360mA um. Ein weiterer Druck auf Taste B schaltet wieder auf 100mA zurück. Wenn die Ladung abgeschlossen ist oder unterbrochen wird schaltet das Programm automatisch auf 100mA zurück.
Der Ladestrom kann auf vorgegebene Werte zwischen 100mA und 1A eingestellt werden. Das lässt sich auch im Programm ändern. Allerdings sollte man wissen was man tut, wenn man sich daran macht.
Die grafische Oberfläche wurde mit den UI-Simulator in der UIFlow IDE erstellt. Dashalb erscheinen im Programm keine Blöcke zur Positionierung. Der Vorteil ist, dass das Display beim Neuaufbau nicht flackert. Das erledigt die Firmware ohne das man etwas davon wahrnimmt. Mit CLS und dem lcd.print Block aus der Textsammlung gibt es erheblich Flackereffekte.
Wenn daran Änderungen vorgenommen werden sollen, dann müssen die entsprechendn Elemente in diesem Bild verschoben werden.
Drehimpulsgeber sind beliebte und vielseitige Eingabegeräte. Im M5-Universum gibt es leider nur einen für den M5Face. Deshalb habe ich mich drangesetzt und eine Routine für die anderen M5-Geräte entworfen. Diese ermöglicht den Einsatz eines Drehimpulsgebers mit der UIFlow-IDE und Blockly / Micropython.
Als Hardware kommt ein M5Stick C plus und ein Drehimpulsgeber von az-Delivery zum Einsatz. Der Drehimpulsgeber hat 3 Pullup Widerstände auf der Platine.
Der Drehimpulsgeber liefert 3 digitale Signale. Davon liefern zwei die Information über den den aktuellen Zustand des Drehgebers und eines den Zustand des Tasters. Im Ruhezustand liefern alle drei Signale eine 1.
Es gibt im Internet so einige Beschreibungen zum Thema Drehimpulsgeber. Einige davon basieren auf Interrupts, die zwar beim ESP32 vorhanden sind, aber in UIFlow und Blockly nicht zur Verfügung stehen. Deshalb habe ich mich für einen pragmatischen Ansatz entschieden. Ich habe die 2 Bits in eine Zahl umgewandelt und mir angeschaut was passiert. Dabei ist herausgekommen, dass im eingerasteten Zustand die Zahl 3 (0b11) ansteht. Beim Drehen bis zur nächsten Rastung entsteht entweder die Zahlenfolge 201 für vorwärts oder 102 für rückwärts. Dann steht wieder die 3 beim nächsten Rastpunkt an. Es ist also nur wichtig zu wissen welche Zahl nach der 3 kommt. Ein überschaubares Problem.
Nun gibt es aber auch noch einen Taster, der ebenfalls abgefragt werden soll. Dieser liefert im Ruhezustand 1, wenn er gedrückt wird eine 0. Deshalb habe ich eine 3-Bit-Zahl zu Grunde gelegt. Es wird dann fortlaufend der Zustand des Drehimpulgebers eingelesen. Wenn eine 7 (entspricht der 3 im obigen Absatz) eingelesen wird, wird ein Flag gesetzt. Wird eine 5 (1) eingelesen, wird geprüft, ob das Flag gesetzt ist. Wenn nicht wird der Wert ignoriert. Wenn ja, so wird das Flag zurückgesetzt und -1 ausgegeben. Bei einer 6 (2) erfolgt die selbe Prozedur, nur wird dann 1 zurückgegeben. Wenn die Zahl < 4 ist, ist der Taster gedrückt und es wird eine 0 zurückgegeben. Die anderen Werte interessieren dann nicht. Wird eine andere Zahl eingelesen, wird diese ignoriert.
Bei dieser Lösung wird das Programm blockiert, solange keine Eingabe erfolgt. Es können auch keine Tastendücke unterschiedlicher Länge identifiziert werden. Weiterhin findet keine Entprellen der Kontakte statt, so dass es gelegentlich zu falschen Werten kommt. Wenn die Impulse nicht gezählt, sondern als Zahl im Display angezeigt werden ist das zwar nicht schön, aber für Bastler m.E. aktzeptabel. Für den Anfang soll es so genügen. Spätere Verbesserungen sind ja immer möglich.
Zunächst müssen unter Setup die verwendeten Pins initialisiert werden:
Und nun das Programm:
dig_006.m5f
Nach einigem hin und her funktionierte das Programm dann ordnungsgemäß. Anfangs gab das Programm zwar die Werte 1 und -1 korrekt zurück, bei der 0 wurden aber immer viele Nullen ausgegeben. Ich habe lange nach der Ursache gesucht. Schließlich stellte ich fest, dass der nächste und viele weitere Aufrufe von dig_auswerten erfolgten bevor ich den Taster wieder losließ. Deshalb habe ich die Warteschleife für die Tasterauswertung eingebaut. Nun läuft das Programm.
Einen eigenen Block erzeugen
Nun werde ich versuchen einen eigenen Block für diese Funktion zu erzeugen. Eine umfangreiche Beschreibung des Blockmaker werde ich an anderer Stelle machen. Hier nur soviel wie nötig.
Es werden drei Blöcke benötigt:
init_dig – zum Initialisieren der Ports
read_dig – den aktuellen 3-Bit-Wert ermitteln
get_dig – daraus den Rückgabewert erzeugen und zurückgeben
Ich habe mich hier für englische Bezeichnungen entschieden, weil es sich dabei um die internen Bezeichnungen handelt und Englisch in der Programmierung Standard ist. Wobei dig dann in ris (rotary impuls switch) geänder werden müsste. Der Name des Blocks kann in Deutsch erfolgen.
Nachdem ich nun einige Zeit mit dem Blockmaker oder besser mit meinen mangelnden Pythonkenntnissen und einigen Nachlässigkeiten beim Testen zu kämpfen hatte, ist es mir gelungen entsprechende Blöcke zu erstellen.
Da die UIFlow-IDE die Blöcke wie Macros in den Code einfügt, ist der Block read_dig überflüssig geworden. Dessen Code habe ich gleich bei get_dig eingefügt. Die beiden übriggebliebenen Blöcke heissen jetzt init_dig und hole nächsten Impuls. Wie versprochen in deutsch.
Anwendung der Blöcke
init_dig
Wie der Name schon verrät wird mit diesem Block die Verwendung eines Drehimpusgebers initialisiert. In den Feldern pinA und pinB sind die Nummern der Pins anzugeben an denen die Anschlüsse A und B oder wie immer sie heissen mögen des Drehimpulsgebers einzutragen. Die Pinnummer des Tasteranschlusses wird bei pinT eingetragen. Das ist schon alles was zur Vorbereitung des Drehimpulsgeber Einsatzes erforderlich ist.
Hier gibt es aber einige Einschränkungen zu beachten: Es kann nur ein Drehimpulsgeber angeschlossen werden. Der Drehimpulsgeber kann nur direkt an Pins des M5-Gerätes angeschlossen werden. Ein I/O-Expander kann nicht eingesetzt werden. Weiterhin werden die drei Pins intern als Eingang und float initialisiert. Es ist also jeweils ein externen Widerstand gegen +3,3V erforderlich, so wie es bei dem von mir verwendeten Modul der Fall ist. Letzters kann leicht mit dem Blockmaker im Code geändert werden.
Da habe ich wohl schon ein neues Projekt 😉
hole nächsten Impuls
Die Impulse des Drehimpulsgebers werden einzeln geholt. Der Rückgabewert dieses Blocks ist:
1 = ein Schritt vorwärts
-1 = ein Schritt rückwärts
0 = Taster gedrückt (erst wenn Taster losgelassen wurde)
Wobei vorwärts und rückwärts sich auf meinen Testaufbau beziehen und hängt davon ab, welche internen Schalter des Drehimpulsgebers jeweils an pinA und pinB liegen. Wenn die falsche Richtung erscheint kann man:
die Kabel an pinA und pinB vertauschen,
im Blockmaker die Ausgabewerte ändern oder
die Auswertung umstellen auf -1 vorwärts und 1 rückwärts.
Wichtiger Hinweiß
Wenn Du in einem Blockly-Programm eigene Blöcke verwendest und es erneut in die IDE laden willst, so musst Du vorher die eingen Blöcke (das *.m5b-File) in die IDE laden, sonst wird das Blockly-Programm nicht geladen!
Nun viel Spaß beim Basteln.
Download
Geht noch nicht, weil WordPress den Upload der Datei noch blockiert und „WP Extra File Types“ nicht funktioniert. Ich arbeite daran.
wenn kein Blockcode eingetragen ist speichert der Blockeditor nicht. Im Zweifelsfall hilft ein # (Kommentar) Zeichen im Codefeld.
Kontakt
Wenn Jemand sich zu diesem Beitra äußern möchte, mich auf Fehler hinweisen oder Tipps dazu geben möchte, so geht dass über die Emailadresse peter@peters-bastelkiste.de
Die Kommentar- und Diskussionsfunktion ist noch nicht freigeschaltet.
Heute ist es soweit. Ich werde meine ersten Versuche mit ESP Now unternehmen.
Das Sendeprogramm
Zuerst habe ich einen Sender erstellt. Dazu habe ich einen M5ATOM lite genommen. Dieser soll auf Knopfdruck eine Nachricht (Hallo #lfd.Nr.) senden. Diese Nachricht wird zur Kontrolle auch über ein UART und die USB-Schnittstelle an einen PC gesendet. Hier zeigt Putty die Nachricht an. Die RGB-LED des M5ATOM lite leuchtet normal gelb. Wenn die Nachricht erfolgreich versendet wurde leuchtet sie kurz blau und wenn sie an den PC übermittelt wurde kurz grün auf.
Mein erstes Sendeprogramm (ESPNowTX_003.m5f)
Im Bild oben ist eine Broadcast Aussendung, also eine Nachricht an alle aktiviert. Der deaktivierte Block sendet nur an eine Adresse aus der Adresstabelle, die am Anfang definiert ist.
Dieses Programm funktioniert wie es soll.
Das Empfangsprogramm
Für den Test des Empfangsprogrammes habe ich einen M5Stick C genommen, damit ich die Nachricht anzeigen kann. Und genau das tut es auch. Es zeigt in der Titelzeile die eigenen MAC-Adresse an. Darunter die MAC-Adresse des Senders und die Nachricht.
Mein erstes Empfangsprogramm (ESPNowRX_003.m5f)
Auch dieses Programm tut was es soll. Allerdings wurden beim ersten Versuch keine Nachrichten Empfangen. Der Austausch gegen einen anderen M5Stick C brachte aber Erfolg. Offenbar ist der zuerst verwendete M5Stick C defekt, ob wohl er sich über WLAN brennen ließ. Nachdem ich die Firmware und das Programm erneut aufgespielt hatte funktionierte dieser M5Stick C auch.
Ein Sende- und Empfangsprogramm
Da bisher alles sehr gut lief habe ich gleich noch ein Programm geschrieben, dass sowohl Senden, als auch Empfangen kann. Ich brauche es für die Entwicklung eines Konverters, der serielle Signale vom PC in das ESPNow-Netzwerk überträgt und umgekehrt.
Sende- und Empfangsprogramm (ESPNowTRX_001.m5f)
In dem Block „Taste A was Pressed“ sollte der Text für jedes Gerät individuell angepasst werden. Nach dem Text wird eine laufende Nummer ausgegeben.
Die Displayausgabe habe ich in eine Funktion getan, weil ich diese an 2 verschiedenen Stellen im Programm benötige.
Ganz unten im Display und ganz klein wird die Versorgungsspannung über die USB-Buchse und der aufgenommene Strom angezeigt. Wenn die Spannung > 4V ist in grün und < 4V in rot. Dann ist es Zeit die Powerbank zu wechseln!
Die Stromversorgungsdaten werden alle 10 Sekunden gemessen und ausgegeben.
Ein kleines Problem gibt es bei dem Sende- und Empfangsprogramm allerdings. Gelegentlich wird alles im Display ganz klein dargestellt. Beim nächsten Displayrefresh wird aber alles wieder so wie es sein soll. Also kein wirkliches Problem.
Leider funktionierte der Code nicht mehr, wenn er auf das Gerät downgeloaded wurde 🙁 Der ESPNow-Teil arbeitete nicht.
Schließlich fiel einer von den drei M5Stick C die ich im Einsatz hatte ganz aus. Nach dem Löschen im Brenner ging nichts mehr. Er wurde nicht mehr vom Brenner gefunden.
Ich habe die Reset-Taste 6 Sekunden gedrückt damit das Gerät sicher ausgeschaltet ist und erstmal bei Seite gelegt. Am nächsten Morgen habe ich es erneut an den PC angeschlossen. Nun hat der Brenner es erkannt und ich konnte es löschen und die Firmware darauf spielen. Nun läuft es wieder, als wäre nie etwas gewesen. Also immer etwas Geduld mit dem M5Stick C haben, nach einer Weile kommt er meist wieder zur Vernunft.
Weiterhin musste ich feststellen, dass die Kommunikation nicht auf Kanal 1, sondern auf Kanal 6 erfolgte, obwohl Kanal 1 im Programm eingestellt war! Und genau das war das Problem ! Ich habe es nicht gleich richtig eingeordnet. Nach dem ich auf meinem Tablet einen Netzwerkscanner gestartet hatte, konnte ich sehen, dass das Gerät mit dem auf ihm gespeicherten Programm tatsächlich auf Kanal 1 arbeitet und die anderen auf Kanal 6.
Also beim Testen im RAM läuft immer Kanal 6, beim echten Einsatz wird der im Programm vorgegebene Kanal benutzt!
Beim Übertragen des Programms per RUN wird dieser Block nicht ausgewertet! Ich habe es bei M5Stack gemeldet. Mal sehen wie lange es dauert bis dieser Bug behoben ist.
Erweiteres Sende-Programm für ATOM lite
Bisher hat das Sendeprogramm nur auf Knopfdruck Daten gesendet. Nun würde ich gerne eine automatische Aussendung implementieren. Dazu habe ich einen M5ATOM lite genommen und ESPNowTX_003.m5f erweitert. Ich habe einen Timer eingefügt, der durch einen kurzen Doppeldruck auf die Taste gestartet und durch einen langen Tastendruck (> 1 Sekunde) wieder gestoppt wird. Ein normaler Tastendruck löst wie bisher das Senden eines Datenpaketes aus. Außerdem habe ich die Sendeblöcke in ein Funktion „sende“ ausgegliedert, da diese nun an mehreren Stellen im Programm benötigt wird.
Neueste Kommentare