Introduction to RTOS Part 3 - Task Scheduling | Digi-Key Electronics
ฝัง
- เผยแพร่เมื่อ 20 พ.ค. 2024
- The RTOS scheduler decides which task to run on a recurring basis, and some tasks can interrupt and run before other tasks in a process known as “preemption.”
The solution to the challenge in the video can be found here: www.digikey.com/en/maker/proj...
CORRECTION at 2:37: A higher priority task in FreeRTOS will immediately preempt other tasks and run if it is made ready. It does not wait for the next tick to run. Thanks to @G-aurav B-hattarai for pointing this out!
In this video, we examine how the FreeRTOS scheduler makes a decision at every tick (recurring timer interval) to determine which task to run for the remainder of the tick. With a single-core processor, this time-slicing allows tasks to run in a fashion that appears to be concurrent to the user.
Tasks with higher priority are chosen to run before tasks with lower priority. However, not all tasks need to be run. Only tasks in the “ready” or are already in the “running” state can be chosen to run next. A task may put itself or another task in a “blocked” state by using one of the appropriate blocking functions, like vTaskDelay(). Tasks that are waiting for an external event, such as a free semaphore or a serial transmission, may also enter the blocked state. The expiration of a timer or received resource may move a task from the “blocked” state to the “ready” state.
Additionally, a task may put another task into the “suspended” state with the vTaskSuspend() function. This prevents the suspended task from running until another task calls the vTaskResume() function on the suspended task.
Note that tasks with equal priority are executed in a round-robin fashion.
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:
Introduction to RTOS Part 3 - Task Scheduling -www.digikey.com/en/maker/proj...
Related Articles:
Getting Started with STM32 and Nucleo Part 3 - 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 - วิทยาศาสตร์และเทคโนโลยี
![🔴 [TRỰC TIẾP] U20 VIỆT NAM VS U20 THÁI LAN | Cúp VTV9 - Bình Điền 2024 | JET STUDIO](http://i.ytimg.com/vi/tdmZlw-XJJI/mqdefault.jpg)
Seriously great content here. Give this guy a raise. Well earned.
I think it is probably going to be one of the best FreeRTOS tutorials or maybe even the best.
Thanks for doing this series in chunks.
I will have to let my brain process this episode and the prior episode in an equal priority round robin manner for a while until it is pre-empted by the higher priority episode 4 :)
Great course! Was looking for a next video, but it is super fresh. Looking forward to next ones.
Shawn is just amazing on teaching so much simple and clear! Congrats!
Very good stuff, just in time for my FreeRTOS explorations. Please don't stop these video series halfway! :)
Great work! Really happy for this series. Thank you!
Unbelievably ! you explained all of that in details in 10min ! Thank you so much for that great work and explaination.
I can't thank you enough for these super useful contents.
Great series. Looking forward to the next parts
This is definitely the best FreeRTOS tutorial
Solid tutorials. Thank you.
Hi! Great content. Thank you so much for producing these and making them available.
Just a minor correction: on the LED control exercise solution, there's a missing increment 'i++" operator in the buf_len index.
So good, great work and thanks for sharing the code!
What a series!!
IIRC, serial output may also cause a task to be not ready because it can take a tick to wait for the character to be output.
In an RT application, the serial output should be in a task dedicated for the output to that physical device port. Messages are then sent to that task when output is required. That strategy avoids garbled output produced by two or more tasks outputting to the same physical device. The serial output task can wait on a message in a queue so no cycles are burned by it unless there is something to do.
Similarly, some input operations duch as analog input or serial input may block.
Rule of thumb is one task per physical resource. With ADC, there is usually only one converter that has its input multiplexed over several ports. So one task per converter. If you know the hardware well, then you can start the conversion and suspend the task until the conversion is complete, resuming via ISR.
Scheduler may be configured to yield to the next ready task for the remainder of the tick when a task is suspended.
Thanks for the great advice! The idea of using one task per physical device seems very useful. I’m not sure exactly how the ESP32 handles serial output, but I know that on other Arduino boards, it relies on the UART hardware to manage it. So, once you copy your message to a buffer, the rest is non-blocking while the hardware handles outputting the message, byte-by-byte, at the specified baud rate. However, that still doesn’t mean it’s thread-safe, as another task could interrupt the process of copying data to the buffer :)
Thanks for the videos, i find them very informative! I have a question: when the running task calls taskDelay, is the scheduler invoked immediately? If so, isn't that "violating" its 1ms periodicity?
this makes my life easier, since the freeRTOS doc is not for everyone.
Very nice compressed video great
Beautiful video, very helpful to understand the fondamental concepts of RTOS. Thank you ❤️
Most welcome! Glad it helps!
For the solution code, why the serial port only recieve the last number? If I send "123", serial port respond "Updated LED delay to: 3
".
I am facing the same issue
Awesome! Keep it up pretty please!
For the question at the end of the blog:
Try playing around with the priorities of the tasks. What happens if you make the “Toggle LED” task priority 2? Why does everything still work?
What happens if you make the “Read Serial” task priority 2 instead (and leave the toggle task at priority 1)? Why does the LED task stop blinking?
Ans from ChatGPT:
In FreeRTOS, tasks with higher priorities are given precedence in execution. However, lower priority tasks can still run when higher priority tasks are in a blocked state. In your case, even though `toggleLED` has a higher priority, it periodically blocks when waiting using `vTaskDelay()`, allowing `readSerial` to execute. When priorities are swapped, `readSerial` continuously executes, preventing `toggleLED` from running and causing the LED to appear continuously off.
Great full ideas
Thanks for the video =)
Hi, thanks for the great work. I have a question, after writing my answer to this challenge, I copied your answer (just to get the nice formatting) and started to mess around to check things. One of the things I did was to delete the "while(1) { ... }" loop on the ReadSerial() task, thinking that the task would be executed only once after being started by the scheduler, exit, and I would never get a chance to input values. But instead of that, the ESP32 panics! I tried on my code too, almost the same as yours, and same result: works with the "while(1)" loop on ReadSerial(), panics without it. Shouldn't FreeRTOS just exit the task and continue blinking the LED forever, as it would be the only task left running?
Great video
Hi, one question, which ide/tools do you suggest to work with esp32 and implement unit testing, and debugger in the circuit?
Great Video. What happens if the interrupt is still running when it's time for an OS "Tick"? what has highest priority? Assuming OS but then what?
My guess is TASK A -> INT -> OS -> INT -> TASK (A?)
Superb intro to FreeRTOS. One clarification, in the solution to the challenge problem, you are not incrementing the idx variable after reading a byte from serial port. Is it a typo or am I missing something.
1:02 preemptive scheduling
4:30 task states
7:00 vTaskSuspend() and vTaskResume() example
Weird how priority is increasing in these examples, usually lower numbers means higher priority (arm and Linux both do it this way) but here priority 1 runs before priority 0, strange
Yup! High number means high priority in FreeRTOS and low number means high priority in Linux and Arm.
welcome to programming lol
@@nicolaskeroack7860 yeah it's like I'm making a new thing, let me just change all the fundamental conventions you're used to, that should be fun 🤦♂️
There is something weird (for me) happening when task_1 is deleted: Serial port just stops printing to console. I asked ChatGPT and it says the problem is the collision of the serial port access between the tasks, but I don't know really how to solve it.
nice video
What is the priority of the "third" task (void loop()) ?
Hello guys, trying to understand, so the loop() function will be a third task that has highest priority than all the task that we defined?
Is it necessary to check that task_1 handle is != Null because if it is equal to Null then the loop task is what gets deleted?
Very nice video, thank you. It would have been nice if at this stage you would have told us what happens with your own interrupt routine in case it is itself interrupted by a scheduler tick. Because you may write your interrupt code as short as you want, there is always a moment where this will happen.
Good question! Most of the time, I have found that the scheduler tick timer interrupt is at a lower priority than other hardware interrupts. For processors that supported nested interrupts (e.g. NVIC), you'd likely find that your interrupt will take priority over the scheduler (tick timer ISR). I suppose it's possible to set it so the tick timer interrupt is higher priority, though. In that case, I imagine that the tick timer ISR might choose a task to run that would not start running until after your ISR is done. Here's some good info on how the tick timer works: www.freertos.org/implementation/a00011.html
@@ShawnHymel Thank you! I think that the "Interrupted interrupt" is a topic way too often eluded in many courses about interrupts on Arduino. I just found more general notions about interrupted interrupts in this thread: stackoverflow.com/questions/5111393/do-interrupts-interrupt-other-interrupts-on-arduino . Mentioning this because I initially thought that interrupt calls would be "nested", but it is not the case and I believe it is very important to understand this first.
Is there also talk about CANBUS anywhere in here?
Thinks a lot
I checked for a valid taskHandle but when I deleted task_1 my program crashed.
I had to change priority of both task_1 and task_2 to 2 and 3 respectively to get it to work.
there's a bug in your example, in the line 75 you need to increment the idx variable, otherwise it will only return the last character you wrote on the serial, like "400" it will return 0
idx++; // it was idx ; for some reason
Here this code is need to place in the freertos directory then load free rtos code in controller?
Is this right?
Correct me if I am wrong
RTOS is run only on MicroControllers right ?? You meant Single core processor as Microcontroller, Correct ?? Thanks
But if anyone is paying attention, they will tell you that the example won't run as expected, because if we go back to the video and see the priority you've done for each task, we'll see task 2 won't run as well as at the end of the video
Hello i have a question sir does the schedular runs as a task itslef ? If so when exaclty a task Can change state from blocked to running i suppose a part of the main Memory . Also thanks you for thé videos.
Great question! In some operating system, the scheduler could be a task. In FreeRTOS it is simply a timer interrupt service routine (ISR) that runs every time the tick timer overflows (default: 1 ms). The ISR then figures out which task needs to run and sets it to running. For a task to get out of the "blocked" state, some external event must occur. This is something like releasing of a mutex/semaphore or a delay timer expiring. A blocked task may only return to the ready state (or be put in the suspended state). The scheduler (the ISR) looks at the list of ready tasks, determines the highest priority, and chooses it to run. Here is a good article on what is happening in the scheduler: www.freertos.org/implementation/a00011.html Hope that helps!
@@ShawnHymel thanks you !
( 8:56 ) - Despite being warned that BAD THINGS will happen, it seems that we don't need to go too far to see a •vTaskDelete(NULL);• used in earnest: like the solution to exercises for the reader (to kill the 'setup and loop' task there, apparently.) Hmmm. I imagine clarity must be in the docs somewhere - I can't imagine you're deliberately driving it off a cliff there!
I am wording the same, vTaskDelete(task_1); is causing the program to crash.
Thanks for this great stuff. A question at 2:17, what if as the Tast A is blocked (OS in Idle) and at the third tick the Task B and C are in ready state? Will the scheduler let them run in the 3rd tick?
Yes, whenever Task B or C enter into the ready state, the scheduler will let them run. Something that's not shown in the diagram: if Task B and C enter the ready state while Task A is running, the scheduler will interrupt Task A (even not on a tick) to let the higher priority task run (assuming preemption is enabled, which it is by default in the ESP32). This post has a good discussion on how this works: www.freertos.org/FreeRTOS_Support_Forum_Archive/May_2016/freertos_Does_the_highest_priority_task_run_at_all_times_b8195787j.html. Hope that helps!
@@ShawnHymel as each task is a thread (CPU utilization), could several Tasks run at the same Tick (the so called multithreading?)? In other words, is the case in your video the so called 'single threading'?
@@lxzhang4911 You can only run one task at a time in a single-core CPU. If you have a multi-core CPU, you could run several tasks at the same time. In the single-core example that I've shown in the videos, the CPU must split its time between tasks. This is still "multithreading" in a single core.
@@ShawnHymel So in your example is it a RTOS or general purpose OS? Because in your this video (th-cam.com/video/OPrcpbKNSjU/w-d-xo.html&ab_channel=Digi-Key) the example of general purpose OS is quite similar with the example here in this video. It makes me quite confused. I thought in a general purpose OS the OS will not check at each tick if it need to switch context to another task. Is it?
@@lxzhang4911 Most general purpose operating systems (e.g. Linux) still have a scheduler, which is some code that must run periodically in order to determine which task/thread to run next. Usually, this happens at some pre-determined frequency (in Linux, this is determined by the "timeslice" setting). This ends up looking much the same in both GPOS and RTOS cases: there's a small sliver of time in which the OS scheduler must run periodically to determine which task to run for the remainder of the timeslice. Here's a good article about how one such Linux distro handles timeslices: doc.opensuse.org/documentation/leap/archive/42.1/tuning/html/book.sle.tuning/cha.tuning.taskscheduler.html
Small bug in your solution. You need to increment idx in line 75, otherwise, it only accepts the last digit...
thanks bro, i was having this issue with the example then i added the missing "++" on the line 75
HEY...good video.
Nice 8-)
Thanks for this series.
But I need to know the answer of question in the challenge.
Why toggeling is stoped when making the periority of led_toggle is 1 and the other task 2 ??
If you look at the code for the readSerial() task, you'll see that it never uses vTaskDelay(), which means that it will never yield the processor if it is the highest priority task (which is what happens when you set it to priority 2 and the toggleLED() task to priority 1). If it's hogging the processor, the LED task will never run. You either need to make it the same or lower priority than toggleLED() or put a vTaskDelay() in the readSerial() task to force it to yield the processor some of the time. Hope that helps!
@@ShawnHymel Really thanks, Sure it helped. but this will lead me to another question..
is that mean if i have 3 tasks , i must block 2 of them during their execution to enable the third one to be executed?!!
@@eslamsayed8405 It depends on how you set the priority of each of the tasks. If they are all set at the same priority, then the scheduler will execute each one for 1 tick in a round-robin fashion (so they'll all get a chance to run). If one is a higher priority than the other two, then you'll need to make sure that the higher-priority task delays or blocks itself to let the others run. Hope that helps!
@@ShawnHymel OK got it. thanks.
RTOS solves a lot of timing problems.
How the value of task_1 changes from NULL because there isn't any instruction that does so.
Good videos, but now I wonder, the ISR reside in which core? Core 0? Core 1?
The ISR executes in whichever core it was created (attached). So if you attach the ISR to an interrupt in a task in Core 0, it will execute in Core 0. We cover Hardware interrupts in a later episode.
I hope Shawn or anyone could explain to me the output on the Serial terminal at the last Example, where the 2nd Task should interrupt the 1st every 100mSec (10 Times/Sec) This should result in 10 Astrix per every Sentance (as the sentences are printed every 1 Sec) but the output is different and we can see the whole sentence is completely printed most of the times. Why is that?
same doubt
A year later but incase anyone still has the doubt. You must have missed that the loop task suspends and resumes task_2 every 2 seconds as well.
I have used exactly the same code as given in the solution except that I used Serial.parseInt() to get integer value from serial port and the program is not working right and the ESP keeps resetting (watchdog resets in readSerial function). Also it shows that the blink delay was updated but immediately gets set to 0 after and the program crashes. What am I doing wrong?
If you use firefox and copied the code to paste to your IDE; some characters does not appear on Digikey website when Firefox is used. So the problem might be that :D
I am using Arduino UNO. Most of the sketch is the same as the one in the video.
I left the loop function empty for simplicity but there is still an error.
Does anyone know what might cause the characters in msg being replaced by *?
Instead of something like:
Ba*rkadeer brig* Arr booty rum.
some of the characters in msg are replaced by * in my program:
Ba*kadeer brig Arr*booty rum.
Thanks in advance!
Good to know the UNO works with FreeRTOS! I have not tested it yet. The * issue is an odd one that I have not seen. It might have to do with the baud rate of the UART. Could you try slowing it down? Maybe 9600 or even 1200?
@@ShawnHymel Thanks for your reply! I was using 1200 already and I even tried 300 but the output became gibberish. I guess this is why we want one task only to handle serial communication.
Gotem
Hi Shawn. I think you have stopped working on your own channel
By the way, nice video series on FreeRTOS.
I did :( Too much other work for clients in the past few months (I can't really complain about that, though :)
Is FreeRTOS using a cooperative scheduler?
FreeRTOS uses a pre-emptive scheduler by default. However, you can turn off pre-emption (look for a #define of something like portUSE_PREEMPTION) to make it a cooperative scheduler.
Very good series, but in this video the 2nd half was a bit too fast for me, had to re-watched it again)
I agree. Overall video was good though.
Good explanation. But, my dude, you should put a bit of gap between sentences...
pirate ipsum
This guy is just reading a script and not pausing during important moments. He doesn't know the material himself. Sounds very much like the written documents.
Awwww man, Arduino ruined it. You just needed to use the IDF and these videos would've been great. So sad.
#include
#include
#if CONFIG_FREERTOS_UINCORE
static const BaseType_t app_cpu = 0;
#else
static const BaseType_t app_cpu = 1;
#endif
#define led_pin (int)22
String ledDelay = "";
static int ledDelayInt = 500;
// Task 1 :: Set the Serial Port for listening the data
String serialData(void);
void ListenSerialPort(void *parameter) {
while (true) {
ledDelay = serialData();
}
}
// Task 2 :: Convert the string into integer
void StringToInt(void *parameter) {
while (true) {
if(ledDelay != "")
ledDelayInt = ledDelay.toInt();
Serial.print("Toggle Delay = ");
Serial.println(ledDelayInt);
}
}
void ledBlink(void *parameter){
while(true){
digitalWrite(led_pin,HIGH);
vTaskDelay(ledDelayInt/portTICK_PERIOD_MS);
digitalWrite(led_pin,LOW);
vTaskDelay(ledDelayInt/portTICK_PERIOD_MS);
}
}
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
pinMode(led_pin,OUTPUT);
vTaskDelay(10 / portTICK_PERIOD_MS);
xTaskCreatePinnedToCore(
ListenSerialPort,
"ListenSerialPort",
1024,
NULL,
1,
NULL,
app_cpu
);
xTaskCreatePinnedToCore(
StringToInt,
"StringToInt",
1024,
NULL,
1,
NULL,
app_cpu
);
xTaskCreatePinnedToCore(
ledBlink,
"ledBlink",
1024,
NULL,
1,
NULL,
app_cpu
);
}
void loop() {
// put your main code here, to run repeatedly:
}
String serialData(void){
String str = "";
while (Serial.available() > 0) {
vTaskDelay(20/portTICK_PERIOD_MS);
char ch;
ch = (char)Serial.read();
if (ch == '
' || ch == '
') {
break;
}
str += ch;
}
return str;
}
😍😍😍