Telnet to esp32

[hedleyd]

On the SparkFun esp32 thing with micropython I can not telnet . For some reason on my WiPy 2.0 telnet works just fine. Both boards are running micropython but does anyone know what Pycom have done to get it to work ? As other posts indicate that for a number of reasons it can’t be done.

[robert-hh]

pycom.io uses a completely different approach with an underlying RTOS kernel. Using that, they have dedicated tasks for telnet, ftp, and the python engine.

[hedleyd]

Thanks - we are exploring the Espressif range ideally using micropython so this helps join the dots as our minimal requirements are low power , WiFi , BT , with ssl / TLS connectivity . Coming from an LPC cortex range running embedded Linux I guess the Espressif platform and tool chain are a work in progress but seem to have a very active community and responsive prime vendor . Could someone point me to docs of how to connect remotely once WiFi is set up . Eg get , put , post ?

[robert-hh]

Micropython by micropython.org or pycom.io is not a full operating system. You if you need support for a specific network protocol, you have to implement that as Python scripts. Pycom provides telnet and simple ftp for an easier access. There are http servers made by some people, so you can try these. Just look around in the respective forums forum.micropython.org or forum.pycom.io. It's a little bit more work compared to a Linux platform

B.t.w.: You can run the WiPy2 image on a sparkfun esp32 thing, or almost any similar device (huzzah feather esp32, wemos lolin32, wemos esp32 lite, ...), and the opposite, since the underlying chip & architecture is similar.

[nickzoic]

I have a branch for a telnet server, it needs to be rebased onto current master but it was pretty workable.If you're interested, I'll rebase it onto current.

I was thinking of putting an ssh server together.

Just like the PyCom stuff, these run as separate FreeRTOS tasks alongside the main MicroPython task.  I was thinking of making them compile- time options.  It could bake in an authorized_keys at build time.

[MrSurly]

@nickzoic, could you provide a link? Any thoughts on supporting file transfer?

Your raw mode copy script is great, but slow over serial.

On Oct 1, 2017 2:26 AM, "Nick Moore" notifications@github.com wrote:

I have a branch for a telnet server, it needs to be rebased onto current master but it was pretty workable.If you're interested, I'll rebase it onto current.

I was thinking of putting an ssh server together.

Just like the PyCom stuff, these run as separate FreeRTOS tasks alongside the main MicroPython task. I was thinking of making them compile- time options. It could bake in an authorized_keys at build time.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/micropython/micropython-esp32/issues/191#issuecomment-333364439, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYHCBIbMQ2cJke6WWVqrXQuO35acdYNks5sn1q1gaJpZM4PpzrZ .

[robert-hh]

For file transfer during development I adapted a little ftp server, which is here: https://github.com/robert-hh/ESP8266-FTP-Server, file ftp.py. It runs in foreground, so you have to start it with: import ftp It then tell the where it' s listening at, and quits when the client closes the connection. You can restart it with ftp.ftpserver(). It has to be placed on your ESP32 by serial or embedded as frozen bytecode. I use it as simple transfer during testing.

[nickzoic]

The biggest problem with all the repl-manipulating approaches is that ESP-IDF log messages, eg: WiFi connecting and disconnecting etc, really screw them up. I need to go through and write error handling for the replcontrol stuff to retry when this happens.

RREPL (telnet) is here https://github.com/nickzoic/micropython-esp32/tree/esp32-rrepl ... I need to rebase it though.

(also, as noted, they're kinda slow ... although the difflib version make everything a lot quicker!)

[MrSurly]

The biggest problem with all the repl-manipulating approaches is that ESP-IDF log messages, eg: WiFi connecting and disconnecting etc, really screw them up. I need to go through and write error handling for the replcontrol stuff to retry when this happens.

ELI5?

[hedleyd]

I tried a few times to load the WiPy image onto the sparkfun ESP32 thing . It starts up and then garbage . I suspect the WiPy image may comprise a number of " layers " and if using the Pycom formware update untility It seems to program but does not work - perhaps some differences in the memory on board .

Does anyone know where to find a WiPi 2 image that will load onto the ESP 32 thing ??

Hedley Davidson Managing Director Cynaps Technologies Pty Ltd hedley@cynaps.co.za 078-458-7476 ( Mobile )

On Sun, Oct 1, 2017 at 10:48 AM, robert-hh notifications@github.com wrote:

Micropython by micropython.org or pycom.io is not a full operating system. You if you need support for a specific network protocol, you have to implement that as Python scripts. Pycom provides telnet and simple ftp for an easier access. There are http servers made by some people, so you can try these. Just look around in the respective forums forum.micropython.org or forum.pycom.io. It's a little bit more work compared to a Linux platform

B.t.w.: You can run the WiPy2 image on a sparkfun esp32 thing, or almost any similar device (huzzah feather esp32, wemos lolin32, wemos esp32 lite, ...), and the opposite, since the underlying chip & architecture is similar.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/micropython/micropython-esp32/issues/191#issuecomment-333362480, or mute the thread https://github.com/notifications/unsubscribe-auth/AHXOKmxZFpWu7TpOPwvtq5pny2bBHh71ks5sn1HFgaJpZM4PpzrZ .

[tuupola]

@hedleyd Not sure if this helps, but the WiPy 2.0 is a tarball which contains bootloader.bin, partition.bin and the firmware itself wipy.bin. Bootloader goes to 0x1000, partition table to 0x8000 and firmware to 0x10000. Ie to flash everything one could:

$ esptool.py --port /dev/cu.usbserial* --baud 115200 --after no_reset write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x1000 bootloader.bin
$ esptool.py --port /dev/cu.usbserial* --baud 115200 --after no_reset write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x8000 partitions.bin
$ esptool.py --port /dev/cu.usbserial* --baud 115200 --after no_reset write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x10000 wipy.bin

More thorough instructions in this blog post.

[robert-hh]

It works, but when Microypthon comes up, the resulting speed is 74800 baud. And having 74800 baud on a linux machine is difficult, so I tried Windows & Putty. It works nicely with a WEMOS lolin32. The difference could be the crystal, which is 26 MHZ on the esp32 thing and 40 MHz on other devices. Since the MP ESP32 port works with 115200 baud, I have to look into the sources. Maybe I find a cure. Until then, you can fool it, by changing _boot.py into:

from machine import UART
os.dupterm(UART(0, 177200))

That causes UART to actually run at 115200 Baud

Edit: REPL will work, but WiFi is also at the wrong frequency, and won't work

[robert-hh]

OK: found a method that works with both frequencies: a) you must setup the environment to create your own image b) once that is done, modify the file sdkconfig.h in follows: change the line #define CONFIG_ESP32_XTAL_FREQ 40 into #define CONFIG_ESP32_XTAL_FREQ 0 remove the line #define CONFIG_ESP32_XTAL_FREQ_40 1 and add instead the line: #define CONFIG_ESP32_XTAL_FREQ_AUTO 1 Then rebuild bootloader and app, erase the flash and load the new image: erase flash: make erase build bootloader: make BOARD=WIPY TARGET=boot build app: make BOARD=WIPY flash image: make BOARD=WIPY flash with the ESP32 thing, you do not have to tie GPIO0 to GND yourself. That's done by board & esptool.py magic.

[nickzoic]

@MrSurly what I mean is, the mpy-utils scripts are pretty damned dumb, and they send down statements like print(repr(os.listdir('/')))\x04 and then wait for a response like OKoutput\nmore output\x04exception message\netc\netc\x04> But it can get confused if the Wifi warning messages etc interject, as they often do especially if you've got LWIP logging turned up. That's possibly fixable with some changes to the commands and/or raw mode so we can distinguish good output from bad, but I'm not sure I'm happy with that approach.

Also, if you have a main.py which runs forever, like a web server etc, then the remote tools have to Ctrl-C out of it, which can be a bit messy. Inspired by @robert-hh 's FTP server above I was thinking: how about instead of breaking out of main.py, how about we write some code which sits in boot.py ... if it gets some file transfer commands then it lets you talk to the filesystem, if it times out it falls through to main.py for business as usual. We've got a bit more control here than pushing commands one by one to the raw repl, so should be able to work around the log messages. For production use, just remove it.

Dunno. It's still pretty sketchy. On the upside, it'd work the same over serial / telnet / SSH / whatever (which is what I wanted mpy-utils to do as well) I'll keep thinking about it.

[MrSurly]

what I mean is, the mpy-utils scripts are pretty damned dumb, and they send down statements like ... But it can get confused if the Wifi warning messages etc interject, as they often do especially if you've got LWIP logging turned up.

@nickzoic

Ah, okay, now it makes perfect sense. I thought that there was some mechanism where the logging would make the human REPL ureadable (I mean, it does, but it's not really a problem).

My take was to have a telnet or SSH REPL, and another mechanism (e.g. FTP or SFTP) for file transfer.

The Pycom FTP is nice when it works; it's still pretty buggy. It'd be ideal to have mDNS, SFTP, and SSH working "under the hood" (RTOS level). With mDNS, it's no more messing around with IP addresses. Even implementing network.Server() would be neat. You could tie an external button on your gadget to enable the server, and do your uploads.

[dpgeorge]

The biggest problem with all the repl-manipulating approaches is that ESP-IDF log messages, eg: WiFi connecting and disconnecting etc, really screw them up.

@nickzoic please see #112 : it adds esp.osdebug() to disable these messages. What do you think about that function, would it help your case?

[nickzoic]

Yeah, I was looking at that one just before too and planning on rebasing it onto the current ports structure ... I often want the debug messages while my code is running but being able to suspend them while the file transfer process is  running would be very helpful.  Maybe suspending messages would make sense for raw repl mode in general ... anything using raw repl mode is using it for a reason.

[nickzoic]

For discussion of the repl stuff see micropython/micropython#3817

Work on the telnet client is lost in the mists of time, sorry, but see https://github.com/nickzoic/mpy-utils/pull/16 which was working up to being able to interface mpy-utils via TCP.