ESP32 FreeRTOS: Connecting edp_http_client to UART with uart_echo Example

dondu wrote:

What am I doing wrong?

.
In the FreeRTOS documentation it states: " Tasks are normally implemented as an infinite loop, and must never attempt to return or exit from their implementing function. "
Your my_task () function should therefore look like this, for example:
.
Source .

Task, despite being a normal function from the C point of view, has no right to return via return from a function. If it is not needed, it should be removed using the appropriate function. The system will release its context etc. Such a function is vTaskDelete. Of course you have to set INCLUDE_vTaskDelete to 1 in the configuration file.

In addition, if you delete a task, you must remember that the idle task gets the CPU time, because the deletion takes place right there.

Additionally, the task itself cannot return via return.

If you want a task to execute only once and then delete itself

.

Of course there are many other ways than while(1) vTaskDelay(1); I deliberately don't write about them at the moment because they either require a longer explanation or the right configuration

Below is the solution to the problem, and now read about semaphores and accessing global variables from FreeRTOS tasks .
.

I see you are trying to invent your own RTOS governed by its own laws. (For those who understand otherwise, this is a joke).

1 I don't know what app_main , but if it's something you prefer from main after schedular starts - it's wrong. After schedular starts in min there should be nothing because this code should not execute.

2. in the still shuffle they can exit via return. This cannot be the case.

3) If multiple threads refer to the same object then you need to ensure some synchronisation. In this case you must ensure that only one thread has exclusive access to the variable.

4. if you assume that the function that starts the shuffle is another shuffle, and you only want 2 of them to start, then you also need to synchronise this. Because you may find that you are starting many more shuffles than they are deleting.

Nobody does it that way anyway. Note that even just deleting the shuffle is optional in freeRTOS - many applications never do this.

In addition, deleting tapes does not release the memory used by the task. This has to be done "manually" (if the task has allocated something dynamically, of course).

stmx wrote:

I don't know what the app_main is , but if it's something you prefer from the main after schedular starts - then it's wrong. After schedular starts in min there should be nothing because this code should not execute.

.
Another "I don't know, but I'll comment" style statement. Please refer to the ESP-IDF documentation, where it is described how the app_main is constructed.

stmx wrote:

In further shuffle they can exit via return. This cannot be the case.

.
This can be the case and is correct. The task is deleted. Please take a look at the example from the FreeRTOS documentation: https://www.freertos.org/implementing-a-FreeRTOS-task.html

stmx wrote:

I see that you are trying to invent your own RTOS governed by its own laws.

.

stmx wrote:

Nobody does it that way anyway.

Please keep these kinds of puppyish remarks to the participants https://www.kickstarter.com/projects/16738888...enerator-debugger-multimeter-and-muc/comments

Added after 1 [hour] 14 [minutes]:

stmx wrote:

Additionally, deleting shuffles does not release the memory used by the task. This has to be done "manually" (of course if the task allocated something dynamically)

.
And if it does not allocate (as in the case of the code shown in post #4) then this (releasing memory) is done automatically during the Idle task.

Added after 1 [minute]:

stmx wrote:

Tape deletion itself is optional in freeRTOS

.
That is, you may or may not do this depending on what you want to do e.g. in the case of ESP32 such a restart is required to reassign a task to another core.

Added after 50 [seconds]:

stmx wrote:

In this case you must ensure that only one thread has exclusive access to the variable.

.
This is why the mutex was used in the code in post #5 - xSemaphoreCreateMutex().

Added after 1 [hour] 9 [minutes]: .

An alternative way to use a mutex in this case is to use the atomic type atomic_int :
.

dondu wrote:

The result is correct because my_task runs every second and my_task_2 runs every 5 seconds:

.
So the code should also be correct .
You have changed the strategy: you no longer create shuffles in app_main every time, i.e. in the "normal" way .
In the function assigned to tasks, vTaskDelete(NULL) is redundant at the moment, unless you exit the while(1) loop with e.g. some break.

You can, for example, send a task to vTaskSuspend

dondu wrote:

If I needed one task to suspend the work of another for a while, what would need to be done?

.
Simply via vTaskSuspend() : https://www.freertos.org/a00130.html

More "elegantly" by using xTaskNotifyGive() and ulTaskNotifyTake(), but this is a bit more difficult:
https://www.freertos.org/RTOS-task-notifications.html

dondu wrote:

What I meant was whether FreeRTOS compliant

.
I don't want to answer that question, because there are as many "rules" in the Forum as there are participants

khoam wrote:

More "elegantly" by using xTaskNotifyGive()

this won't work because the task you want to stop has to block itself while waiting for the notification.

stmx wrote:

this won't work because the task you want to stop has to block itself while waiting for notifications

.
That's why I wrote about using ulTaskNotifyTake() - please quote in full and read with understanding.

Added after 2 [minutes]:

dondu wrote:

Result correct:

.
It is OK.

khoam wrote:

Simpler by vTaskSuspend() : https://www.freertos.org/a00130.html

More "elegantly" by using xTaskNotifyGive() and ulTaskNotifyTake(), but this is a bit more difficult :

.

Full quote. Tell me how you stop another task elegantly with notification? If you find such a magic way then so can a semaphore or queue

khoam wrote:

This is why I wrote about using ulTaskNotifyTake() - please quote in full and read with understanding.

I understand perfectly but due to the rules I won't comment on it.

To @dondu just suspend. Any other method requires the task to lock itself. Another task can only unblock it

stmx wrote:

Tell me how you stop another notification task elegantly?

.
I won't directly stop another task with a notification, but I can cause the target task, upon receiving such a notification, to "pause" itself for a period of time specified in the notification sent - this is what the Author of the thread asked about in post #10.

Added after 23 [minutes]: .

I think it won't be long before the Author of the thread himself starts using notifications to determine the shuffle stop time, as soon as he faces the fact that the xTaskAbortDelay() function is not implemented in the FreeRTOS version for ESP32.

dondu wrote:

If I needed one task to pause the other for a while, what would need to be done?

probably not about that though .

khoam wrote:

as soon as it faces the fact that the function xTaskAbortDelay()

LOL. I think dondu is a better programmer and won't "face" this problem.

stmx wrote:

I don't think that's what it's about though .

.
Exactly what it is about, but the way of interpretation remains divergent and let it stay that way.

dondu wrote:

Now I need to add a timer. With FreeRTOS, can xTaskGetTickCount() be used for this task, or something else?

.
I use the soft timers from FreeRTOS for this task: https://www.freertos.org/FreeRTOS-Software-Timer-API-Functions.html.

Added after 2 [minutes]: .

In the ESP-IDF itself you also have timers, of course, if you want more precise timing.

dondu wrote:

With FreeRTOS, can xTaskGetTickCount() or something else be used for this task?

Yes it can.

stmx wrote:

Exactly that, but the way of interpretation remains divergent and let it stay that way.

But I still don't understand how to "elegantly" do it. The task you want to put to sleep has to poll all the time to see if there is a notification to go into a locked state- which is definitely not elegant nor in the spirit of multitasking. So bring me closer to this "elegance".

In addition suspended != blocked.

khoam wrote:

For this I use the soft timers from FreeRTOS: https://www.freertos.org/FreeRTOS-Software-Timer-API-Functions.html

.
Also a circular method because the freeRTOS timers are used to call a callback after a certain time has elapsed. This callback in turn must notify the task. In addition, the software timers are based on the queues in freeRTOS - and these are resource intensive. So software timers are useful, but I don't know if that's what Kol dondu meant - because for timeouts, for example, they are completely unsuitable.

stmx wrote:

This callback, in turn, must notify the task.

.
The soft timer does not need to notify task. Only the timer handler is passed in the callback, and the action it further calls does not have to be related to the FreeRTOS task.

Added after 1 [minute]: .

dondu wrote:

For now I want to count down time intervals of about 15 minutes. This is needed because every such time the data is to be sent to the database

.
It all depends on what you want to happen after this countdown of the set time. If you want to send some data to the database, the callback in the soft timer will be appropriate.

If it is only to wait and so to speak it is not to unlock vTaskDelay( xDelay );

stmx wrote:

If it is supposed to be just waiting and so to speak there is no unblock vTaskDelay( xDelay );

.
The callback in the soft timer can also unblock the task by sending an appropriate notification.

dondu wrote:

I will also use Software Timers to get to know them

get to know the queues better.

Task sending locks onto a data queue. Task collecting data as time elapses adds to this queue which unlocks the sending task, which after sending again locks on accessing the queue