Drüben bei Module freezing for Genuine MicroPython gibt es ein paar Probleme mit der REPL bei selbstgebackenen firmware images von Genuine MicroPython v1.12.
Nach dem Aufspielen dieses Images funktioniert leider die Dateiübertragung per rshell nicht mehr:
Welcome to rshell. Use Control-D (or the exit command) to exit rshell.
/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware> cp main.py /pyboard/
timed out or error in transfer to remote
Da kommt eigentlich noch mehr Output, wenn du mit rshell verbindest. War das Board gerade schlafen? Wie ist deine connect Zeile?
Habe mich nur auf das Wesentliche beschränkt, kam schon
noch mehr
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make rshell
Device port: usb => /dev/ttyS6
.venv3/bin/rshell --port /dev/ttyS6 --user micro --password python --buffer-size 2048
Using buffer-size of 2048
Connecting to /dev/ttyS6 (buffer-size 2048)...
Trying to connect to REPL connected
Testing if ubinascii.unhexlify exists ... Y
Retrieving root directories ...
Setting time ... Feb 24, 2020 12:41:53
Evaluating board_name ... pyboard
Retrieving time epoch ... Jan 01, 2000
Welcome to rshell. Use Control-D (or the exit command) to exit rshell.
/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware> ls
bin/ terkin/ CHANGES.rst docker-compose.yml
client/ test/ CONTRIBUTORS.rst platformio.ini
dist-packages/ tools/ Dockerfile pybytes_config.json
doc/ boot.py LICENSE requirements-dev.txt
examples/ main.py Makefile requirements-mpy.txt
lib/ settings.example-bob.py Makefile_original requirements-release.txt
lib-mpy/ settings.example.py README-HARDWARE.md requirements-terkin-agent.txt
portainer/ settings.py README.rst settings-user.example.json
ratrack/ settings.pybd.py config.mk
/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware> cp main.py /pyboard/
timed out or error in transfer to remote
/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware>
Habs auch schon mit vollem Pfad probiert:
cp /home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware/main.py /pyboard/main.py
versucht oder anders herum mit
/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware> cd /pyboard/
/pyboard> cp /home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware/main.py /pyboard/main.pymake install-sketch kann das auch. Es überträgt nur die main.py, boot.py und settings.py.
Schon mal probiert? (Vorausgesetzt, du bist auf dem aktuellen master Branch)
Ansonsten, du wärst nicht der Einzige:
EDIT: rshell 0.0.26 soll das Problem behoben haben
source .venv3/bin/activate
pip install --upgrade rshell==0.0.26Danke @Thias! Liegt vermutlich nicht an rshell, sondern an der firmware! Mit der firmware oben ESP32-SPIRAM-IDF3-20191220-v1.12-Annapurna-0.1.0.bin geht kein Hochladen, weder über rshell noch über make install-sketch. Wenn ich dagegen die “alte” firmware esp32spiram-idf3-20191220-v1.12.bin verwende geht es!
/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware> cd /pyboard/
/pyboard> ls
boot.py main.py settings.py
Mit der Anapurna-Firmware
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make install-sketch
Device port: usb => /dev/ttyS6
Using buffer-size of 2048
Connecting to /dev/ttyS6 (buffer-size 2048)...
Trying to connect to REPL connected
Testing if ubinascii.unhexlify exists ... Y
Retrieving root directories ...
Setting time ... Feb 24, 2020 15:19:36
Evaluating board_name ... pyboard
Retrieving time epoch ... Jan 01, 2000
timed out or error in transfer to remote
timed out or error in transfer to remote
timed out or error in transfer to remote
2 Likes
Schade! Keine Ahnung, was an unserem Build in dieser Hinsicht krumm sein könnte. Vielen Dank fürs Testen erst einmal!
Ich habe nochmal ein Build vom MicroPython HEAD erzeugt [1].
[1] ESP32-SPIRAM-IDF3-20200224-v1.12-b1699042-Annapurna-0.1.0.bin
Ne, geht immer noch nicht
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make install-sketch
Device port: usb => /dev/ttyS6
Using buffer-size of 2048
Connecting to /dev/ttyS6 (buffer-size 2048)...
Trying to connect to REPL ....................Unable to connect to REPL
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware#
Das ging ja vorhin schonmal besser. Da kam die Verbindung zur REPL ordnungsgemäß zustande und dann ging es nicht weiter beim Dateitransfer.
Wir lernen daraus: MicroPython HEAD ist u.U. zu experimentell und wenn @poesel’s Hinweis oben stimmt, wird es mit dem nächsten Build (dann wieder v1.12-stable) hoffentlich klappen.
Hi Clemens,
hier noch gschwind ein neuer Build: ESP32-GENERIC-SPIRAM-v1.12-dirty-Annapurna-0.2.0.bin.
Viele Grüße,
Andreas.
Leider wieder wie oben
root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# make sketch-and-run
Device port: usb => /dev/ttyS6
Using buffer-size of 2048
Connecting to /dev/ttyS6 (buffer-size 2048)...
Trying to connect to REPL ....................Unable to connect to REPL
Unable to connect to REPL
No MicroPython boards connected - use the connect command to add one
Unable to find board ''
Schade! Bevor wir hier weiter rumstöpseln: Ich brauche dann doch wohl erstmal entsprechende Hardware, damit wir aus dem Blindflug rauskommen. Vielleicht kann sich auch @poesel noch einmal daran versuchen.
Ein paar weitere Nachforschungen haben ergeben:
- https://github.com/micropython/micropython/issues/5454
- esp32: latest prebuilt firmware hangs · Issue #3651 · micropython/micropython · GitHub
Wir steuern zwar nicht UART1 an, sondern UART0
– aber wer weiß. Daher lassen wir das einstweilen mal.
Gerade erneut auf dieses Problem gefallen: mit rshell 0.0.31 ist es, ähm… besser geworden.
EDIT:
- host → mpy device: funktioniert problemlos,
- mpy device → host: terminiert mit “EOF missing”, aber file wird komplett angelegt; man kann mit buffersize noch tweaken
- rsync: tbd
1 Like
Merci.
In der aktuellsten Version bei GitHub - dhylands/rshell: Remote Shell for MicroPython kann ich die Zeichenkette "EOF missing" nirgends entdecken, auch nicht zum Stand der Version 0.0.31. Hast Du eine Idee, wo die herkommt?
Das war aus dem Gedächtnis zitiert; tatsächliche Ausgabe siehe unten.
Der rshell-Befehl (rshell 0.0.31 ohne buffersize-Angabe, somit default buffersize=32)
cp /flash/settings.py .
führt zum Fehler
dst_file.write(binascii.unhexlify(write_buf[0:read_size]))
binascii.Error: Non-hexadecimal digit found
, während der gleiche Befehl, aber aufgerufen aus rshell mit --buffer-size 16384 zu dem EOF-Problem führt:
raise PyboardError('timeout waiting for first EOF reception')
rshell.pyboard.PyboardError: timeout waiting for first EOF reception
(Die buffersize war hier so gewählt, daß die settings.py mit knapp 11kB auf jeden Fall paßt.)
1 Like
Danke. Das Problem ist scheinbar nicht ganz unbekannt.
- Problem in file edit · Issue #42 · dhylands/rshell · GitHub (42!)
- Unable to perform file transfert from pyboard · Issue #132 · dhylands/rshell · GitHub
Dave Hylands, der Autor von rshell, meinte dazu vor zwei Jahren:
I looked at this exact issue back in March (on a private email thread) and the problem appears to stem from a bug in the PyCom firmware.
– Unable to perform file transfert from pyboard · Issue #132 · dhylands/rshell · GitHub
1 Like
So wiederum funktioniert es aber, trotz der Fehlermeldung? Daraus schließe ich, dass dieser Fehler erst beim Teardown der Verbindung entsteht?
Ich frage deshalb, um eine etwaige Meldung an Dave Hylands möglichst präzise formulieren zu können, bzw. um ggf. selbst nocheinmal im Code nachsehen zu können.
1 Like
Ja, trotz Fehlermeldung wird ein lesbares file erzeugt, offenbar gibt es irgendein guard timer (oder spätestens den scheduler?), was file flush+write forced - oder so.
Ich werde dies weiterverfolgen, es klappt ja mit größerer buffersize (aber rsync wird spannend), aber zunächst ist eine andere ESP+nRF24 -Baustelle zu bearbeiten. ;)
1 Like