0:00 Welcome back, we are not continuing with the Wifi stuff, rather focusing on tasks 1:25 create a new folder in application with TaskMessaging.h and populate the file You need to follow from the beginning for this to make any sense 1:23:30 Wrap up Thanks Simon!
Thank you so much for this series, it's really fantastic. I am struggling with how I can create my own tasks though, like I want to be able to have a member function of a class run as a task. Is this the right approach? Do you have any advice?
Hi guys, I am wondering why the parentheses ( ) are needed when calling this constructor: TASKMESSAGING::StaticQueue my_queue(); GCC shows an error when I remove the parentheses. TASKMESSAGING::StaticQueue my_queue; And the second thing is how the template initializer complies to the constructor parameters StaticQueue(const size_t n_items, const size_t item_n_byte). Why the parameters are needed here? Are they not redundant? Thanks in advance, martesik
No braces make it a declaration rather than a definition. You can't use symbol "my_queue" that's not been defined (i.e. constructed). This is part of the core C++ language. For the template; can you explain the question? There are no uses of the template in the constructor parameters. They are used in the base class constructor QueueInterface_t and they are passed like any other argument would be. Specifically, they are compile time constants. T is just a typename, and our use is as sizeof(T), which compiles to a size_t and len is just a size_t (referred to as a "non type template parameter"). You can try omitting the and you will probably get a compile time error because the compiler cannot automatically deduce what these arguments are (known as "class template argument deduction").
Just a question related to mutexes and your implementation. Are these required in FreeRTOS queue? Going through its documentation, I thought the API calls are thread safe by default? But in a multi core application this could be different, I guess.
The FreeRTOS queue API is thread and core safe in the ESP-IDF. The reason for the mutexes was to prevent the edge case where something changes between calls in a particular flow. For example, in the send function, we check the queue isn't full (API call 1), then if not, push to the queue (API call 2). The mutex is there to prevent someone else from pushing to the queue (on the other core) between API call 1 and 2 and filling it after the check to see if the queue is full. Practically, all this really means is we get a more helpful error message because we won't get ESP_FAIL when from the callers point of view we expected ESP_ERR_NO_MEM.
I've not had issues and last time I looked they used the same implementation. I.e. the "system calls" used by the C++ standard library were calling freertos locks. To be fair, it is a long time since I checked but I've had no reason to doubt it's changed so far.
Exception handling on embedded increases binary size and reduces code performance significantly. It is quite uncommon in embedded work to have exceptions turned on
@@DrGreenGiant Can you elaborate on this? There is a lot of articles claiming that the performance kill is small. I don't think they are talking embedded but still.
0:00 Welcome back, we are not continuing with the Wifi stuff, rather focusing on tasks
1:25 create a new folder in application with TaskMessaging.h and populate the file
You need to follow from the beginning for this to make any sense
1:23:30 Wrap up
Thanks Simon!
Thank you so much for this series, it's really fantastic.
I am struggling with how I can create my own tasks though, like I want to be able to have a member function of a class run as a task. Is this the right approach? Do you have any advice?
11:06
13:24 recursive mutex
15:45 send
20:52 receive
31:15 underlying pointer
34:35 QueueInterface constructor
38:20 convert pointer
40:14 copy constructor
46:40 default constructor
47:35 n_item_waiting
50:15 n_free_space
53:00 clear
54:47 create and destroy queue
1:01:00 create unique ptr to pass to Base Q Message
Very informative videos,
keep it going.
Hi guys,
I am wondering why the parentheses ( ) are needed when calling this constructor:
TASKMESSAGING::StaticQueue my_queue();
GCC shows an error when I remove the parentheses.
TASKMESSAGING::StaticQueue my_queue;
And the second thing is how the template initializer complies to the constructor parameters StaticQueue(const size_t n_items, const size_t item_n_byte).
Why the parameters are needed here? Are they not redundant?
Thanks in advance,
martesik
No braces make it a declaration rather than a definition. You can't use symbol "my_queue" that's not been defined (i.e. constructed). This is part of the core C++ language.
For the template; can you explain the question? There are no uses of the template in the constructor parameters. They are used in the base class constructor QueueInterface_t and they are passed like any other argument would be. Specifically, they are compile time constants. T is just a typename, and our use is as sizeof(T), which compiles to a size_t and len is just a size_t (referred to as a "non type template parameter").
You can try omitting the and you will probably get a compile time error because the compiler cannot automatically deduce what these arguments are (known as "class template argument deduction").
This is so helpful 👍🌟🌟🌟👍
Just a question related to mutexes and your implementation. Are these required in FreeRTOS queue? Going through its documentation, I thought the API calls are thread safe by default?
But in a multi core application this could be different, I guess.
The FreeRTOS queue API is thread and core safe in the ESP-IDF. The reason for the mutexes was to prevent the edge case where something changes between calls in a particular flow.
For example, in the send function, we check the queue isn't full (API call 1), then if not, push to the queue (API call 2). The mutex is there to prevent someone else from pushing to the queue (on the other core) between API call 1 and 2 and filling it after the check to see if the queue is full. Practically, all this really means is we get a more helpful error message because we won't get ESP_FAIL when from the callers point of view we expected ESP_ERR_NO_MEM.
I'm not quite clear if C++ mutexes and FreeRTOS semaphores can coexist without any problem ?
I've not had issues and last time I looked they used the same implementation. I.e. the "system calls" used by the C++ standard library were calling freertos locks. To be fair, it is a long time since I checked but I've had no reason to doubt it's changed so far.
Thank you so much for this
Question. You are using error codes to indicate if different functions is successful or not. Why not use C++ exceptions?
Exception handling on embedded increases binary size and reduces code performance significantly. It is quite uncommon in embedded work to have exceptions turned on
@@DrGreenGiant Can you elaborate on this? There is a lot of articles claiming that the performance kill is small. I don't think they are talking embedded but still.
Tbh it's just what I've always been told, I've never actually explored it. Leave it with me and I'll have a play and get you a proper answer!
@@DrGreenGiant no problem. I just wanted to raise the question.