Introduction to RTOS Part 4 - Memory Management | Digi-Key Electronics
ฝัง
- เผยแพร่เมื่อ 20 พ.ค. 2024
- Memory management is important in a multi-threaded environment, as threads (or tasks) can quickly consume all of the allocated memory, causing bizarre effects such as overwritten memory locations or random processor resets.
The solution to the challenge in the video can be found here: www.digikey.com/en/maker/proj...
In this video, we look at various ways to allocate memory to a task and how to monitor memory usage in FreeRTOS.
Most C programs rely on 3 different types of memory. Static memory is set aside prior to program execution and used for things like static variables, constants, and global variables. Stack is allowed to grow dynamically and consists of local variables declared at the function level. Finally, heap may also grow dynamically and must be specifically allocated and deallocated by the programmer (e.g. using the malloc() and free() functions, respectively).
Whenever we create a new task in FreeRTOS, we must assign it a set amount of stack memory to use out of the global, available heap. Note that each task also requires another section of heap for the Task Control Block (TCB), which stores various attributes about the task, such as its state and priority.
We demonstrate ways to monitor the stack in each thread as well as the total amount of heap available to the system. We also show what happens when you overrun the stack or heap!
Product Links:
www.digikey.com/en/products/d...
Related Videos:
Introduction to RTOS Part 1 - What is a Real-Time Operating System (RTOS)? - • Introduction to RTOS P...
Introduction to RTOS Part 2 - Getting Started with FreeRTOS - • Introduction to RTOS P...
Introduction to RTOS Part 3 - Task Scheduling - • Introduction to RTOS P...
Introduction to RTOS Part 4 - Memory Management - • Introduction to RTOS P...
Introduction to RTOS Part 5 - Queue - • Introduction to RTOS P...
Introduction to RTOS Part 6 - Mutex - • Introduction to RTOS P...
Introduction to RTOS Part 7 - • Introduction to RTOS P...
Introduction to RTOS Part 8 - • Introduction to RTOS P...
Introduction to RTOS Part 9 - • Introduction to RTOS P...
Introduction to RTOS Part 10 - • Introduction to RTOS P...
Introduction to RTOS Part 11 - • Introduction to RTOS P...
Introduction to RTOS Part 12 - • Introduction to RTOS P...
Related Project Links:
www.digikey.com/en/maker/proj...
Related Articles:
www.digikey.com/en/maker/vide...
Learn more:
Maker.io - www.digikey.com/en/maker
Digi-Key’s Blog - TheCircuit www.digikey.com/en/blog
Connect with Digi-Key on Facebook / digikey.electronics
And follow us on Twitter / digikey - วิทยาศาสตร์และเทคโนโลยี
"Good luck. We're all counting on you." I love this guy. He's good at explaining, makes it interesting, makes good use of visual aids and demos, and has a sense of humor. Thank you Shawn!
This channel is basically covering one of my courses thats painfully unclear, absolutely awesome
real time embedded systems at my school, although lecture wise is ok, does not cover hardware implementation at all. Im really disappointed considering that my school is supposed to be one of the more advanced in terms of software/hardware education. It doesnt help that they pulled the lab ta off the street and he knows virtually nothing about rtos and wants to teach us about linux and computer os instead which is completely disconnected from the course content.
For those who are referring his solution form website, do note that instead of "idx ;" correct it as "idx++;" .If index in not incremented there can be chance for assert failed error.
Hope this helps someone.
I found that too..
Excellent content. Thank you Shawn, keep them coming!
Really good explanation and visual demonstration on how memory allocation should be done. Your voice can really stay in my head, looking forward to all of your videos!
This guy is seriously amazing! Thanks for the vid!
was waiting for this.. thanks
Awesome work Shawn
Nice Mission Impossible reference! Your voice does remind me of the guy on the tape, now that you said it.
I was hoping someone would catch that :)
This guy is excellent
Great video, Shawn! And I've a question. From 2:46, what is the usage of the light-orange-colored Stack (at the top of the RAM pattern)? Seems that this part is unused in FreeRTOS system, doesn't it? Thank you :-)
Really good ideas
Dear Mr Shawn, thanks for your video. On your solution code, you use a global variable msg_flag. Will it create a race condition between the printMessage task and the interrupt handler? i.e. before the task clear the flag, interrupt occur and set the flag, then return to the task and the task clear the flag. The message will be missed, and the msg_ptr is not freed
thank you very much!!!!!
Shawn, are you planning to upload a quick tutorial that uses both cores of ESP32 soon?
I wasn't planning on it, as these videos are focused on RTOS concepts and FreeRTOS (the ESP32 just happened to be a really easy way to start using FreeRTOS). However, I'm glad to know there's interest in talking about multi-core operations and the ESP32, so I'll keep that in mind. For now, I recommend starting by looking the differences between ESP-IDF and FreeRTOS to get a sense of how the ESP32 uses its 2 cores when running tasks: docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/freertos-smp.html
Hey Shawn! I have realized that if I put vTaskDelay(100 / portTICK_PERIOD_MS); at the and of the task where you demonstrated the stack free space size problem, there is no Guru Meditation Error! Why is that?
So if I dynamically allocated a array inside a task, does it go onto the task's stack?
Thanks Shawn, you just explain my problem and show the way to a sullution. 👍🧐
malloc is called that becoz it references the human readable Memory Allocate so it becomes malloc
i find it easier to memorize the functions name if i know the human readable equivalent .
If the heap has some bytes remaining that is more than enough to allocate more arrays of 1024 integers in the above example at 9:17 why does it say that the heap has run out of heap?
How do you get 768 bytes overhead at 6:22? Shouldn't it be 623 (1024 - 401)?
Each task in ESP-IDF requires 768 bytes of task stack for bare minimum operation. If you allocate 1024 bytes for stack, that gives you 1024 - 768 = 256 bytes left in stack for that task. Since we try to declare an int array with 100 elements, that will try to use 400 bytes of stack (100 * sizeof(int) = 400 bytes), which is more than we have left. Hope that helps!
@@ShawnHymel Thanks! Now I see that 768 bytes comes from documentation/configuration.
@@ShawnHymel you should have explain like that in the video. Because i have had the same question. Now , i got this but i have wasted my brain tying to figure out.
Anyway..
Thank you
Thank you for pointing it out and bridging the gap!
I have the same question, thank for your pointing it out. :)
Why are we counting till idx-1 and why is volatile qualifier necessary?
Interesting note... I wasn't able to get my ESP32-S2-Mini-1 to crash when allocating the 400-byte array when I configured the task to use 1024 bytes of stack memory. I had to lower it to something like 500 bytes to replicate the hard reset. I supposed this means that the overhead is lower for my version of the ESP-IDF core? :)
Yes, probably this is what is happening. I suppose the overhead needed would depend on the device
I have completed the challenge. However I could not get my application to run properly without using vTaskDelay(0) in both tasks. Otherwise, only the task which was created first, is executed, and the other one never. The tasks are of the same priority and are pinned to one core. It seems to me that you actually have to explicitly yield task execution (by calling vTaskDelay() ) in order to give other tasks a chance to run. Which contradicts, what was said about the scheduler executing tasks of same priority in round robin fashion ?!
I have the same problem...
At around 0:34, you mentioned that: "This section is labelled as static memory and connot be used for other parts of the program".
This explanation is misleading as it gave the impression that static memory cannot be 'used' for other parts of the program. Static memory can certainly be used in any part of program as long as the variable visibility rules are adhered to.
Instead, your explanation could have been better stated as: "This section is labelled as static memory which is only allocated during compile time".
Good point, thank you!
What he is trying to say is that the static variables have an internal linkage that means static variables can only be accessed within the same program file where they are defined. You can not access static variables in any other file if your program has multiple files. similarly, if we use static with the function definition, it can not be accessed from any other file.
@@Microcontrollerslabit would have been clearer and much more accurate to simply state that static variables follow the same visibility rules as other variables.
Calculating the size of the actually allocated memory gives me 4112 bytes instead of 4 * 1024 = 4096 bytes, why is that?
I was wondering the exact same thing. I also did the exercise and even just allocating one byte, it decreases the heap size by like 20 bytes. Is there some type of overhead in the heap when dynamic allocation is used?
Sorry actually, I did not understand stack size calculation. can you please describe to me how can I calculate it? in my case memory size is 408 bytes.
To get stack, you need to add up the size of all of the automatically allocated variables for that task.
@@ShawnHymel How can I calculate thr stack size I need if I have a big Task with lots of functions ?
please, how did you calculate the overhead 768 at 06:21
Shawn Hymel
6 months ago
Each task in ESP-IDF requires 768 bytes of task stack for bare minimum operation. If you allocate 1024 bytes for stack, that gives you 1024 - 768 = 256 bytes left in stack for that task. Since we try to declare an int array with 100 elements, that will try to use 400 bytes of stack (100 * sizeof(int) = 400 bytes), which is more than we have left. Hope that helps!
@@digikey thank you Mr it helps :)
@@digikey then why it didn't overflowed in first iteration itself ?
I mean we are not freeing up the space then according to calculation 400>>usable stack..
So it should not allow this many iteration..rather it should give error at first iteration itself..
How to change task scheduling time in freeRTOS?
Good question--It's set in the line "#define configTICK_RATE_HZ" in FreeRTOSConfig.h. This is set to "1000" by default in the ESP32 Arduino package.
Please can anyone help? Why is the stack canary watchpoint not triggered immediately and the task while loop is able to run several times before the trigger? Also, is it watching the "real" stack or the "task" stack in the heap?
Could you find any answer to your question?
Same question buddy..
@@taccle1129 Nope. I moved on. Better not be stuck. Can always revisit this issue.
The stack overflow is not checked every time when something is written to the stack, but only when the tick is finished and the kernel takes over control. Then the kernel can check if the canary was overwritten.
@@pandabar2869 Thank you! I think it might take several ticks? Because the loop is able to run 10+ times(not sure, don't have the code at hand).
you look like glassreflection guy who reviews anime
Maybe you need to slow down while explaining 😉
Good thing it is a video and I can watch again and again if I need (and I usually do)
I too feel the narrative is too fast. It tends to distract the listeners and affect understanding. I hope your narrative for future videos can be slower by say 10~15%. Nevertheless, your content is excellent!
@@boontecklee592 you can always watch at 0.75x!
use 0.5x for that
Slow the video down and open up his code for review before watching the video. That's how you really learn this stuff anyway