Introduction to RTOS Part 5 - Queue | Digi-Key Electronics

preview_player
Показать описание
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.

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:

Related Videos:

Related Project Links:

Related Articles:

Learn more:

Рекомендации по теме
Комментарии
Автор

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.

GrahamStw
Автор

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()) !

dbl_play
Автор

Hint for non-blocking keystroke waiting test (not something I have done in the Arduino environment):
if (Serial.available() > 0) {
c = Serial.read();

Clark-Mills
Автор

Shouldn't the addresses at 1:10 each increment by 4 and not 1? Because the ESP32 uses byte-addressing and not word-addressing.

embeddedbastler
Автор

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

himanshujangra
Автор

Very useful and interesting content.
Thank you for sharing.

atmloginvideos
Автор

I like this series, very helpful! Thank you!

robotics_and_stuff
Автор

Nice series Shawn.
I have seen that you're going to teach a course embedded ML on coursera. Is that true?

zee-lab-electronics
Автор

Very good content, tho I think we can go into the FreeRTOS src for a bit to explain alittle what happen behind the scene

xidameng
Автор

I'm still having a little bit of trouble understanding how the queue resolves the previously mentioned issue of storing 64-bit number to memory. Say Task A is trying to write 64-bit data to the queue, I assume it would still have to do 2 writes to store the full 64-bit number into the queue (in 2 of its cells). But what would prevent Task C from also writing to the queue such that the way the data series ends up being stored in the queue is: First half of 64-bit data of Task A at the head of the queue, then 32-bit data from Task C, then Second half of 64-bit data from Task A? Somehow Task B would need to be able to distinguish each data stored in the queue as having come from either Task A or Task C if it wants to "reclaim" the 64-bit data from Task A right?

manicool
Автор

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.

RicardoPenders
Автор

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.

skelstar
Автор

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?

bayareapianist
Автор

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'.

thisusernameismine
Автор

Superb tutorials!
I think there's a small mistake @ 1:15
Memory addresses 0x3FFC_0001, 0x3FFC_0002 should be 0x3FFC_0004, 0x3FFC_0008 respectively.

alireza
Автор

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?

FreshSmog
Автор

i got my challenge code to work, but i like your solution much more. However, i did note i kept getting stack canary panics on the CLI queue. These seem to go away if i dropped the buf_len from the 255 to a more modest size say 20-50.

MultigrainKevinOs
Автор

Does the scheduler consider the loop as a task and switch between it and the created task " printMessages " ??

eslamsayed
Автор

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?

pornpojhanhaboon
Автор

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?

statters