Namensräume bei mehreren hintereinander ausgeführten Scripts.
Version 1.11.8
Wenn 2 Scripte nacheinander ausgeführt werden ohne den ESP32 zwischenzeitlich neu zu booten, so sind im M5Stick C Plus die Namen der Objekte des zuerst ausgeführten Scripts im anschließend ansgeführten Script bekannt.
Beim M5STAMP Pico ist das nicht der Fall! offenbar wird vor dem Start des zweiten Scripts hier der Speicher geleert. Der freie Speicher war nach dem Ausführen von 2 Scripten genauso groß wie nach dem Ausführen nur des zweiten Scriptes. Das gilt nur für die REPL! Im Normalbetrieb sind in main.py die Objekte aus boot.py sichtbar.
libs.urequests beim M5ATOM Lite funktioniert nicht.
Beim M5Stick C Plus und beim M5STAMP Pico tut sie was sie soll.
Durch den Touchscreen des M5Stack Core 2 bieten sich viele Eingabemöglichkeiten die bei den Geräten ohne Touchscreen extern nachgerüstet werden müssen. Mein erster Versuch gilt einem nummerschen Keyboard auf dem Touchscreen.
Ehrlich gesagt ist mein zweiter Versuch. Der Erste war nur mal zum probieren wie das überhaupt geht. So war die GUI nach einem LCD_clear oder Clear_screen verschwunden und nicht wieder herstellbar. Auch war mir nicht klar, ob die Touch-Button wenn sie unsichtbar sind noch reagieren. Das alles habe ich beim ersten Austesten herausbekommen und ist in diesen Beitrag eingeflossen.
Auf diese Erfahrungen aufbauend ist dieser Versuch am Ende wirklich einsetzbar.
Das Ergebnis des zweiten Anlaufs kann sich sehen lassen:
Darstellung des Versuchsprogramms
Die Nutzung des Touchscreens geht am einfachsten mit dem UI-Simulator der UIFlow-IDE. Der ist aber nicht sonderlich komfortabel. Ich habe mich deshalb zu folgender Vorgehensweise entschlossen:
Die Darstellung der GUI und die erforderlichen Objekte werden vorher entworfen.
Die GUI-Elemente mit dem UI-Simulator erzeugen und nur die wesentlichen Eigenschaften festlegen.
Sie werden platzsparend irgenwie und -wo im UI-Simulator angelegt.
Die Anordnung auf dem Display wird vom Programm vorgenommen.
Sie werden im Programm sichtbar bzw. unsichtbar geschaltet. Dadurch wird ihre Funktion aktiviert bzw. deaktiviert.
So sehen die grafischen Elemente beim Erstellen aus. Das ist ein Programmausschnitt der die Objekte anordnet.
Die Blöcke der Buttons und Labels bieten eine große Gestaltungsmöglichkeit. Diese sollte man nutzen um ein ansprechendes Aussehen zu erzeugen. Vor allem kann man die Objekte sichtbar (show) und unsichtbar (hide) machen. Unsichtbare Button reagieren nicht auf Berührung. So kann man auch verschiedene Objekte übereinander legen. Aktiv ist immer nur das sichtbare Objekt. Eine sehr interessante Gestaltungsmöglichkeit für eine GUI.
Ich habe im Testprogramm die Button „show“ und „hide“ eingebaut, mit denen ich die Tastatur ein- und ausschalten kann. Die Anzeige der Eingabe „label_input_show“ bleibt aber und so kann überprüft werden, dass tasächlich keine Eingabe erfolgt, wenn die Tastatur unsichtbar ist.
Die Funktionen und Buttom-Aktivities zum sichtbar und unsichtbar machen der Tastatur.
Hier kann die Programmdatei für die UIFlow-IDE heruntergeladen werden:
Mein Traum seit vielen Jahren ist es ein drahtloses Multimeter aufzubauen. Mit den M5Stack Geräten ist dieser Traum der Wirklichkeit sehr viel näher gerückt und mit dem Erscheinen der isolierten Units VMeter und AMeter steht der Realisierung nun nichts mehr im Wege.
Erster Testaufbau – ein chaotisches Gewusel
Auf dem Bild seht Ihr den ersten Testaufbau. Dank der Steckmöglichkeiten war es schnell zusammengesteckt und getestet und funktionierte. Die Spannungswerte sind zwar nicht real aber die Grundsätzliche Funktion ist gegeben. Die Spannungseingänge sind offen und fangen sich offenbar alle möglichen Störsignale ein. Die Stormaufnahme von 500mA enthält den Ladestrom für den Akku des M5Stick Cplus. Mit geladenem Akku sind es immerhin noch 460mA.
Ganz einfach war es nicht diese Kombination zu realisieren, weil die UIFlow-IDE es nicht ermöglichte ohne weiteres die Units am PaHUB zu betreiben. Erst der in diesem Beitrag beschriebene Trick brachte den Durchbruch:
Die Units können inzwischen auch direkt in der UIFlow-IDE hinter einem PaHUB benutzt werden.
Das erste Testprogramm
Das erste Testprogramm – Die GUI wurde mit dem UI-Simulator von UIFlow erstellt.Das an die neuen Möglichkeiten der UIFlow-IDE angepasste Programm (MVA033-010.m5f).
Messgenauigkeit
VMeter Unit
Um überhaupt etwas messen zu können habe ich eine LiIon-Zelle an alle drei VMeter angeschlossen. Eine davon invers gepolt. Das geht Dank galvanischer Trennung der Messteile problemlos. Die Anzeige schwankt zwischen 3,463 und 3,475 Volt. Als eine Unsicherheit von 12 mV. Die Spannungsänderungen springen in 4 mV Schritten. Mein Rigol DM3068 zeigt 3,4629 Volt an. Das entspricht -0% … +0,35% Abweichung. Für allgemeine DIY-Messungen völlig in Ordnung.
AMeter Unit
Zum testen der AMeter habe ich alle drei und das Rigol in Reihe geschaltet und an ein Hameg HM8040 Netzgerät angeschlossen. Mit dem Stromegrenzungspoti habe ich den Stron eingestellt. Da ich die Stromanzeige auf ganze mA eingestellt habe gibt es bei den kleineren Strömen ungenauigkeiten. dazu werden ich anschließend eine Weitere Messreihe durchführen.
DM3068
AMeter
10,0776 mA
10 mA
20,461 mA
20/21 mA
50,762
51/50 mA
99,315
100/99 mA
201,025
201/202 mA
301,47
301/302/304 mA
404,92
405/406/407 mA
mehr geht nicht beim HM8040
Auch diese Werte können sich sehen lassen. Alle Abweichungen <1%.
Maximal können Ströme bis ±4 A gemessen werden. Die höheren Ströme werde ich später testen. Genauso wie Ströme <1 mA.
Drahtlose Kommunikation
Ein großer Vorteil des ESP32 ist es, dass die Messwerte drahtlos übertragen werden können. Dafür stehen die WLAN-Einheit oder die Bluetooth-Einheit des ESP32 zur Verfügung.
Ein eigenes Übertragungsprotokoll
Im Prinzip ermöglichen die unten aufgeführten drahtlosen Übertragungsprotokolle schon Alles. Warum also noch ein eigenes Protokoll darauf setzen?
Der wesentliche Grund ist, dass es mir beim ESP Now – das ich bevorzugt einsetzen möchte – noch nicht gelungen ist mit der UIFlow-IDE im laufenden Betrieb neue Peers in ein Netzwerk aufzunehmen. Die MAC-Adresse muss zur Programmierzeit bekannt und fest im Programm vorgegeben sein. Damit lässt sich aber kein flexibles zur Laufzeit zusammenstellbares Mess-Netzwerk aufbauen.
ESP Now ist ein Protokoll von Espressif, dass die UIFlow-IDE unterstützt. Damit ist recht einfach ein kleines Netzwerk aufgebaut, dass keinen Accesspoint benötigt. Die einzelnen ESP32 Geräte kommuniziernen direkt miteinander. Der Nachteil ist, das bei der Programmierung mit der UIFlow-IDE die MAC-Adressen aller Mitglieder eines solchen Netzwerkes bekann sein müssen. Ob das bei ESP Now grundsätzlich so ist glaube ich nicht. Es ist mir bisher aber nicht gelungen einen Workaround für Micropython und damit für Blockly zu finden. Man kann mit ESP Now aber auch Broadcast Packete aussenden, so dass jedes andere Gerät die Informationen empfangen kann. Das ist zwar nichts für reale Anwendungen, aber zum Ausprobieren ist es zu gebrauchen.
Ein einfaches Programm, dass alle 6 Messwerte ermittelt und anzeigt. U1 wird als Broadcast mit ESP Now gesendet.Hier das dazugehörige Empfangsprogramm
Die beiden oben abgebildeten Programme zeigen die Möglichkeit der Übertragung mit ESP Now.
Eine Schwierigkeit bei ESP Now ist, dass die Daten als String übertragen werden. Wenn Die Daten in eine Liste gepackt werden und diese Liste übertragen wird sieht der String nach dem Empfang so aus: „[ Wert1, Wert2, Wert3, Wert4, Wert5 Wert6] „. Die Werte daraus zu entpacken ist etwas umständlich. Zuerst müssen die eckigen Klammern entfernt werden:
Aus dem von den eckigen Klammern befreiten String kann nun wieder eine Liste erstellt werden:
Nun ist tmp_date eine Liste die die Messwerte enthält.
In einer Schleife lassen sich nun die Messwerte auslesen. Hier ein kleines Programm, dass die Messwerte untereinander im Display darstellt, zurechtgestutzt auf ganze mV und mA.
Ein universelles Empfangprogramm. Es wird eine Liste mit Daten erwartet und dargestellt.
Ein einfaches Sendeprogramm, dass die Daten der 6 Messstellen in eine Liste verpackt überträgt.
Damit kann man schon erste Versuche anstellen.
MQTT
MQTT ist ein Protokoll, dass für den Zweck der Messwerverteilung sicher gut geeignet ist. Es benötigt im WLAN aber einen Brocker, der die Daten entgegen nimmt und weiterverteilt an die Geräte die diese abonniert habe.
WLAN
Das Gerät mit einem Webserver auszurüsten und die Daten dort abzuholen oder vom Server zuschicken zu lassen ist wohl die Königsklasse der drahtlosen Übertragung. Dazu fehlt mir aber noch einiges an Wissen, so dass dieser vorläufig nicht von mir beschritten werden wird.
Grenzwertüberwachung
Die integration einer Grenzwertüberwachung erweitert den Einsatzbereich des Gerätes. Dazu ist eine Tastatur zur Eingabe der Grenzwerte und eine Ausgabe durch Logiksignale, ggf. eine Darstellung auf dem Display.
Für die Grenzwertüberwachung ist wie schon erwähnt eine Tastatur erforderlich, die 5, 7 oder 8 Leitungen benötigt, je nach Anzahl der Tasten. Ausserdem sollte eine Grenzwertüberschreitung auch nach Außen gemeldet werden. Dazu sind weitere 6 oder 12 Leitungen erforderlich. Je nach dem ob Über- und Unterschreitung oder nur eine einfache Meldung erfolgen soll.
Nun wird es eng auf dem I2C-Bus. Es werden weitere 2 bis 3 I/O-Expander benötigt. Das funktioniert nicht weil deren Adresse nicht umgestellt werden kann (in der UIFlow IDE). Ein weiterer PaHUB kan auch nicht eingesetzt werden, aus dem selben Grund. Der Versuch einen I/O-Expander und einen PbHUB zu kombinieren schlug auch fehl, weil ein I2C-Error gemeldet wurde. Der PbHUB belastet den I2C-Bus offenbar zu stark. Eine M5Stack inherente Lösung gibt es offenbar nicht. Deshalb habe ich I2C-Bus -Expander-IC’s bestllt. Ich hoffe damit lässt sich das Problem lösen.
Ich habe das Proglem mit den fixen Adressen in der UIFlow-IDE und damit auch in Micropython zwar an M5Stack weitergegeben, aber aufgrund meiner bisherigen Erfahrungen rechne ich mit großer Resonanz.
Alternativ könnte das Problem mit den Adressen mit der Arduino-IDE gelöst werden. Soweit ich weiß, kann man dort die I2C-Adresse eines Bausteins angeben. Aber ich wollte doch bei Blockly und Micropython bleiben.
Eingabe Tastatur
Als Eingabetastatur käme eine 4×4-Matrix-Tastatur in Frage. Diese ist aber relativ groß. Alternativ könnten auch Touchkeys zum Einsatz kommen. Deren Eignung muss aber noch untersucht werden.
Software
Die Software muss zum Einen die Eingabe des Grenzwertes für jeden Messkanal ermöglichen. Während des Messens müssen die Werte überprüft und ggf. Aktionen ausgeführt werden.
Darstellung im Display
Im Display kann ein Wert normal grün, in der Nähe des Grenzwerte gelb und bei überschreiten des Grenzwertes rot angezeigt werden.
Ausgabe
Die Ausgabe könnte durch Darlingten-Treiber-IC z.B. ULN2008 realisiert werden. Das ist universal einsetzbar und kann ggf. auch Relais treiben.
Die VMeter-Unit ist ein isoliertes Voltmeter. Der Messteil ist also galvanisch von der übrigen Schaltung, also dem M5Gerät getrennt. Deshalb kann damit an beliebiger Stelle in einer Schaltung gemessen werden, auch wenn diese mit dem M5-Gerät elektrisch verbunden ist. Weiterhin hilft es Störungen zu verringern und die Unit vor Zerstörung zu schützen.
M5Stack gibt an, dass jede Unit individuell mit einer Genauigkeit von 0,1% Skalenendwert ±1 kalibriert wird. Die maximal messbare Spannung beträgt ±36V.
Die Auflösung beträgt mit automatischer Messbereichswahl bei Spannungen ≤ 16V 1mV und bei Spannungen > 16V 7,9mV.
Die Isolierung verträgt Spannungen bis 1000 Veff.
Der ADS1115
Das Herz dieser Unit ist der 16-bit-ADC ADS1115. Hier möchte ich dieses IC näher betrachten.
Der ADS1115 besteht aus einem Multiplexer mit 4 Eingängen, einem programmierbaren Verstärker PGA) dem 16Bit-ADC, einer Referenzspannungsquelle und dem I2C-Interface. Mich interessieren hier nur die analogen Blöcke.
Der Multiplexer
Der Multiplexer interessiert bei der Betrachtung der VMeter-Unit wenig, weil dieser nicht genutzt wird. Es werden nur die Eingänge AIN0 und AIN1 als differenzeingang genutzt, wobei AIN0 auf 2,5 Volt liegt, um positive und negative Spannungen messen zu können. das IC kann entweder vier Single-Ended- oder zwei Differenzsignale messen. Entladungsdioden (ESD), die mit VDD und GND verbunden sind, schützen die analogen Eingänge des ADS111x. Um das Einschalten der ESD-Dioden zu verhindern, darf die Eingangsspannung eines jeden Eingangs nur im angegebenen Bereich von GND- 0,3 V < V(AINX)< VDD+ 0,3 V. Wenn die Spannungen an den Eingangspins potenziell die Bedingungen verletzen können, verwenden Sie externe Schottkydioden und Serienwiderstände, um den Eingangsstrom auf sichere Werte zu begrenzen.
Soweit die wichtigsten Informationen aus dem Datenblatt.
Die Analogeingänge
Die Informationen im Datenblatt zu den Analog Eingängen sind für die Anwendung der VMeter-Unit uninteressant.
Der Wandler
Das IC ist mit einem prigrammierbaren Vorverstärker vor dem ΔΣADC ausgestattet. Damit lassen sich die folgenden Messbereiche einstellen: ±6,144V, ±4,096V, ±2,048V, ±1,024V, ±0,512V, ±0,256V.
Die analogen Eingangsspannungen dürfen die in den absoluten Maximalwerten angegebenen Grenzwerte nicht überschreiten. So können z. B. bei VDD = 3,3 V und FSR = ±4,096 V nur Signale bis VIN = ±3,3 V gemessen werden. Spannungen|VIN| > 3,3 V können nicht gemessen werden.
ADS111x verfügt über eine integrierte Spannungsreferenz. Eine externe Referenz kann nicht verwendet werden. Fehler, die mit der Genauigkeit der Anfangsspannungsreferenz und der Referenzdrift mit der Temperatur verbunden sind, sind in den Angaben zum Verstärkungsfehler und zur Verstärkungsdrift in der Elektrischen Kennlinien Tabelle enthalten.
Der ADS111x hat einen integrierten Oszillator, der mit 1MHz läuft. Für den Betrieb des Gerätes kann kein externer Takt angewendet werden.
Der ADS111x bietet programmierbare Ausgangsdatenraten von 8SPS, 16SPS, 32SPS, 64SPS, 128SPS, 250SPS, 475SPS oder 860SPS.
Rauschen
Das Rauschen beeinflusst die maximal nutzbare Auflösung. Im Datenblatt befinden sich dazu diese beiden Tabellen:
Tabelle 1 zeigt die Rauschspannung in µVeff und µVss.
Tabelle 2 gibt an wie viele der 16 bit Auflösung durch das Rauschen noch aussagekräftig sind. Ebenfalls bezogen auf das Rauschen in µVeff bzw. µVss.
Bis zu 64 Messungen/Sekunde sind demnach bei allen Messbereichen die vollen 16-Bit gültig. Bei 860 Messungen/Sekunde sind es nur noch ca. 14-Bit.
Die Betriebsarten
Der ADS111x arbeitet in einer von zwei Betriebsarten: kontinuierliche Wandlung oder Single-Shot.
Die analogen Eigenschaften aus dem Datenblatt
Interessant ist für mich noch der maximale Strom an den Eingängen, um die maximale Spannungsbelastung zu berechnen. Der beträgt ±10 mA.
Meine Beurteilung
Was mir zuerst auffiel ist der Eingangsspannungsteiler aus 680k / 11k. Dieser reduziert das Eingangssignel auf 0,01592 also ca. 1/60. Damit geht doch sehr viel Auflösung verloren.
Bei einem Widerstand von 680kOhm und 10mA maximalen Eingangsstrom darf die Eingangsspannung maximal 6800V betragen, bevor das IC zerstört wird. Das entspricht einer Leistung von 68Watt die der SMD-Widerstand mit Sicherheit nicht verträgt.
Die maximale Eingangs- und messbare Spannung wird mit +- 36Volt angegeben. Das ergäbe hinter dem Spannungsteiler am IC eine Spannung von 0,57312 Volt. Da die Betriebsspannung 5 Volt beträgt ist am IC eine Spannung von 5 Volt zulässig. Da AIN0 auf 2,5Volt liegt bleiben noch ±2,5Volt übrig die messbar sind, also etwa die 4fache Spannung. Hier werden ca. 2 Bit an Auflösung verschenkt.
Unter Berücksichtigung des Vorteilers und einer Eingangsspannung von 5 Volt am IC wäre eine maximale Spannung von 314 Volt noch messbar.
Es viel auszuprobieren in der nächsten Zeit.
Fazit für die VMeter-Unit
Die VMeter-Unit ist sehr auf Sicherheit ausgelegt und so wie es scheint dürfte sie im praktischen Einsatz ziemlich unverwüstlich sein. Praktische Erfahrungen habe ich bisher nur sehr wenige, aber das wird sich bald ändern. Diese werde ich dann hier niederschreicben.
Jedenfalls scheint diese Unit ein großes Potential für Modifikationen zu bieten.
Meine Erfahrungen
Ich habe eine Genauigkeit von 0,2% vom Messwert bei ca. 3,6 V festgestellt. Gemessen mit einem Rigol DM3068 (0,0035% Grundgenauigkeit). Das Gerät ist allerdings nicht erneut kalibriert worden und mittlerweile ca. 3-4 Jahre alt.
Das Innenleben
Ich habe die VMeter-Unit geöffnet, weil sehen wollte, ob der Eingangsspannunsteiler einfach umzubauen ist. Das sind die beiden Widerstände parallel zur orangen Buchse. Unten der 680KOhm und darüber der 11kOhm Widerstand.
Diese beiden Widerstände sind sicher bald ein Ziel für Modifikationen.
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.
Dieser Begriff beschreibt eine interaktive Programmierschleife, ähnlich wie IDLE Es geht darum einen Befehl einzulesen, auszuwerten und das Ergebnis auszugeben. Dazu wird eine Konsole mit einem Computer verbunden. Die Ein- und Ausgabe erfolgt am Terminal, die Auswertung/Verarbeitung im Computer.
Hier bedeutet das konkret, dass der M5Stick Cplus über seine USB-Schnittstelle mit dem PC verbunden wird. Dann wird ein Terminalprogramm wie Putty oder auch eine Python-IDE wie Thonny gestartet und dieses mit dem M5Stick Cplus verbunden. Die Tastenkombination Strg + C (Ctrl + C) gedrückt, ggf. mehrmals und dann kann man Micropython Code interaktiv eingeben. Die Ausgabe erfolgt je nach Kommando im Terminalprogramm oder auf dem Display des M5Stick Cplus.
M5Stick Cplus auf USB-Mode einstellen. Das ist wohl nicht erforderlich.
REPL unter Ubuntu 20.04
Ich hatte große Probleme zuverlässig eine REPL-Verbindung aufzubauen.
REPL mit PuTTY
Mit Putty ist es mir bisher noch nicht gelungen eine REPL einzurichten. Es kommt immer die Meldung, dass die serielle Schnittstelle nicht eingerichtet werden konnte.
REPL mit Thonny
Auch hier gab es spontan funktionierende Verbindungen und dann ging wieder gar nichts mehr. Zuletzt bin ich zu der Ansicht gelangt, das man am besten mit dem Stoppschild oben die letzte Verbindung beendet, mit Ctrl-D einen Softreset ausführt und dann mit Ctrl-C in die REPL gelangt. Das funktionierte zuletzt relativ zuverlässig.
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.
Nachdem der Fernsteuersender funktioniert ist jetzt der Empfänger dran.
Anforderungen
Die Umsetzung in kleinen Schritten
Das MAC-Adress Problem
Das erste Problem war, dass der M5Stack C mir mit dem Block „get mac adress“ 24:a1:60:53:bc:15 anzeigt. Als Absenderadresse sendet er aber 24:a1:60:53:bc:14.
Der erste Versuch – Kontaktaufnahme
Als die MAC-Adresse angepasst war funktionierte das erste Programm:
Der zweite Versuch – Daten extrahieren – dauert etwas länger
Nun der nächste Versuch. Die Daten hatte ich im Senderprogramm in eine Liste getan. So werden sie auch auf dem vorherigen Bild im Empfänger dargestellt. Diese soll nun entpackt werden, damit ich die einzelnen Werte verwenden kann:
Das Ergebnis verwundert mich dann doch sehr:
Das sieht so aus, als wären die Daten nicht als Liste, sondern als String übertragen worden. Index 0 gibt das letzte Zeichen „]“ aus, Index 1 das erste „[“ und Index 2 das zweite „0“.
Der Versuch den empfangenen String in eine Liste umzuwandeln bleibt auch erfolglos.
Die list() Funktion aus Python habe ich dann versucht:
Erstaunlich ist jedoch, dass die Ausgabe von rx_list leer ist oder ein # enthält (erste Zeile im Display), wärend die daraus extrahierten Werte „richtig“ angezeigt werden:
Allerdings ist damit dem Problem nicht bei zu kommen. Hier macht die typlosigkeit von Python wohl Probleme.
Der Versuch rx-data zu addieren endet mit einer Fehlermeldung (rotes Kreuz auf dem Display) ohne weiter Informationen.
Wenn rx_data aber vorher in ein Integer umgewandelt wird funktioniert die Addition und es wird die 2 im Display angezeigt.
Damit ist klar, der Wert wird immer als String gesendet! Und die Konvertierung in eine Liste funktioniert nicht. Nun ist guter Rat teuer. Mit Stringverarbeitung möchte ich mich hier nur ungern abgeben. Dauert lange und braucht viel RAM.
Das hätte ich viel einfacher haben können:
espnow.send(id=1, data=str(send_data))
So steht es im Micropython Code.
Trotz Brille
Diesen Block habe ich glatt übersehen.
Ins Programm eingefügt:
Und …
Das sieht doch schon besser aus. Die einzelnen Werte sind nun richtig getrennt. Aber die Klammern stören noch und es sind Leerzeichen enthalten.
Wie erwartet führt dieser Versuch zu einer Fehlermeldung, weil nicht numerische Zeichen enthalten sind. Also bleibt nur noch die Klammern und Leerzeichen gezielt zu entfernen.
Die Zeile
espnow.send(id=1, data=str(send_data))
bringt mich auf eine andere Idee. Den Micropython mit dem Ausführen Block ohne str() einbauen. Mal sehen ob’s klappt.
Fehlermeldung: „Type should be bytes or string“. Es wäre auch zu schön gewesen.
Also musste ich mich doch mit der Stringmanipulation beschäfftigen. Allerdings war es dann doch nicht schlimm wie ich befürchtet hatte. Zuerst habe ich die eckigen Klammern aus dem String rx_data entfernt. Dann daraus eine Liste erstellt und bei der Gelegenheit gleich die überflüssigen Leerzeichen entfernt. Schließlich erfolgt noch die Umwandlung in Integer oder Float. Damit habe ich die Daten so wie ich sie haben möchte.
Das Programm dazu sieht so aus:
Und die Anzeige zeigt rx_list immer noch nicht an. Die anderen Ausgaben entsprechen den Erwartungen. X-Wert (int), Y-Wert (int) und Batteriespannung (float).
Der Grund für die fehlend Anzeige von rx_list ist vermutlich, dass der Block „LCD ausgeben“ keine Typumwandlung von list zu String vornimmt. Das baue jetzt mal ins Programm ein.
… das war’s:
Das Ziel dieses Programms ist aber nicht die Werte anzuzeigen, sondern Servos anzusteuern. Also los auf zur nächsten Runde!
Etwas mit den Daten machen.
Die empfangenen Daten sollen 2 M5Stack 360° Servos als Antrieb für ein kleines LEGO-Fahrzeug steuern. Deshalb habe ich zuerst ausprobiert wie die Servoansteuerung funktioniert. Dazu habe ich ein kleines Gestell mit LEGO Steinen gebaut an dem die 360° und 180° Servos befestigt sind.
Links befinden sich die beiden 360° Servos und rechts die 180° Servos. Der M5Stick C mit dem Servos Hat ist in derMitte zu sehen.
Das ist mein erstes Programm zum Servotesten:
Programm mit Servoansteuerung
Zur Servoansteuerung wurden nur die 4 Blöcke „set servos rotate“ hinzugefügt. Wenn man vorher am Servos Hat den kleinen Schalter auf ON stellt klappt’s dann mit den Servos.
Vorher musste ich die empfangen Daten aber noch aufbereiten. Die Servoansteuerung erfolgt mit Ganzzahlwerten zwischen 0 und 180. Bei den Servos ist also 90 die Grundstellung bzw. der Motorstillstand. Das ist ein Anlass die Übertragung von Wertung zwischen -100 und +100, die ich im Moment im Sender implementiert habe zu überdenken. Das hat aber noch Zeit. Zuerst soll alles zuverlässig funktionieren. Dann kann ich an Modifikationen denken.
Der Wert muss dem Servo nur einmal übermittelt werden. Er bleibt dann solange eingestellt bis ein neuer Wert übermittelt wird.
Das erste Testprogramm wertet nur die X-Achse aus und schickt diesen Wert zu allen 4 Servos. Die 180° Servos bewegen sich dabei parallel, die 360° drehen hingegen entgegengesetzt.
XY zu 2X
Die Überschrift dieses Kapitels sieht nach Mathe aus und ist es auch. Vom Sender kommen Werte für die X- und Y-Achse. Wenn aber keine normale Steuerung wie sie im Kfz üblich ist eingesetzt wird, sondern 2 Motoren parallel laufen, dann müssen diese unterschiedlich schnell drehen um eine Kurve zu fahren. Diese Aufgabenstellung gibt es auch in der Fliegerei bei Flugzeugen mit V-Leitwerk.
Nach einigen Überlegungen und Versuchen bin ich zu folgender Lösung gelangt. Die X- und Y-Werte werden für den einen Motor addiert und für den anderen subtrahiert. Dann sind noch einige Anpassungen erforderlich und schon passt es.
Nun noch die detailierteren Erklärungen:
Hauptprogramm
Das Hauptprogramm enthält hier die wesentlichen Teile des Code.
Setup
Im Setupteil wird zuerst das Display eingerichtet. Anschließend mit dem „Add peer“ Block ESP Now eingerichtet. Im zweiten „Add Peer“ Block wird die MAC Adresse des Senders eingetragen, damit der Empfänger Daten zum Sender schicken kann, z.B. Batterie ist schwach. Diese Funktion ist noch nicht implementiert. Die Variable rx_flag signalisiert dem Hauptprogramm wenn neue Daten eingetroffen sind. Deshalb erstmal auf 0 – keine neuen Daten gesetzt. Schließlich wird die RGB-LED auf dem Servos Hat in grün eingeschaltet.
Loop
In der Loop wird zuerst nachgeschaut ob Post (neue Daten) eingetroffen sind. Wenn nicht hat sie nichts zu tun und langweilt sich.
Wenn aber neue Daten vorhanden sind, also rx-flag = 1 ist, wird zuerst die RGB-LED auf rot gesetzt, das signalisiert neue Daten werden bearbeitet.
Die weiteren Abschnitte werden gleich erklärt.
Am Ende des aktiven Abschnittes wird rx-flag wieder auf 0 gesetzt und die RGB-LED wird wieder grün.
Nun zu den übersprungenen Abschnitten.
Stringliste entpacken
In Blockly verschickt ESP Now die Daten immer als String. Die Daten wurden im Sender in eine Liste gepackt. Im String wird die Liste nun incl. „[“ und „]“, Leerzeichen und Kommas dargestellt. Daraus müssen nun die Daten herrausgepult werden.
Die ersten beiden Blöcke entfernen die beiden eckigen Klammern. Aus dem übrig gebliebenen String lässt sich nun eine Liste machen. Deren Elemente sind auch Strings und enthalten noch die Leerzeichen. Diese werden mit den nächsten drei Blöcken entfernt. Gleichzeitig werden die Daten noch in integer bzw. float bei der Batteriespannung umgewandelt. Nun liegen die Daten so vor, dass sie weiterverarbeitet werden können.
XY Mischen
Hier werden die Geschwindigkeitswerte für die beiden Motoren errechnet von -100 … +100 auf 0 … 100 angehoben.
Bereichsanpassung
Nun wird noch die Drehrichtung angepasst und auf den Bereich 0 – 180 skaliert.
Anzeige
Eine Anzeige ist im Empfänger nicht wirklich erforderlich. Ich habe sie für Programmentwicklung benötigt. Diesen Teil kann man entfernen, oder sie den eigenen Bedürfnissen anpassen.
Empfangsroutine
Der Empfang der ESP Now Daten geschieht im Hintergrund. Da braucht man nichts zu programmieren. Allerdings muss bekannt sein, wo die MAC-Adresse des Absenders und die Daten gespeichert werden sollen. Die entsprechenden Variablennamen müssen „Receive“ Block eingetragen werden. Wenn Daten empfangen wurden, wird das darunter eingetragene Programm abgearbeitet (Interrupt Service Routine oder callback genannt). Hier wird nur geprüft, ob die Daten vom zugeordneten Sender kommen und eine Flagge (rx_flag) gehisst, die dem Hauptprogramm mitteilt, das es nun Daten verarbeiten muß.
Bei der MAC-Adresse die zu prüfen ist muss beachtet werden, das diese im 1 kleiner ist als die mit dem entsprechenden Block abgefrage MAC-Adresse.
Notaus
Bei meinen Experimenten ist es häufiger vorgekommen, dass die Servos nicht mehr abgeschaltet werden konnten, weil die Skalierung nicht stimmte. Deshalb habe ich mit der Taste A einen Notaus eingebaut.
Das Programm ist so wie es jetzt ist einsetzbar. Ich werde aber später noch den Rückkanal implementieren, der Statusdaten des Mobils an den Sender schickt.
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