Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Threaded Wifi support
#1
I'm having some difficulty porting some lobo ESP32 style code to the K210. I'm writing a web server which uses a background thread to make a bunch of usocket/urequest requests to random servers on the Internet. My initial test was porting one of the usocket requests.

The usocket code (trivial IMAP inbox size test) runs perfectly from the REPL thread, and when not starting it in a background thread, runs perfectly from the MicroWebSrv. However, the second I try to run the code from within a background thread (no fancy options) the trivial DNS query it begins with starts failing.

Is this by design? If so do you have any ideas how I could restructure the code to support the use case?

If I run using the twotasks version could I IPC between the two cores such that the second main would perform the backend server requests and the first main provide the web service? I'm unsure how the 82xx based wifi modules work with twotasks.

Thank you so much!
Reply
#2
(05-18-2020, 11:51 PM)lypanov Wrote: I'm having some difficulty porting some lobo ESP32 style code to the K210. I'm writing a web server which uses a background thread to make a bunch of usocket/urequest requests to random servers on the Internet. My initial test was porting one of the usocket requests.

The usocket code (trivial IMAP inbox size test) runs perfectly from the REPL thread, and when not starting it in a background thread, runs perfectly from the MicroWebSrv. However, the second I try to run the code from within a background thread (no fancy options) the trivial DNS query it begins with starts failing.

Is this by design? If so do you have any ideas how I could restructure the code to support the use case?

If I run using the twotasks version could I IPC between the two cores such that the second main would perform the backend server requests and the first main provide the web service? I'm unsure how the 82xx based wifi modules work with twotasks.

Thank you so much!

I've made many changes to the network support after the last GitHub update.

Support for ESP32 over SPI interface is added which works very well. Some advanced features are also added, for example Web Server can run completely on ESP32, serving files and scripts from K210 file system.
It works much better than ESP82xx, the speed is up to 2 MBytes/second and it is far more reliable.

Socket module is rewritten andĀ improved and supports all available network interfaces (for now WiFi over UART (ESP82xx), WiFi over SPI (ESP32) and GSM module, I also plan to add Ethernet support later).
SSL/TLS is now supported on all network interfaces to.

MicroWebSrv and FTP Server both runs well started in a separate thread.
If you have some examples of the code which fails, could you, please, post it here and I'll test it.

I haven't tested network functions in twotask version, I'll try to find some time to do it...

I'm doing some more testing and the new update can be expected soon.
Reply
#3
Will any of these improvements affect the ESP32 network support? I have had significant stability issues trying to do ESP32 network operations in a separate thread (although a lot of my issues seem to be related to GC while using threads). Will there be a new ESP32 release concurrently with the upcoming K210 release?
Reply
#4
I've since explored this space a lot more and came to the conclusion that it's impossible to have an ongoing "long polling" web request without holding the wifi mutex and thereby preventing any network access.

Websockets do not have the same limitation. My earlier test of websockets was flawed as I failed to increase the thread stack size in my worker threads resulting in random restarts.

I still have a few more issues but as soon as I have test cases I'll write them up for github.
Reply
#5
(05-26-2020, 07:35 PM)lypanov Wrote: I've since explored this space a lot more and came to the conclusion that it's impossible to have an ongoing "long polling" web request without holding the wifi mutex and thereby preventing any network access.

Websockets do not have the same limitation. My earlier test of websockets was flawed as I failed to increase the thread stack size in my worker threads resulting in random restarts.

I still have a few more issues but as soon as I have test cases I'll write them up for github.

Very interested. Please let us know when you post it.
Thanks for the report.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)