Grund war also der deep sleep, der während make install einfach dafür sorgt, dass der Hahn zugedreht wird und nichts mehr geht!
Mögliche Gegenmaßnahmen:
make install löschen, z.B. mit make format-flash oder als Option beim flashen der Firmware “erase during update” oder per FTPDu solltest auch mit Ctrl - c den Code vorher anhalten können. Das macht die Übertragung sowieso einiges stabiler.
Wo muss ich dafür sein? In der REPL oder rshell?
Gute Frage weiß jetzt gar nicht wie ich in der WSL Sandbox mit der repl ins aktuelle logging hin komme, es sei denn ich habe gerade frisch aufgespielt.
make connect
Vielleicht.
In Atom einfach auf das aktive logging und dann strg c.
Benutze aktuell Atom und die Sandbox zusammen (proggen in Atom aufspielen in WSL). Klappt prima, werde heute Abend Mal eine Anleitung dazu schreiben.
Vielen Dank für die Meldung, wir konnten das Verhalten bei uns ebenfalls schon erleben. Wir haben uns kurzzeitig beholfen, indem wir entweder a) die Firmware per CTRL+C aus der REPL-Shell heraus angehalten haben, wie @MKO vorschlägt oder b) die Schlafdauer hochgestellt oder deep sleep kurzzeitig ganz abgestellt haben.
Wir versuchen, uns bei der nächsten Softwareiteration um eine komfortablere Lösung des Problems zu kümmern.
Das funktioniert im Linux-System unter Windows (WSL) nicht:
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make install-pycom-firmware
wget --no-clobber --unlink --output-document=./dist-firmwares/FiPy-1.20.0.rc11.tar.gz https://software.pycom.io/downloads/FiPy-1.20.0.rc11.tar.gz | true
--2019-07-19 11:57:29-- https://software.pycom.io/downloads/FiPy-1.20.0.rc11.tar.gz
Resolving software.pycom.io (software.pycom.io)... 18.195.202.40
Connecting to software.pycom.io (software.pycom.io)|18.195.202.40|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1171395 (1.1M) [application/octet-stream]
Saving to: ‘./dist-firmwares/FiPy-1.20.0.rc11.tar.gz’
./dist-firmwares/FiPy-1.20.0. 100%[=================================================>] 1.12M 1.93MB/s in 0.6s
2019-07-19 11:57:30 (1.93 MB/s) - ‘./dist-firmwares/FiPy-1.20.0.rc11.tar.gz’ saved [1171395/1171395]
Install Pycom firmware "FiPy-1.20.0.rc11.tar.gz" on the device connected to "/dev/ttyS16" [y/n]?
Installing firmware FiPy-1.20.0.rc11.tar.gz
/bin/sh: 5: --verbose: not found
tools/pycom.mk:48: recipe for target 'install-pycom-firmware' failed
make: *** [install-pycom-firmware] Error 127
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# cd tools
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware/tools# ls
clean.rshell micropython.mk reset.rshell upload-all.lftprc upload-sketch.rshell
core.mk pycom.mk setup.mk upload-framework.rshell upload-terkin.rshell
help.mk release.mk terkin.py upload-ratrack.rshell
Merci Clemens.
Er findet vermutlich wie erwartet die pycom-fwtool-cli.exe nicht. Das kann drei Gründe haben, die sich nicht ausschließen.
$(eval pycom_fwtool_cli_windows := c:\\Program\ Files\ (x86)\\Pycom\\Pycom\ Firmware\ Update\\pycom-fwtool-cli.exe)
[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/master/tools/pycom.mk#L5
Es wäre spitze wenn Du das überprüfen könntest, zumindest 1. und 2., ggf. auch 3. Hier ist in der näheren Umgebung leider kein Windows zu sehen.
Pfad an sich scheint zu passen, bei mir gibt es
C:\Program Files (x86)\Pycom\Pycom Firmware Update\pycom-fwtool.exe
und dort auch
C:\Program Files (x86)\Pycom\Pycom Firmware Update\pycom-fwtool-cli.exeDann vielleicht anders/mehr/besser escapen, evtl. weiß die Suchemaschine was. Vielleicht kann @MKO auch mal drauf sehen. Ansonsten ist es nicht super tragisch, da es dafür ja auch Alternativen gibt, wie das Programm interaktiv zu bedienen. Von dem Makefile Gedöns wird sich eh viel in Luft auflösen, also nicht zu viel Liebesmüh reinstecken – unter Python bekommt man das besser automatisiert.
Wenn Du willst, leg doch ne kleine tools/pycom-fwtool-cli.bat dazu und kapsle darin den Aufruf zum Stiefkind. Das wird meistens im Internet empfohlen, wenn es um solche Dinge geht. Das wäre sinnvoll und vermutlich schneller zu machen, als sich mit der Frage zu beschäftigen, wie man Windows Pfad-Escaping innerhalb eines Makefiles richtig machen kann. Richtig wäre vermutlich am besten: Gar nicht.
Ich schau mir das heute Abend an.
Hab noch einen Recht interessanten Link über Updates direkt via GitHub direkt auf dem Node gefunden, so in der Art können wir uns später bestimmt den ganzen Rattenschwanz sparen, den wir uns jetzt aus der “Not” heraus anhängen.
Gruß Michael
$(eval pycom_fwtool_cli_windows := /mnt/c/Program\ Files\ \(x86\)/Pycom/Pycom\ Firmware\ Update/pycom-fwtool-cli.exe)
sollte richtig sein.
Leider funktioniert es immer noch nicht.
Der Com Port meckert.
user@Werkstatt:/mnt/c/test/hiveeyes-micropython-firmware$ make install-pycom-firmware
wget --no-clobber --unlink --output-document=./dist-firmwares/FiPy-1.20.0.rc11.tar.gz
https://software.pycom.io/downloads/FiPy-1.20.0.rc11.tar.gz | true
File ‘./dist-firmwares/FiPy-1.20.0.rc11.tar.gz’ already there; not retrieving.
Install Pycom firmware "FiPy-1.20.0.rc11.tar.gz" on the device connected to "/dev/ttyS8" [y/n]?
Installing firmware FiPy-1.20.0.rc11.tar.gz
Invalid serial port /dev/ttyS8! Use list command to show valid ports.
tippe mal da die pycom-fwtool-cli.exe ein Windows-Tool ist will sie den echten COM-Port und nicht den gemappten, wie er für die WSL passt.
kenne mich jetzt leider nicht mit .mk Files aus wie man dort Strings bearbeiten kann. Man müßte jetzt bei Windows alle Zeichen bis auf die zahlen aus /dev/ttyS8 entfernen und COM davor schreiben.
wenn ich von vorne rein
export MCU_SERIAL_PORT=COM8
mache geht es übrigens nicht. Denke mal der Porttyp wird dann nicht erkannt
Hab es denke ich hin bekommen. Einfacher als gedacht.
pycom_firmware_port :=$(subst /dev/ttyS, COM, $(mcu_port))
Pull request ist raus.
Hi Michael,
danke dass Du da Zeit reinstecken konntest um die Probleme bei der hemdsärmligen Basisimplementierung zu erkennen und dass Du den ausgezeichneten Patch bei Make "make install-pycom-firmware" work on Windows by MKO1640 · Pull Request #15 · hiveeyes/terkin-datalogger · GitHub zur Verfügung gestellt hast, um die entsprechenden Stellen aufzumöbeln.
Note to self: Wir sind hier wie gewünscht im Kontext des WSL unterwegs und müssen dabei natürlich beim Zusammenstecken der Einzelteile berücksichtigen, dass es jenseits der Grenze des gelobten Landes gerade bei der Adressierung von Betriebssystemressourcen anders zugeht - Andere Länder — andere Sitten. Das hatten wir bei der Basisimplementierung gar nicht entsprechend berücksichtigt.
So true. Thanks.
Thanks for spotting this!
pycom_firmware_port :=$(subst /dev/ttyS, COM, $(mcu_port)) berechnet nun die richtige serielle Schnittstelle für die entsprechende Adressierung des Geräts aus der Perspektive des nativen Windows-Subsystems und die Variable $(pycom_firmware_port) leitet diese Information nun überall dorthin weiter, wo $(pycom_fwtool_cli) tatsächlich verwendet wird. Daher wird nun vermutlich auch "make chip_id", "make format-flash" sowie "make erase-fs" ebenso unter Windows funktionieren. Perfekt.
Vielen Dank fürs richtig rum aufs Pony setzen, Michael.
Herzliche Grüße,
Andreas.
Wie muss denn der COM-Port jetzt angegeben werden?? Alte Methode funktioniert nicht (meht):
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# export MCU_PORT=/dev/ttyS16
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make list-boards
Device port: usb => /dev/ttyS16
failed to access /dev/ttyS16
tools/micropython.mk:15: recipe for target 'list-boards' failed
make: *** [list-boards] Error 1
Neue auch nicht, die wird COM16 als IP interpretiert:
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# export MCU_PORT=COM16
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make list-boards
Device port: ip => COM16
failed to access COM16
tools/micropython.mk:15: recipe for target 'list-boards' failed
make: *** [list-boards] Error 1Das signalisiert, dass das Sandbox-Tooling denkt, es wäre ein IP-basierter Port. Das könnte hier die Ursache sein und man müsste die Erkennung entsprechend nachziehen. Es muss allerdings nicht so sein: Vielleicht ist das in Wahrheit kein Problem und der Fehler liegt woanders.
git pull und make setup habe ich vorher gemacht
Über git log kannst Du Dir die Historie ansehen und per git checkout <commitref> lokal zu einem älteren Versionsstand zurückkehren.
In Ausnahmefällen – je nach den Umständen – kann auch in solchen Situationen ein darauf folgendes make setup notwendig sein.
git checkout f1431f4a7e9da08363741aeef64cf18a9ac3848f
make setup
export MCU_PORT=/dev/ttyS16
make list-boards
Connecting via port type usb
Using buffer-size of 2048
Connecting to /dev/ttyS16 (buffer-size 2048)...
failed to access /dev/ttyS16
tools/micropython.mk:37: recipe for target 'list-boards' failed
make: *** [list-boards] Error 1
grad völlig aufgeschmissen
list-boards hat mit den kürzlichen Updates für Windows hinsichtlich pycom-fwtool-cli.exe überhaupt nichts zu tun, nur mit der rshell – das heißt: Reines Python Umfeld, bei Dir vermutlich innerhalb von WSL betrieben.
## List all MicroPython boards
list-boards: check-mcu-port
@$(rshell) $(rshell_options) boards
@echo
Obacht wenn Du zu weit zurück gehst. Die Umstellung auf MCU_PORT erfolgte erst kürzlich, ca. bei 43568c5df96. Vorher hieß es MCU_SERIAL_PORT.
Die wichtigste Frage: Ging das überhaupt schon einmal auf Windows?
Auf meiner Workstation (macOS) sieht es mit dem aktuellsten Entwicklungsstand ungefähr folgendermaßen aus:
$ export MCU_PORT=/dev/cu.usbmodemPy001711 # libero
$ make list-boards
Device port: usb => /dev/cu.usbmodemPy001711
> pyboard @ pyboard connected Epoch: 1970 Dirs: /flash /pyboard/flash
Der COM-Port hatte sich aufgehängt, war also kein Software-Problem!