Skip to content
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

Changing priority of task #55

Closed
AckmaniacSoftware opened this issue Jul 15, 2019 · 4 comments
Closed

Changing priority of task #55

AckmaniacSoftware opened this issue Jul 15, 2019 · 4 comments
Labels

Comments

@AckmaniacSoftware
Copy link

AckmaniacSoftware commented Jul 15, 2019

I tried to port my code from ESP8266 to ESP32 and became timing issues. Problem was that on the ESP8266 the requests were handled in the loop and not Async at any time. This caused timing issues in the rest of the logic which is critical for my application. I tried to fix that by suspending the AsyncTCP task but it didn't work exactly how i wanted.
Finally a hige difference made the change of the tasks priority.

Changing priority from 3
xTaskCreateUniversal(_async_service_task, "async_tcp", 8192 * 2, NULL, 3, &_async_service_task_handle, CONFIG_ASYNC_TCP_RUNNING_CORE);

to 1 fixed all my issues
xTaskCreateUniversal(_async_service_task, "async_tcp", 8192 * 2, NULL, 1, &_async_service_task_handle, CONFIG_ASYNC_TCP_RUNNING_CORE);

Now my code runs reliable without any noticeable impact by handled requests.

So is there a reason that by default the priority is set to 3?

@atanisoft
Copy link
Contributor

It runs at 3 so it has a higher priority than the loop() method. It should have no impact on your code as long as you don't abuse the callbacks (ie run something that isn't directly related to sending/receiving data)

@AckmaniacSoftware
Copy link
Author

I work with shit registers and need to switch their state as fast as possible. This is done directly in the software via switching a PIN state from HIGH to LOW and vice versa. And setting the priority to 1 fixed the issue that request handling had an effect on the switching times. And the requests are still handled perfectly.

@stale
Copy link

stale bot commented Sep 21, 2019

[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 stale bot added the stale label Sep 21, 2019
@stale
Copy link

stale bot commented Oct 5, 2019

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

@stale stale bot closed this as completed Oct 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants