-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing features #3
Comments
Hi @ammaree, controlling DTR and RTS signals is already possible with the existing API, just not demonstrated in the example. To support remote flashing, RFC2217 server needs to detect the beginning of the DTR/RTS reset sequence, and instead of passing it on to the GPIOs, it needs to generate a precise enough reset sequence itself — something similar to what this code in esp_rfc2217_server is doing. I think this doesn't require changes in rfc2217-server component and can be implemented in the If I find some time to work on rfc2217-server component I'll add an example to flash an ESP chip remotely. |
Hi @igrr thanks for the feedback. The most important item for me to move forward is the DTR/DSR support. I have started adding it (simplistically) by toggling DSR & DTR pins as required, but obviously that will not be sufficient. Another item I need to add is simultaneous support for at least 2 telnet sessions: Any suggestions on how to adapt your RFC2217 component to handle 2 simultaneous sessions in the most effective manner? |
Could you please clarify what you mean by "HOST device CLI"? Does it mean simply forwarding the console logs of the rfc2217-server to the TCP port? Or is there an actual CLI with line editing, command prompt, etc? |
We have an actual CLI on the Telnet RFC2217 HOST device, primarily used for Wifi configuration but also with significant debug capability. What we would like to achieve with the first Telnet session is to remotely have access the CLI on the HOST device The second Telnet session would be used to "passthrough" commands to the CLI on the TARGET device as well as to reflash the TARGET device using the RFC2217 functionality |
Just to possibly clarify, functionality similar to the original ESP-Link on 8266, but without the Arduino/AVR, ARM support, no MQTT or outbound REST HTTP functionality. The webserver as an alternative console maybe nice to have, but critical is ... Host device to be small and compact, powered from the target device. Ideal existing platform would be ESP32-S3-USB-BRIDGE, if only I can source them. Ultimately the perfect Espressif based remote support device to support remotely deployed Espressif devices! |
@igrr Apologies if you are on leave, but just another update from my side. I have added support for the DTR and RTS pins and configured as per code below:
In addition I have add basic support for the minimal control options, see the code below:
I have the software running on a Lolin Mini-S3 and can connect to the target device using: The UART to Telnet functionality is working perfectly in both directions. I have done some research and it seems as if the esptool.py
I also had a look at the link to the Python server code but that made very little sense to me based on my limited Python skills Where can I find some specific detail on the ESP32 reset sequence, specifically the start and end conditions as well as the exact timing required? Alternatively, if you have made some progress with the flashing example that would be wonderful André |
Thanks for explaining the use case. Regarding adding generic Telnet support, I think it is possible. However since I don't have a need for such functionality myself, I don't think I'll find time to add it to this project. If someone contributes that, I'll accept reasonable PRs, of course.
ESP32 datasheet contains the timing parameters, please search for If you are driving the reset and GPIO0 pins of ESP32 via a transistor pair, as often done on development boards, you need to consider the delays introduced by this circuit. The exact timings will depend on the parameters of this circuit, you probably have to analyze this yourself. |
Hi @igrr Thanks for the feedback. As an update I have added the following functionality... rfc2217-server/include/rfc2217_server.h:Fixed RFC2217_PURGE_????? enum values should be 1/2/3
rfc2217-server/include/rfc2217_server.c:Slightly improved baudrate support to report consistent format
Q1: Why the duplicated functionality in lines 565 and 573 (original source code)? You are welcome to include the changed code above directly into your source, no credit or copyright required... In addition to the above I have changed the UART example to add the required support. The basic functionality is working to reset the device and (sometimes) get it into download mode, but no luck (yet) get any flash operations to work.
Have not yet played with different timing delays until I can have the DTR/RTS logic verified. Once we have the full functionality working happy to have the code included in your repo. Thanks André |
Using
Using
|
Just another comment. I am ONLY trying to make this work with target devices without any transistor drivers, directly controlling EN and IO0 with GPIO's from the host device. Should it become a requirement at a later stage to support target devices through a USB (to UART) interface the required timing adjustments can be made at that stage. For an example see this device but there are many more... |
Hi @igrr
Recently found this repo and was hoping it would be part for the solution for a burning need as identified in https://github.com/espressif/esp-dev-kits/issues/99
Whilst all the support for a basic RFC2217 session is there, the support required to enable remote UART flashing an ESP32 device is missing. Primarily the simulated control of DTR and RTS signals.
Any specific technical reason why this was omitted?
The text was updated successfully, but these errors were encountered: