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.
@ShawnHymel3 жыл бұрын
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.
@HoangMinhNguyen-030715 күн бұрын
did you mean 1 tick, the third parameter of xQueueReceive() ?
@dbl_play3 жыл бұрын
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()) !
@ShawnHymel3 жыл бұрын
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): kzbin.info/www/bejne/nqq9hGWmZtmKY8k. I'll keep the others in mind for future episodes.
@Clark-Mills3 жыл бұрын
Hint for non-blocking keystroke waiting test (not something I have done in the Arduino environment): if (Serial.available() > 0) { c = Serial.read();
@ShawnHymel3 жыл бұрын
Yes! Thanks for the hint. That should help with the challenge :)
@himanshujangra25993 жыл бұрын
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
@ShawnHymel3 жыл бұрын
Good to know there's interest in more STM32 stuff. I'll keep that in mind!
@studentofedison4212 жыл бұрын
❤️❤️❤️❤️❤️❤️❤️
@RicardoPenders3 жыл бұрын
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.
@atmloginvideos3 жыл бұрын
Very useful and interesting content. Thank you for sharing.
@xidameng3 жыл бұрын
Very good content, tho I think we can go into the FreeRTOS src for a bit to explain alittle what happen behind the scene
@thisusernameismine102 жыл бұрын
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'.
@cheesecake6673 жыл бұрын
You guys are so awesome!
@bayareapianist3 жыл бұрын
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?
@ShawnHymel3 жыл бұрын
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.
@bayareapianist3 жыл бұрын
@@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.
@ShawnHymel3 жыл бұрын
@@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.
@MuhammadDaudkhanTV1003 жыл бұрын
So super hit and cool content bro
@bonafide90858 ай бұрын
I like this series, very helpful! Thank you!
@zee-lab-electronics3 жыл бұрын
Nice series Shawn. I have seen that you're going to teach a course embedded ML on coursera. Is that true?
@ShawnHymel3 жыл бұрын
Yes. It went live today :)
@skelstar3 жыл бұрын
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.
@ShawnHymel3 жыл бұрын
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!).
@skelstar3 жыл бұрын
@@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.
@achalasamapriya27013 жыл бұрын
finally...thanks a lot
@siqingzhang80614 ай бұрын
Very good video, thanks a lot!
@embeddedbastler64062 жыл бұрын
Shouldn't the addresses at 1:10 each increment by 4 and not 1? Because the ESP32 uses byte-addressing and not word-addressing.
@alireza983252 жыл бұрын
Superb tutorials! I think there's a small mistake @ 1:15 Memory addresses 0x3FFC_0001, 0x3FFC_0002 should be 0x3FFC_0004, 0x3FFC_0008 respectively.
@manicool2719892 ай бұрын
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?
@kunaalkirankumar69382 жыл бұрын
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
@studentofedison4212 жыл бұрын
A thanks from Bangladesh(neighbor country of India)
@FreshSmog9 ай бұрын
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?
@DukeBambaluc3 жыл бұрын
Love this
@sorooshkeivanfard6383 Жыл бұрын
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?
@hendrikkrack33593 жыл бұрын
Great tutorial!
@statters2 жыл бұрын
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?
@vex123 Жыл бұрын
I think it's more for clarity
@pornpojhanhaboon99602 жыл бұрын
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?
@arunsnair52573 жыл бұрын
Good one
@eslamsayed19473 жыл бұрын
Does the scheduler consider the loop as a task and switch between it and the created task " printMessages " ??
@ShawnHymel3 жыл бұрын
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.
@cth88027 ай бұрын
there is a *parameters in the printMessages function declaration. Where is *parameters actually used within the function?
@ARUNKUMAR-ql1di3 жыл бұрын
please do daily one video
@ShawnHymel3 жыл бұрын
I really wish I had time to make 1 video per day ^_^
@othmanechaima847411 ай бұрын
I think one address is only for one byte, 0x3FCC0000 can address only on byte not 4 !!
@tahirsengine Жыл бұрын
Where are these Queus made? DDR or RAM?
@asaduzzamanabrar60012 жыл бұрын
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.
@deryorsh2 жыл бұрын
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?
@all.n.19 ай бұрын
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.