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.

Great course! Was looking for a next video, but it is super fresh. Looking forward to next ones.

Great work! Really happy for this series. Thank you!

Very good stuff, just in time for my FreeRTOS explorations. Please don't stop these video series halfway! :)

I can't thank you enough for these super useful contents.

Shawn is just amazing on teaching so much simple and clear! Congrats!

Unbelievably ! you explained all of that in details in 10min ! Thank you so much for that great work and explaination.

Great series. Looking forward to the next parts

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 :)

This is definitely the best FreeRTOS tutorial

Solid tutorials. Thank you.

So good, great work and thanks for sharing the code!

I tried the exercise using switch case, thanks Shawn for such amazing course!

What a series!!

Beautiful video, very helpful to understand the fondamental concepts of RTOS. Thank you ❤️

Small bug in your solution. You need to increment idx in line 75, otherwise, it only accepts the last digit...

Thank You So Much for This Amazing Video Video Lecture - 3 Completed

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.

Very nice compressed video great

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.

Awesome! Keep it up pretty please!

this makes my life easier, since the freeRTOS doc is not for everyone.

Great full ideas

Thanks for the video =)

Great video

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

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?

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.

Hi, one question, which ide/tools do you suggest to work with esp32 and implement unit testing, and debugger in the circuit?

Sehr gut

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?

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.

nice video

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.

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?)

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?

What is the priority of the "third" task (void loop()) ?

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

Thinks a lot

Is there also talk about CANBUS anywhere in here?

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?

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

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

why is that (void *parameter) used? What work it does?

Nice 8-)

RTOS is run only on MicroControllers right ?? You meant Single core processor as Microcontroller, Correct ?? Thanks

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.

HEY...good video.

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

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.

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.

Good videos, but now I wonder, the ISR reside in which core? Core 0? Core 1?

How the value of task_1 changes from NULL because there isn't any instruction that does so.

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?

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 ??

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?

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?

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!

RTOS solves a lot of timing problems.

1:02 preemptive scheduling 4:30 task states 7:00 vTaskSuspend() and vTaskResume() example

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

Is FreeRTOS using a cooperative scheduler?

Hi Shawn. I think you have stopped working on your own channel By the way, nice video series on FreeRTOS.

Gotem

Very good series, but in this video the 2nd half was a bit too fast for me, had to re-watched it again)

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.