me-no-dev / AsyncTCP

Async TCP Library for ESP32
GNU Lesser General Public License v3.0
757 stars 439 forks source link

How to access _async_service_task_handle to suspend? #18

Closed terryjmyers closed 5 years ago

terryjmyers commented 6 years ago

Feature Request or implementation help:

I have a high speed data acquisition project in an ESP32 in which I need to devote one core to SPI communications and another core to serving the data via socket connection. I'm only using the Async libraries for (AsyncWebServer and AsyncWebSockets) for a configuration webpage, as even a 1ms response time of FreeRTOS is too slow (and the vTaskDelay(1) used in _async_service_task takes too much processing power). I need all of the grunt that the ESP32 can muster just to keep up with the flood of data. So I'd like a way of programmatically suspending and resuming the "_async_service_task". Which of course I'm doing with all of the other "housekeeping" type tasks i the program when the user initiates the high speed data transfer. For some reason I can't just vTaskSuspend(_async_service_task_handle), as I get the following error: "error: '_async_service_task_handle' was not declared in this scope vTaskSuspend(_async_service_task_handle)" I just can't seem to figure out how the Async Libraries are put together enough to access this handle.

I'm using VisualStudio with the VisualMicro plugin and the Arduino toolchain. I'm using the Arduino toolchain "Loop" task as my housekeeping task (Serial console, Telnet client, WiFi stuff, etc), and simply vTaskSuspending it during the high speed data transfer. I'd like to use the Async libraries, but I could just simply use the new WebServer library in the Arduino ESP32 toolchain and the arduinoWebSockets library in a task I can control, but I'd rather use these libraries for various reason (SPIFFS editor, Alexa library, re-use of previously written code, etc).

me-no-dev commented 6 years ago

did you pull the latest code? vTaskDelay is no longer in the async task. You also should keep in mind that there are other threads involved, like the wifi and LwIP threads. Suspending the task is not a very good option, because packets might arrive and get discarded (if the event queue is overflown). Please pull the latest AsyncTCP and WebServer and see how it goes

terryjmyers commented 6 years ago

@me-no-dev Thanks, I pulled the latest code for AsyncTCP and ESPAsyncWebServer. I'm not too worried about getting packets discarded, as like I said I need my project to switch to a mode that ONLY reads an ADC over SPI and writes that data out serial and/or a WiFiClient (not async).

I see that the delay was taken out, which I think basically means that the Async Library will take over full control of Core1. While this is probably fine for most people who are using these libraries as they aren't even using both cores, but I have a need to control the tasks very rigidly. Basically when the user initiates "high speed mode", I really do want to shut off the Web Server entirely, as there is no reason for them to want to access a webpage at this point and I don't want to devote any resources to this. Would you suggest I simply use the the Webserver library (https://github.com/espressif/arduino-esp32/tree/master/libraries/WebServer) so I can decide when to process "server.handleClient();"? As I know you wrote that library as well. Or is there an issue to simply not processing "server.handleClient();" at all for a while?

me-no-dev commented 6 years ago

the delay is missing but the task is made to wait for packet as long as it needs to, so instead of waiting 2ms, it might wait a minute or more if there is no packet coming, and not wait 2ms if there is one pending.

terryjmyers commented 6 years ago

Is there any reason why I shouldn't change the "xTaskCreatePinnedToCore" to "xTaskCreate", and give it a lower priority, such, the same priority as my "housekeeping" task?

stale[bot] commented 5 years ago

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] commented 5 years ago

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.