MicroPython-Firmware schmirgeln (240er)

Das 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

post mortem ;-)

Der COM-Port hatte sich aufgehängt, war also kein Software-Problem!

1 Like

Follow-up: Wie kriegt man den COM-Port auch ohne Neustart wieder flott?

wenn USB-Serielle: USB subsystem neustarten. :)
Aber geht ja um aktuelles Windows/WSL, da kenne ich mich nicht aus, wie die dort ihre hardware abbilden und wrappen.

1 Like

systemctl restart usb?

@clemens berichtete, dass er den Port folgendermaßen wieder flottkriegte:

  • Geht nicht
  • Atom/Pymakr starten
  • Atom/Pymakr beenden
  • Geht wieder

Daher:

  • Vielleicht macht Pymakr ja bereits irgendetwas (anwendungsorientiertes?), um die Schnitte wieder freizukriegen?
  • Vielleicht finden wir hierzu irgendwie einen passenden “Reset-COM-Port-Through-Powershell”-Schnipsel?

make reset-port

all over the place. Auch der neue FTP-Dateitransfermechanismus per "make recycle-ng" (siehe Operate the Terkin-Sandbox using the MicroTerkin Agent - #2 by Andreas) ist leider nicht ganz lupenrein, daher werden wir auch dafür ein "make reset-port" brauchen, wie es bei Makefile: Add RUNNING_IN_HELL flag · hiveeyes/terkin-datalogger@976cab2 · GitHub nun angelegt wurde.

– Meow. – Wie machen eigentlich Yaks?

Die Serielle zickt manchmal unter der Arduino IDE auch rum, dann hilft abstöpseln und anstöpseln, manchmal auch nur IDE schließen und in schweren Fällen Windows Neustart. Heute bin ich nicht drauf gekommen, weil es unter WSL bisher gut geklappt hat und ggf. auch die Fehlermeldung failed to access /dev/ttyS16 vielleicht zu unspezifisch war, oder weil halt Montag …

Wenn sich nun WSL und Windows die Schnittstelle teilen und es schon unter Windwos ab und an Probleme gibt, vielleicht eine Baustelle, die wir nicht lösen können. Für mich sah es im Nachhinein so aus, als ob Atom die Schnittstelle blockiert hat bzw. nicht freigegeben hat.

1 Like
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
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 "  COM16" [y/n]? # Prompt the user for action.

So, nun funktioniert es zumindest, momentan ist aber noch die FiPy-Firmware hard gecoded drinnen, habe gerade einen LoPy auf dem expansion board … das hat Andreas aber auf dem Schirm, zumindest hatten wir vor Tagen mal darüber gesprochen, daher u.a. auch die Abfrage, ob man wirklich möchte und explizite Nennung der Firmware-Version nebst Board für das sie gedacht ist.

Et voilà.

make install-pycom-firmware pycom_firmware_file=LoPy-1.20.0.rc12.tar.gz

Ja, das läuft, cool!! Man kann also den Firmware-Namen der latest and greatest version per parameter mit übergeben, prima!

Top! @Andreas, auch quick connect geht:

root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make connect-wifi ssid="sogar mit space geht" password=123viele
Entering REPL. Use Control-X to exit.
>
Pycom MicroPython 1.20.0.rc12 [v1.9.4-81167ed] on 2019-07-15; LoPy with ESP32
Type "help()" for more information.
>>>
>>> from mininet import MiniNet ; MiniNet().connect_wifi_sta('sogar mit space geht', '123viele')
INFO:  Starting MiniNet
INFO:  WiFi STA: Scanning for networks
INFO:  WiFi STA: Networks found ['DIRECT-xy47" Philips 6158', 'sogar mit space gehr', 'sogar mit space geht Gastzugang', 'FRITZ!Box 7490']
INFO:  WiFi STA: Connecting to "sogar mit space geht"
INFO:  WiFi STA: Connected to "sogar mit space geht"
INFO:  WiFi STA: Network configuration is ('192.168.178.23', '255.255.255.0', '192.168.178.1', '192.168.178.1')
INFO:  Ready.

INFO:  WiFi STA: IP address is 192.168.178.23

Note: Press CTRL+X or Ctrl+] to detach from the REPL

Exzellent ;].

@clemens: Thanks for checking out the new features arrived on master since your last pull the other day. Enjoy the ride and good luck.

Next stop "make recycle-ng"

$ time make recycle-ng

Device port: ip => 192.168.178.61
Uploading MicroPython code to device
lftp -u micro,python 192.168.178.61 < tools/upload-all.lftprc
lftp status: 0
Upload finished
Restart device using the HTTP API [y/n]?
INFO: Restarting device at IP address 192.168.178.61 using HTTP API
SUCCESS: Device restart acknowledged. Please wait some seconds for reboot.
Ready.

real	13m33.126s

To receive desktop notifications from Terkin Pinocchio [1] like outlined within the documentation of the MicroTerkin Agent, please have a look at Setup Terkin Pinocchio desktop notifications.

image

For Windows, this would be pip install zroya into the right environment(s) – eventually both the Windows-native one as well as the virtualenv-sandboxed one – like.

  • conda install zroya
  • .venv3/bin/pip install zroya

Along the lines

I am humbly asking you to verify accurateness of the canonical documentation recently spawned with Operate the MicroTerkin firmware sandbox while walking through the ng-steps you are currently invoking. Both posts over there are Wiki’ed, so you will be able to adjust them as you like.

I know these steps are still somehow involved and will need more pedantic review of their intended functionality as they just recently have been minted. However, we have been to the moon and all we got was this lousy spacesuit ;].

We tried hard to optimize on the naming things side during the most recent iterations along the lines of make help. If you feel we could do better, please drop us a note about a specific thing you would like to rename.

Thanks!


  1. Pinocchio accepts a ride from a dolphin to the nearest island called the Island of Busy Bees. Upon arriving on the Island of Busy Bees, Pinocchio can only get food in return for labor. Pinocchio offers to carry a lady’s jug home in return for food and water. When they get to the lady’s house, Pinocchio recognizes the lady as the Fairy.

    The Adventures of Pinocchio - Wikipedia ↩︎

For anyone wondering: This is not real yet but holds true for

  • lftp://exec => mirror --reverse --delete --use-cache terkin, see also the ng upload macro upload-all.lftprc.
  • Some lousy seconds waiting for the lazy operator to press y+ENTER after being prompted for Restart device using the HTTP API [y/n]?

Läuft unter Win / WSL wieder nicht!

statt make terkin-agent action=monitor mache ich in der Windows PowerShell

PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu\home\cgruber\hiveeyes\sources\hiveeyes-micropython-firmware> python tools/terkin.py monitor
2019-07-22 23:30:56,727 [tools/terkin.py] INFO   : IP networks found: ['192.168.178.0/24']
2019-07-22 23:30:56,727 [tools/terkin.py] INFO   : Discovering devices already connected to IP network 192.168.178.0/24
2019-07-22 23:30:56,727 [tools/terkin.py] INFO   : Waiting for any devices having MAC address prefixes of ['30:ae:a4', '80:7d:3a'] to appear on your local network
2019-07-22 23:30:57,243 [tools/terkin.py] INFO   : Sending ARP ping request to 192.168.178.0/24

Du sagtest, dadurch soll eine Datei angelegt werden, oder war das wo anders?

Make console kann ich ja wieder in WSL machen, mit dem USB-Port als MCU_Port geht das auch

root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make console
Device port: usb => /dev/ttyS16
Connecting via serial port /dev/ttyS16.
.venv3/bin/miniterm.py /dev/ttyS16 115200
--- Miniterm on /dev/ttyS16  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

Nur funktionieren die Tastatur-Shortcuts in WSL überhaupt nicht, komme gar nicht mehr raus, kann nur noch das Fenster komplett schließen.

Firmware updaten geht dann auch nicht, vermutlich weil die IP von terkin-agent action=monitor nirgends gespeichert ist, mache ich vorher:

root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make recycle-ng
Device port: ip => 192.168.178.26
Uploading MicroPython code to device
  File "tools/terkin.py", line 52
    log.info(f'Hostname "{hostname}" found at IP address "{ip_address}"')
                                                                       ^
SyntaxError: invalid syntax
Makefile:174: recipe for target 'install-ng' failed
make: *** [install-ng] Error 1

Warum die IP 192.168.178.26, ist doch die 24 am Ende make recycle-ng 192.168.178.24 wirft aber die gleiche Fehlermeldung aus.

Vielen Dank fürs Testen.


Schade.


Das ist ein Indiz dafür, dass die verwendete Python3-Version zu alt ist oder das Programm gar noch unter Python2 läuft. Das hatten wir doch schonmal bei Dir – nicht?

Mögliche Lösung: Das Gerät innerhalb des WSL per python3 starten, falls dort beide Python-Versionen installiert sind.