MicroPython Forum (Archive)

If you have the chance (and are not on Windows), try the command line ftp version, which I used yesterday, or use a browser like Chrome. I cannot recall whether I tried Filezilla with that version, which is kind of intermediate. As far as I could tell, Filezilla quick connect mode doe snot work. Either it uses active mode or more than one connection. That can be a little bit misleading. Even when a command is not supported by the file server, it should print the request. But an attempt to open a second connection will simply stall.
My personal experience is better with the Fireftp extension of Firefox. I'll try myself this evening.

@devnull The problem is yesterday's update, which broke the function. If you go back to 3d903f5b3eb930594a6c0dbaf2b5a3958807f730, it works, at least with FileZilla (passive, 1 session) and command line ftp. FireFTP complains about the incomplete data at ls. I stripped that down since localtime() is not yet available in the port. Not clear what exactly caused the problem in the new build, which was about socket timeouts. So I have to invest a little bit more. So much about my quick hack.

@devnull: After yesterday's update of the esp32 repository, the uftpsever.py script works again. Here are the updated files for my tools. I changed the ls output to send dummy file creation/change dates again. Leaving that out confused some ftp clients. One word about the editor: The copy command is traditionally Ctrl-C. But Ctrl-C is also KeyboardInterrupt, which cannot be caught in this firmware. This is a known bug in the esp32 ports. For the copy operation, Ctrl-D can be used. The problem is, that if you press Ctrl-C for copy, the editor will terminate at the next keyboard press.

@roberthh - thanks, I just received some new wroom boards and thought that I would compile and try the very latest and your original uftp server is working now, I have not tried your updated version.

Any idea what the ram usage is for it ??

Many Thanks

Update

I just tried your latest version and that's working too.

The RAM usage of the ftp server depends. If you have it in flash (frozen bytecode), it's like 1 k. The MPY size is 5k, so RAM usage will be in that range when loaded from the files system. I suggest to put ot into the flash.
If you reload the module, you can also increase the size of the file system.

Has anyone been able to get the pycom port working on a wroom32 based board? (I am using a watterott board)
I have managed to get the micropython-esp32 working but it doesn't support bluetooth.
Also how is the merge process going?

@Roberthh - I have only just started compiling my own build (on the 8266 as of last night actually) and figured out how to use frozen code, seems it is simply a case of dropping it into the modules folder.

But do you know how your ftp server can be started at boot and run in the background ?? - I started another thread on same topic on esp8266 forum.

For the ESP8266 I have a variant that runs in the background. It' here:https://github.com/robert-hh/ESP8266-FTP-Server
The callback mechanism used for that in the ESP8266 does not exist in the esp32 port. And I have no knowledge of a mechanism on the EPS32 port which would allow a background task to be registered in parallel to the REPL prompt.

What is the general state of the ESP32 port? I'm wondering if an ESP32 will overcome some of the reliability issues I've experienced with the ESP8266.

Has anyone tested pin interrupts and the UARTS? @Roberthh if pin interrupts work, have you measured the latency?

@pythoncoder: No, id did not test it yet, but I can do so. The first impression was, that it is way more responsive, maybe because of the larger RAM. but that does not exclude long latencies, since the caching mechanism is still present.
I did not continue testing with the ESP32 port, since it was announced that it will merge with the Pycom esp32 ports. Since then, there was almost no change in the port.
Update: Cannot test, since Pin interrupt is not supported, or I did not find it.