Introduction to RTOS Part 5 - Queue | Digi-Key Electronics
ฝัง
- เผยแพร่เมื่อ 16 พ.ค. 2024
- A queue is a first-in, first-out (FIFO) system that is used to store and pass information between tasks in an RTOS. Data copied to a queue will appear at the front of the queue, and any data added after that will line up behind it. When a task reads from a queue, the value at the front is removed, and all other tasks shift forward by one slot.
The solution to the challenge in the video can be found here: www.digikey.com/en/maker/proj...
Code for this video series (including demonstrations, challenges, and solutions) can be found here: github.com/ShawnHymel/introdu...
When a queue is a kernel object within an operating system, read and write operations should be atomic (as they are with FreeRTOS). Atomic operations means that other threads cannot interrupt the operation while it is executing and overwrite or read partial data from shared variables or buffers.
As a result, we can use queues to pass information between tasks in an operating system without fear of losing the data or having it be corrupted by other threads.
In this video, we begin by showing how threads can interrupt each other to overwrite data or read partial data in shared resources (such as a global variable or shared memory). We then examine queues and show how they can protect shared resources. They are an essential form of inter-task communication to pass messages between tasks.
Additionally, we provide an example of using queues in FreeRTOS on an ESP32 using the Arduino framework. A challenge is issued at the end to use queues in your own program.
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 - วิทยาศาสตร์และเทคโนโลยี
this series is super useful!
No doubt
Very useful and interesting content.
Thank you for sharing.
You really have a talent in doing great tutorials! This might be the best RTOS tutorial in the world. Keep doing the RTOS series, you are doing a great job!
As others suggested maybe future topics(after the RTOS series is done) should be about STM32, critical regions, debugging (without Serial.print()) !
Thanks! We have a series on getting started with STM32 (one of the videos in here shows how to get started with FreeRTOS in STM32): th-cam.com/video/hyZS2p1tW-g/w-d-xo.html. I'll keep the others in mind for future episodes.
I like this series, very helpful! Thank you!
You guys are so awesome!
Hello sir I would like to watch more videos on your stm32 series like can bus,sleep modes ,rtc ,usb device. If you could continue with them. It should be beneficial for all others
Good to know there's interest in more STM32 stuff. I'll keep that in mind!
❤️❤️❤️❤️❤️❤️❤️
Really enjoying this series. One comment on the queue example here: At 7:00 you call xQueueReceive() with a zero timeout and if nothing is received you wait for one second. That means most of the receive loop is spent idly waiting and some incoming messages on the queue will be ignored for up to one second (i.e. if the message arrives just after a check) while others will be handled almost immediately (i.e. if the message arrives just before the check).
In a real application we would normally just set the xQueueReceive to timeout after 1 second rather than idly waiting. If we needed to rate-limit receives then we could place the wait after a successful receive (inside the if-pdTRUE). For extra fancy, we’d look at how long the receive and message handling took, then only wait for the remaining part of that second.
Thanks for the recommendation! I used zero timeout to demonstrate how it works, but I agree that some kind of timeout is generally better. Good to know that 1 second seems to be a common timeout period.
So super hit and cool content bro
Thanks for the awesome videos. They're by far the best way to start learning and working with RTOS. I just have a quick question regarding queues. Where are queues stored during the runtime on esp32? I expected that they are stored in RAM during runtime and are erased when the board is no longer electrically supplied but I encountered a problem with queues and I was getting a whole lot of exceptions even after undoing everything I did, reprogramming the board and turning the esp32 off and on (not just resetting it because resetting will not erase RAM contents). It only stopped giving exceptions after I erased all contents of the flash and reprogrammed the esp32 then it stopped giving exceptions which was super weird. Do you have any ideas regarding this problem?
Great tutorial!
finally...thanks a lot
Very good content, tho I think we can go into the FreeRTOS src for a bit to explain alittle what happen behind the scene
Loving these videos. Looking forward to the one about mutexes, given that it's something that I need to know how to implement now (kind of works). I'm using RTOS on an ESP32, so knowing how to use them with multiple cores (2) would be very useful.
Question: would you create a queue for each object that tasks share? At the moment I'm using a queue for each task, but the queue only supports one type.
Great questions! Multiple cores should "just work" if you're using FreeRTOS on the ESP32. If you use xTaskCreate(), the scheduler will pick one of the cores to run your task. Note that if you're using the WiFi/BLE stack, Core 0 will generally be used to manage those tasks. I stick to one core for these videos because multiple cores would ruin a few of the demos (e.g. context switching and deadlock).
I suppose it depends on what you're trying to do with the queue. The simplest approach is probably one queue per shared object (or message type), but that doesn't mean you couldn't use a queue to pass different types of data (you can always cast the data or pass pointers--just make sure that what you're pointing to doesn't go out of scope before it's read!).
@@ShawnHymel Comfortably using both cores with xTaskCreate. Like the idea of using a queue per object, currently using a queue per "feature" (i.e. "displayQueue" for things the dsplay should show).
Tried the idea of using "peek" but ran into the trouble of knowing what should be the last task to read the queue, knowing when it would be, and ensuring that everything had read the object.
Love this stuff. Thanks for your video and response.
Very good video, thanks a lot!
Love this
Cool, now I know that a shiftregister chip works like a queue for RTOS, that means you can do something similar in hardware with discrete components which is the cool thing about this I think.
Great series, well explained, bravo. In the video example I had to deduce that xQueueReceive() actually removes items. In your second "tweak" of changing the loop period to 1000 and the task period to 500, doing Serial.println("Queue is empty"); would have made that implicit. Just sayin'.
Hint for non-blocking keystroke waiting test (not something I have done in the Arduino environment):
if (Serial.available() > 0) {
c = Serial.read();
Yes! Thanks for the hint. That should help with the challenge :)
Thank you for your great videos. They are easy to understand for people like me. But these are the fundamentals of multi-tasking and they are the same stuff weather you use RTOS or windows/linux. When do you talk about stuff that are specific to RTOS like critical tasks and timing?
That's a really good question. Right now, I don't plan to go into timing and scheduling algorithms (e.g. RMA), even though that's really what makes the "real-time" portion of an RTOS. What I found is that many embedded developers (myself included) are not used to working in a multi-threaded environment. I've lost all my multi-threading knowledge, as the last time I touched it was some 17 years ago when I took an OS class in college.
In order to create an introduction to RTOS series, I felt obligated to cover all those multi-threaded concepts again so that people can feel comfortable working in an RTOS first before moving on to hard real-time applications. With IoT-focused hardware coming out, like the ESP32, many IoT products/projects may not even have hard real-time requirements but still need the ability to run multiple threads.
I'm glad to hear that there's interest in covering the real-time aspects of an RTOS. If this series does well, that would make a good case to continue it in order to cover more advanced topics.
@@ShawnHymel Thank you for your reply. You are doing a great job 👍 If you really ask my humble opinion, you should create video zero to set up one particular embedded chip like EPS32. Then talk about pros and cons of them. Then set up a chip like EpS32 in a bread board and run the it with a few sample code (like setting up rs-232) and send some char to a different computer which is outside of lDE. I have not setup a chip since I was in college and would like to make my hands dirty with chips which can do Free RTOS and see the results. Please post your sample code for us to copy so that we can run. Great work again.
@@bayareapianist That's an idea I've been playing with that I may do in the future. I like the idea of showing people how to work with microcontrollers at a very low level using C with (probably) command line tools. It would likely be it's own series, though.
I use avr version of freertos , but not esp32 version.I have some questions on your examples. In function loop(), you put function vtaskdelay(). In avr version, function loop() run in idle task context. Is it the same for esp32 version? Function vtaskdelay() will force idle task to wait state. Does it make no task can run in the system?
Good one
Nice series Shawn.
I have seen that you're going to teach a course embedded ML on coursera. Is that true?
Yes. It went live today :)
Hi and thanks for the tutorial series. Why do you define the msg_queue_len and msg_queue as static? In part 4 you mention that global and static variables are allocated from the "static" area of memory, so what's the benefit of declaring a global variable as static?
I think it's more for clarity
Shouldn't the addresses at 1:10 each increment by 4 and not 1? Because the ESP32 uses byte-addressing and not word-addressing.
Does the scheduler consider the loop as a task and switch between it and the created task " printMessages " ??
Yes, the setup() and loop() functions in Arduino exist inside a separate task that runs with priority 1 in core 1. Because of this, the scheduler will perform round-robin execution of loop() and the printMessages task.
I'm doing this course in esp-idf without arduino. For the challenge, I'm reading user input from stdin with fgets. However fgets is blocking, the rest of Task A simply does not run while waiting for an input. I could easily solve this with a third task, but am I right that without arduino, a 2 task solution is impossible?
Hey Shawn, I found a glitch in the solution you posted. You should update it. Try typing in the serial monitor "delay " and see what happens (don't forget the space). Make sure you fix this error. Anyway, big fan of your freeRTOS Course
Superb tutorials!
I think there's a small mistake @ 1:15
Memory addresses 0x3FFC_0001, 0x3FFC_0002 should be 0x3FFC_0004, 0x3FFC_0008 respectively.
there is a *parameters in the printMessages function declaration. Where is *parameters actually used within the function?
I think one address is only for one byte, 0x3FCC0000 can address only on byte not 4 !!
Where are these Queus made? DDR or RAM?
A thanks from Bangladesh(neighbor country of India)
please do daily one video
I really wish I had time to make 1 video per day ^_^
Are you reading a script?
if no. Then why you are not taking break while talking.
It seems like I am just hearing a continuous tape recorder not a tutorial.
When you start writing the code, it is like reading a script, too much information in a short time, without any proper explanation. Start of the video is somehow better.
I dont understandstand a single use in the program like a 12 old kid in the Mathlesson of an 17 years old kid, where I can find a "littlebit" more beginner friendly totorials?