Geht Upload/Flash von Pico mit MicroPython Files auch schneller?

Python auf Einplatinencomputer wie Raspberry Pi, Banana Pi / Python für Micro-Controller
Antworten
MainzerKaiser
User
Beiträge: 14
Registriert: Mittwoch 5. Januar 2022, 08:59

Hallo,

ich habe auf meinem Raspberry Pi mit der IDE Pycharm eine GUI programmiert, die ich über ein Touchdisplay verwende. Das GUI Programm flasht dann eine in Micropython geschriebene main.py auf einen PICO, welcher eine LED Leiste ansteuert.

Code: Alles auswählen

self.p=QProcess()
self.p.setProgram("/usr/bin/python3.7")
self.p.setArguments(["/home/pi/.local/share/JetBrains/PyCharmCE2021.2/intellij-micropython/scripts/microupload.py",\
    "-C", "/home/pi/PycharmProjects/LEDStripPico",\
    "-v", "/dev/ttyACM0", "/home/pi/PycharmProjects/LEDStripPico/main.py"])
self.p.start()
Im Terminal erscheint dann diese Meldung, die besagt, dass die main.py erfolgreich upgeloaded wird und ich sehe auch das Ergebnis an meiner LED Leiste.

Code: Alles auswählen

Connecting to /dev/ttyACM0
Uploading files: 0% (0/1)
/home/pi/PycharmProjects/LEDStripPico/main.py -> main.py
Uploading files: 100% (1/1)
Soft reboot
Vorher habe ich das ganze ohne PICO über das GPIO interface geregelt, was ich in diesem Forum auch schon mal hier beschrieben habe.

Ich wollte weg vom GPIO, weil ich die Leiste später in 1-2m Entfernung vom Pi steht und ein USB Kabel zur Verbindung plausibel erscheint.


Nur ist die PICO Lösung im Vergleich jetzt etwas langsamer (>1s statt ca 0.5s). Der Bottleneck scheint die Verbindung mit dem USB Device und der Upload zu sein.


Habt ihr Erfahrung damit, das Ganze zu beschleunigen? Gibt es hard-gecodete Wartezeiten von x Millisekunden beim Pico, die man umschreiben kann? Ich meine gelesen zu haben, dass diese manchmal eingerichtet werden um beim booten zu checken ob der button auf dem Microcontroller gedrückt wird.


Ist die Idee mit GUI + main.py flashen vielleicht nicht richtig zu Ende gedacht?
__deets__
User
Beiträge: 14545
Registriert: Mittwoch 14. Oktober 2015, 14:29

Das ist eine eher ungewöhnliche Idee. Der normale Ansatz Bestände darin, im Pico bzw in Micropython einfach per serieller Schnittstelle via USB die neuen LED-Kommandos entgegenzunehmen. Und dann dauert das Bruchteile von Sekunden. Die kann man dann auch problemlos in einer Datei speichern, Äquivalent zur Python Datei.

Einen Weg, dein Vorgehen zu beschleunigen, kenne ich nicht. Das hat aber auch wenn eher was mit micropython und wie das es erlaubt, ein Programm abzubrechen, zu tun. Das ist tatsächlich eher langsam, aber daran zu schrauben riskant. Denn uU sperrst du dich dann ganz aus.
MainzerKaiser
User
Beiträge: 14
Registriert: Mittwoch 5. Januar 2022, 08:59

Danke! Betrete gerade mit jeder Idee Neuland und rein durch das Googlen von "Pico serial connection" finde ich da einige Hinweise.
https://medium.com/geekculture/serial-c ... c0ba97c7dc
Man muss halt auf die Idee kommen, danach zu googlen ;-)
__deets__
User
Beiträge: 14545
Registriert: Mittwoch 14. Oktober 2015, 14:29

Das ist ein gangbarer Weg. Ich selbst würde eher das uselect Modul nutzen, so wie hier: https://forums.raspberrypi.com/viewtopic.php?t=313288
Benutzeravatar
Dennis89
User
Beiträge: 1376
Registriert: Freitag 11. Dezember 2020, 15:13

Oh hätte ich gewusst, dass du hier die gleiche Frage stellst.

https://forum-raspberrypi.de/forum/thre ... post522990
"When I got the music, I got a place to go" [Rancid, 1993]
MainzerKaiser
User
Beiträge: 14
Registriert: Mittwoch 5. Januar 2022, 08:59

Doppelt hält besser?! Wusste nicht, dass sich die Nutzerplattformen überlappen.
__deets__
User
Beiträge: 14545
Registriert: Mittwoch 14. Oktober 2015, 14:29

Öh, das ist aber doch in deinem ersten thread angesprochen worden: viewtopic.php?t=53774 -wieso ist das jetzt eine Überraschung?

Doppelt hält besser ist auch doppelt gemoppelte Arbeit für mehr Leute, egal ob die sich überlappen. Kann man das verhindern? Nein. Aber es kann durchaus dazu führen, dass jemand sagt: dir helfe ich hier nicht mehr, du bekommst ja schon woanders Hilfe.
MainzerKaiser
User
Beiträge: 14
Registriert: Mittwoch 5. Januar 2022, 08:59

Ihr habt schon Recht, dann lasse ich die doppelten Posts in Zukunft sein.

Wahrscheinlich meinst Du diesen Beitrag zu Picos als Slaves eines Pi-Servers https://github.com/tom-2015/rpi-ws2812-server
Das sieht mir mit meine limitierten Python Kenntnissen doch aus wie ein overkill für meine Zwecke. Eine WLAN Lösung wäre hier auch zu komplex.
__deets__
User
Beiträge: 14545
Registriert: Mittwoch 14. Oktober 2015, 14:29

Wenn man da einen ESP irgendeiner Form ins Spiel bringt, braucht man keinen Pico mehr.

Edit: so hat Dennis das ja auch kommuniziert.


Und ich habe jetzt nicht die gesamte Kommunikation im Pi Forum gelesen, aber sorge, dass es wegen Kabellängen zu Verzögerungen kommt, muss man nicht haben.

Ab einer bestimmten Länge kann es zu Verbindungsproblemen kommen. Bei USB 5m oder so.
MainzerKaiser
User
Beiträge: 14
Registriert: Mittwoch 5. Januar 2022, 08:59

Hallo,
hier mal ein Update zur Nutzung von serial und _thread für meine Anwendung wenn man nicht immer ein main.py booten möchte: https://forums.raspberrypi.com/viewtopic.php?t=331255
Das multithreading ist für den Pico anscheinend noch nicht ausgereift. Ich hatte die Hoffnung, dass es einfacher geht, aber da beißen sich gerade einige die Zähne aus.

Die Serverlösung erscheint mir trotz aller bisher versenkten Stunden immernoch als Overkill. Ich denke, dass die Server/Slave Anbdindung für eine schnelle Bedienung per GUI auf dem Pi nicht geeignet ist. Eine gute Anleitung habe ich auch nicht gefunden.
__deets__
User
Beiträge: 14545
Registriert: Mittwoch 14. Oktober 2015, 14:29

Ich weiß jetzt nicht, was du mir sever Lösung meinst. Aber uselect hat nix mit threads zu tun, ebensowenig asyncio. Und das ist auch lange in Nutzung.
MainzerKaiser
User
Beiträge: 14
Registriert: Mittwoch 5. Januar 2022, 08:59

Als Server/Slave Lösung wurde ja dieses vorgeschlagen https://github.com/tom-2015/rpi-ws2812-server
Was mich abschreckt sind PHP Server, TCP Sockets und die Tatsache, dass das Ganze in C daher kommt. Bisher ist mein Eindruck, dass das doch einfacher gehen muss.

Uselect kannte ich bisher auch noch nicht. Scheinbar wird mir das ja vorgeschlagen, weil ich so auch während des Betriebs von main.py trotzdem parallel lesen kann, ob ein Character vom Pi kommt, e.g. 0 für Stoppen oder 1 für NeuStart. Die Frage zielt darauf ab, ob ich überhaupt einen Multithreading-Ansatz brauche für meinen Zweck.

Kennt ihr schon Anwendungen/Tutorials für Asyncio und uselect? Aber eben bei Nutzung eines Pis, der per USB Signale an einen Pico sendet, auf dem die LED Leisten 99% der Zeit in Endlosschleifen laufen?

Ich bin für jede Idee dankbar!
__deets__
User
Beiträge: 14545
Registriert: Mittwoch 14. Oktober 2015, 14:29

Auf einem Pi hast du wiederum deine Threading Probleme nicht. Das Projekt war ja auch vorgeschlagen mit der Idee, dass es einfach nutzbar ist, wie es ist. Dann spielt es doch keine Rolle, worin das programmiert wurde. Den Eindruck, das programmieren einfach ist, kann ich nicht so ganz nachvollziehen. Einfach Tätigkeiten werden eher selten mit hohen, fast sechsstelligen Gehältern belohnt.

Was uselect angeht: im uPy Forum finden sich Informationen, zb https://forum.micropython.org/viewtopic.php?t=1741
MainzerKaiser
User
Beiträge: 14
Registriert: Mittwoch 5. Januar 2022, 08:59

Hallo zusammen,
die uselect.poll Lösung aus dem verlinkten Forum funktioniert. Ich habe meinen code auch dort gepostet, falls hier jemand landet und das testen möchte:
https://forums.raspberrypi.com/viewtopi ... 3#p1984593
Vielen Dank für eure Hilfe!
Antworten