8000 Telnet to esp32 · Issue #191 · micropython/micropython-esp32 · GitHub
[go: up one dir, main page]
Skip to content
This repository was archived by the owner on Sep 6, 2023. It is now read-only.

Telnet to esp32 #191

Closed
hedleyd opened this issue Oct 1, 2017 · 17 comments
Closed

Telnet to esp32 #191

hedleyd opened this issue Oct 1, 2017 · 17 comments

Comments

@hedleyd
Copy link
hedleyd commented Oct 1, 2017

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
Copy link
Contributor

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
Copy link
Author
hedleyd commented Oct 1, 2017

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
Copy link
Contributor

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
Copy link
Collaborator
nickzoic commented Oct 1, 2017 via email

@MrSurly
Copy link
Contributor
MrSurly commented Oct 1, 2017 via email

@robert-hh
Copy link
Contributor

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
Copy link
Collaborator
nickzoic commented Oct 2, 2017 •
edited
Loading

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
Copy link
Contributor
MrSurly commented Oct 3, 2017

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
Copy link
Author
hedleyd commented Oct 3, 2017 via email

@tuupola
Copy link
tuupola commented Oct 3, 2017

@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
Copy link
Contributor
robert-hh commented Oct 3, 2017 •
edited
Loading

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
Copy link
Contributor

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
Copy link
Collaborator
nickzoic commented Oct 3, 2017

@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
Copy link
Contributor
MrSurly commented Oct 3, 2017

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
Copy link
Member
dpgeorge commented Oct 4, 2017

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
Copy link
Collaborator
nickzoic commented Oct 4, 2017 via email

@nickzoic
Copy link
Collaborator

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 nickzoic/mpy-utils#16 which was working up to being able to interface mpy-utils via TCP.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@tuupola @MrSurly @nickzoic @dpgeorge @hedleyd @robert-hh
0