Running rshell natively on Windows

Andreas · April 12, 2019, 9:39am

Hintergrund

Wegen make recycle freezes und finding the appropriate serial port wollen wir schauen, ob die Schwummse vielleicht nicht auch nativ auf Windows laufen kann.

Introduction

The contributions around Not Windows Compatible · Issue #17 · dhylands/rshell · GitHub and Add Windows compatibility. by ccooper21 · Pull Request #38 · dhylands/rshell · GitHub made rshell Windows-compatible and it looks like it is actually working for some users:

In the light of Unstable serial port communication on Windows 10, it would be cool if some Windows users of our community would give this a try:

Can you find some time to try this on your machine, @tonke or @clemens?

Setup

I could imagine this would work most easily like

Install the Chocolatey package manager, see https://chocolatey.org/install.
Install Python3 and the Python rshell package
```
choco install python3
pip install rshell
```

Checks

In order to verify this actually works, these commands would be the proper way to start:

# Enumerate list of serial interfaces.
rshell --list

# Attempt board communication on designated serial interface.
rshell --port COM3 boards

clemens · April 12, 2019, 3:26pm

Again some ??? what we / I should do here? I have problems on the Linux system on Win10. The serial communication is “unstable” or let’s say make setup or make recycle has sometimes problems to access the device. Are yu refering to this problem or is it an other?

Chocolatey is a manager under Win, not on the Linux system. So what is the goal? To switch from the Linux Subsystem to Windows? Again: Lost without more information!

Andreas · April 12, 2019, 3:43pm

That was meant by calling this “natively”, right. Please feel free to adjust the wording as appropriate.

clemens · April 12, 2019, 7:22pm

C:\WINDOWS\system32>choco install python3

worked but

C:\WINDOWS\system32>pip install rshell
Der Befehl “pip” ist entweder falsch geschrieben oder
konnte nicht gefunden werden.

Andreas · April 12, 2019, 8:03pm

Schade! Muss aber dabei sein. Evtl. mal pip3 probieren oder ansonsten auf die Suche gehen. Evtl. ist C:\ProgramData\chocolatey\lib\python3\tools der richtige Ort.

You are right, I’m not used to Python on Windows and I didn’t noticed pip.exe in the Python folder.
– Chocolatey Software | Python 3.x 3.7.3

Alternativ:

python -m pip install rshell

clemens · April 12, 2019, 8:11pm

Ja, pip3 install rshell funktioniert!

Successfully installed pyreadline-2.1 pyserial-3.4 pyudev-0.21.0 rshell-0.0.21 six-1.12.0

clemens · April 12, 2019, 8:13pm

C:\Users\mail>rshell --list
USB Serial Device 04d8:ef98 with vendor 'Microchip Technology, Inc.' serial 'PYDB06DB' found @COM16

Schaut gut aus!
und:

C:\Users\mail>rshell --port COM16 boards
Using buffer-size of 32
Connecting to COM16 (buffer-size 32)...
Trying to connect to REPL ... connected
Testing if ubinascii.unhexlify exists ... Y
Retrieving root directories ... /flash/
Setting time ... Apr 12, 2019 22:13:47
Evaluating board_name ... pyboard
Retrieving time epoch ... Jan 01, 1970
pyboard @ pyboard connected Epoch: 1970 Dirs: /flash /pyboard/flash

Andreas · April 12, 2019, 9:31pm

Einleitung

Exzellent, darauf könnte man aufbauen. Allerdings strotzt das Makefile derzeit nur so vor Verwendung von GNU Software, die man ja nativ unter Windows erst einmal nicht hat. Sobald manches davon ordentlich in Python implementiert und damit plattformneutraler unterwegs ist, könnte man hier umschwenken.

Nächste Schritte

Um herauszufinden, ob die Kommunikation damit stabiler läuft als via WSL, siehe Unstable serial port communication on Windows 10, könntest Du einstweilen versuchen, direkt manuell per rshell zu arbeiten, Dinge wie make recycle bestehen schließlich aus nichts anderem. Konkret am Beispiel also:

Abhängigkeiten installieren

Damit wird der Ordner dist-packages auf das Gerät geladen.

rshell --port COM16 mkdir /flash/dist-packages
rshell --port COM16 rsync dist-packages /flash/dist-packages

Framework installieren

Damit werden die Ordner terkin und hiveeyes auf das Gerät geladen.

rshell --port COM16 --file tools/upload-requirements.rshell

Programm installieren

Damit werden lib/, boot.py, main.py und settings.py auf das Gerät geladen und anschließend ein machine.reset() ausgelöst.

rshell --port COM16 --file tools/upload-sketch.rshell

clemens · April 12, 2019, 11:28pm

Bleibt leider – wie unter Linux – hier schon hängen

C:\Users\mail>rshell --port COM16 mkdir /flash/dist-packages
Using buffer-size of 32
Connecting to COM16 (buffer-size 32)...
Trying to connect to REPL ............. connected
Testing if ubinascii.unhexlify exists ...

bzw.

C:\Users\mail>rshell --port COM16 rsync dist-packages /flash/dist-packages
Using buffer-size of 32
Connecting to COM16 (buffer-size 32)...
Trying to connect to REPL ....... connected
Testing if ubinascii.unhexlify exists ... b'\n>>> \r\n>>> \r\n>>> \r\n>>> \r\n>>> \r\n>>> \r\n>>> \r\n>>> \r\n>>> '
Traceback (most recent call last):
  File "c:\python37\lib\site-packages\rshell\main.py", line 1255, in connect
    ip_address = socket.gethostbyname(port)
socket.gaierror: [Errno 11001] getaddrinfo failed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python37\Scripts\rshell-script.py", line 11, in <module>
    load_entry_point('rshell==0.0.21', 'console_scripts', 'rshell')()
  File "c:\python37\lib\site-packages\rshell\command_line.py", line 4, in main
    rshell.main.main()
  File "c:\python37\lib\site-packages\rshell\main.py", line 2843, in main
    real_main()
  File "c:\python37\lib\site-packages\rshell\main.py", line 2805, in real_main
    connect(args.port, baud=args.baud, wait=args.wait, user=args.user, password=args.password)
  File "c:\python37\lib\site-packages\rshell\main.py", line 1261, in connect
    connect_serial(port, baud=baud, wait=wait)
  File "c:\python37\lib\site-packages\rshell\main.py", line 1285, in connect_serial
    dev = DeviceSerial(port, baud, wait)
  File "c:\python37\lib\site-packages\rshell\main.py", line 1565, in __init__
    Device.__init__(self, pyb)
  File "c:\python37\lib\site-packages\rshell\main.py", line 1339, in __init__
    unhexlify_exists = self.remote_eval(test_unhexlify)
  File "c:\python37\lib\site-packages\rshell\main.py", line 1459, in remote_eval
    return eval(self.remote(func, *args, **kwargs))
  File "c:\python37\lib\site-packages\rshell\main.py", line 1437, in remote
    self.pyb.enter_raw_repl()
  File "c:\python37\lib\site-packages\rshell\pyboard.py", line 187, in enter_raw_repl
    raise PyboardError('could not enter raw repl')
rshell.pyboard.PyboardError: could not enter raw repl

und C:\Users\mail>rshell --list geht jetzt auch nicht

… device nochmal ab- und wieder angesteckt. rshell --list geht nun wieder …
… nächster Versuch:

C:\Users\mail>rshell --port COM16 mkdir /flash/dist-packages
Using buffer-size of 32
Connecting to COM16 (buffer-size 32)...
Trying to connect to REPL ........... connected
Testing if ubinascii.unhexlify exists ... Y
Retrieving root directories ... /flash/
Setting time ... Apr 13, 2019 01:37:57
Evaluating board_name ... pyboard
Retrieving time epoch ... Jan 01, 1970
Traceback (most recent call last):
  File "C:\Python37\Scripts\rshell-script.py", line 11, in <module>
    load_entry_point('rshell==0.0.21', 'console_scripts', 'rshell')()
  File "c:\python37\lib\site-packages\rshell\command_line.py", line 4, in main
    rshell.main.main()
  File "c:\python37\lib\site-packages\rshell\main.py", line 2843, in main
    real_main()
  File "c:\python37\lib\site-packages\rshell\main.py", line 2826, in real_main
    shell.cmdloop(cmd_line)
  File "c:\python37\lib\site-packages\rshell\main.py", line 1689, in cmdloop
    stop = self.onecmd(line)
  File "c:\python37\lib\site-packages\rshell\main.py", line 1722, in onecmd
    self.onecmd_exec("".join(group))
  File "c:\python37\lib\site-packages\rshell\main.py", line 1733, in onecmd_exec
    return cmd.Cmd.onecmd(self, line)
  File "c:\python37\lib\cmd.py", line 217, in onecmd
    return func(arg)
  File "c:\python37\lib\site-packages\rshell\main.py", line 2346, in do_mkdir
    if not mkdir(filename):
  File "c:\python37\lib\site-packages\rshell\main.py", line 786, in mkdir
    return auto(make_directory, filename)
  File "c:\python37\lib\site-packages\rshell\main.py", line 586, in auto
    return dev.remote_eval(func, dev_filename, *args, **kwargs)
  File "c:\python37\lib\site-packages\rshell\main.py", line 1459, in remote_eval
    return eval(self.remote(func, *args, **kwargs))
  File "c:\python37\lib\site-packages\rshell\main.py", line 1439, in remote
    output = self.pyb.exec_raw_no_follow(func_src)
  File "c:\python37\lib\site-packages\rshell\pyboard.py", line 240, in exec_raw_no_follow
    raise PyboardError('could not exec command')
rshell.pyboard.PyboardError: could not exec command

Andreas · April 13, 2019, 10:26am

Sehr schade! Einmalig wäre kein Problem: Hin und wieder komme ich auch in einen Zustand, aus dem ich nur durch power-cycle wieder herauskomme. Wenn es allerdings auch laufend bei mehreren Iterationszyklen in >20% der Fälle auftritt, haben wir dadurch natürlich nichts gewonnen und müssen weiterhin Windows oder rshell verdammen.

Gedanken

Stabil machbar müsste es ja irgendwie sein? Die Referenz ist eindeutig die Arduino IDE, die Artefakte aus C-Code ja auch ordentlich flashen kann und esptool selbst ist doch auch unter Windows stabil, nicht?

Bemerkung: Letzteres hat allerdings auch den software flasher stub an Bord, der in C geschrieben ist. Dieser ist speziell hinsichtlich des Umgangs mit den ESP MCUs vermutlich ausgereifter als das, was anderswo in rshell oder generell dem MicroPython Toolstack für ESP zu finden ist.

Seitenblicke

Nichtmal die IDE Integration des MicroPython Universums scheint stabil unter Windows zu sein. @tonke hat damit auch weiterhin regelmäßige Hänger.

clemens · April 13, 2019, 10:40am

Nur so eine Idee: Bei den PyCom-devices fährt ja auch ein kleines OS hoch. Kann es damit zusammen hängen, dass es unter bestimmten Bedingungen nicht “hört” und ggf. gar nichts mit der pysikalischen Schnittstelle zu tun hat? Bzw. erst getriggert werden muss, dass es hört?

tonke · April 13, 2019, 10:55am

Ja das habe ich auch ab und an. Dann hilft nur ein beherzter Druck auf den “reset switch” am Fipy selber.
https://docs.pycom.io/.gitbook/assets/specsheets/Pycom_002_Specsheets_FiPy_v2.pdf

Andreas · April 15, 2019, 2:02am

Ich vermute, dass der FiPy während der Kommunikation versehentlich einen Reset auslöst und dadurch währenddessen aufhört, zu “hören”.

Ja, Stecker raus Stecker rein ist in dem Fall das pragmatischste.

Firmware upgrade revisited

@clemens: Ich hatte das früher durchaus auch häufiger (ist wirklich nervig!), mit der aktuellen Pycom Firmware 1.20.x [development] jedoch kaum mehr.

MicroPython-Firmware schmirgeln (150er)

Running on 1.20.0.rc8
================================
BOB MicroPython Datalogger 0.2.1
================================
CPU freq     160.0 MHz
Device id    807d3ac262bc


Python  : 3.4.0
lorawan : 1.0.2
machine : FiPy with ESP32
nodename: FiPy
release : 1.20.0.rc8
sigfox  : 1.0.1
sysname : FiPy
version : v1.9.4-7b83c6d on 2019-03-06
When running on a more recent firmware version, the metadata contains valuable information about the system runtime.

We would appreciate if you could upgrade your firmware .