FreeRTOS has a few tricky parts with it. For the most part it is very straight forward. Interrupts, stacks, ISA/pipeling, etc. create problems in some cases. (Resource management) DMA, ram functions, caches, etc. are also capable of driving certain issues. (Networking) Certain memory things like data structures and UMA coherency/concurrency can appear. (Scheduling and Algorithms) Note I left a few things implied. Now most of this is mitigable with processes aka pipes and malloc. (These drive down performance and drive up costs.) Same rough story you have with processors but with different interfaces and price points.
Nice video. I have a few examples of FreeRTOS projects on my channel too on the Pico and Pico-W. I think FreeRTOS can be scary but in fact is quite straightforward. Once you start using on a Pico-W with LwIP it enables so much as you gain a task looking after the IP stack and providing Sockets.
Thank you @DrJonEA for your comment. I had exactly the same feeling about FreeRTOS when I first saw it, but quickly realised that it's really simple to use. Funny you mentioned PicoW and lwIP, because last year I built a simple contraption using these just for fun. Maybe I'll show it in a future video as it may be a good starting project for people wanting their PicoW to use the Internet very easily. I used lwIP together with mbedTLS for HTTPS.
Nice vídeo introducing FreeRTOS. Can It handle interrupts as well? I have a project that needs read USB keyboard input keys and send It to a LCD after some processing, using the RPI2040. The main problem is the firmware is getting slow as far I send more keys to processing and display them (It's a single thread).
Yes, it does support interrupts as @riaganbogenspanner just pointed out. You still implement your interrupt handler yourself. There are versions of some system function calls with the "FromISR" postfix, which are intended to be called from the interrupt handlers specifically. What's great about FreeRTOS is that it has something called "Direct To Task Notifications" which can notify the task of your choice about an event, which effectively switches context from the interrupt directly to that task to minimise latency.
@@helmutzollner5496 Hi, I'm using the main USB Port with TinyUSB lib provided by RPi Pico SDK. It works with interrupts (Idk If It is software or hardware one).
It would be interesting to produce the three tasks using arguments, making sure the code is re-entrant. If coders are to write for multi-tasking systems, then it's useful to learn the rules about making functions re-entrant and, for that matter, to make them thread-safe. In any event, a very useful intro into the basics. Many, many years ago I had to write an embedded system using a Z80 in assembler code and that was fully interrupt driven with pre-emptive multi-tasking and had seven tasks. I had to write a code to do things like message passing via buffers, mutex control, timer routines and so on. It was fun, but would be so much easier with something like RTOS. nb. is RTOS fully pre-emptive, or does it rely on calling system routines for a task to give up control?
Thank you very much @TheEulerID. Yes, this was just a trivial example just to introduce the idea, so I barely scratched the surface (intentionally). FreeRTOS is fully pre-emptive and switches context on both: the system calls and the system tick interrupt. As @Graham_Wideman correctly pointed out, pre-emption can be switched off (never tried that), so I assume, if you did that, the context switch would only happen on a system call. BTW, in the "portable/ThirdParty/Community-Supported-Ports" directory of the FreeRTOS-Kernel you can also find a port for the Z80 as well :-)
@@Graham_Wideman I did a bit more research, and FreeRTOS does have full pre-emption, but it's optional. I can see why, as using a co-operative MT system does help mask some potential subtle programming errors, especially if you have code shared between functions and haven't been rigorous in making sure its re-entrant and thread safe.
@@SladorSoft Thanks. The video gave me enough info to see how it could be used. A few years ago I wrote some software to drive a WW II Battle of Britain sector slave clock (a very rare thing) using an Arduino, and had a whole bunch of timer-related things, like de-bouncing switches, driving timing pulses for the slave clock and maintaining a user interface. The whole process of writing it as a single master-loop whilst keeping multiple timer functions going and polling for user input was horrible. The multi-tasking approach is so much easier. I'm thinking of re-implementing it on a Pi Pico W with a more accessible used interface and using Internet time servers and so on, and I will definitely be looking at using FreeRTOS for the purpose as it looks ideal for my needs.
For that purpose the pico implements something better, the PIO units, you could use the eight state machines to control each one a different software defined SPI port.
Thanks @crckdns! As @drgusman just said, the PIO is a much better choice to do that. You may want to look at my older video were I did exactly that. Some viewers pointed out that my solution there wasn't perfect as it was not keeping all the timings right, but it is still a good starting point I hope.
The OS itself is very small - just a few .c files. The build takes time because of the components of the Pico SDK. Not only need it to build the libraries used in your project, but also a few tools used on the way, like for example the PIO assembler. The good news it that it only does that first time - consequent builds a much quicker.
That is a good question. I didn't answer it in this video as I just wanted to quickly introduce it to the viewers. RTOS stands for: "Real-Time Operating System". The "real-time" part says, that it is designed for timely processing events and switching threads. For example, in simple words, if there is one thread doing something and another thread with higher priority waiting for processing, you know exactly how long at most it will take to process the latter (this time is defined by the system tick). There is more to it, like for example, the distinction between hard- and soft- RTOSes etc. But in general RTOS gives some guarantees in terms of timing.
Yes, I've heard the news, but I've never used ThreadX before, honestly. I'm going to have a look and maybe share my experience here in the future. Thanks!
@@SladorSoftThe interesting part of Threadx is its picokernel. There is no single kernel. The core kernel, the filesystem driver and network stack all run on base hardware with their own application specific kernels independent of one another. Same with the optional GUI component.
I'll put in a vote for more on FreeRTOS!
A great introduction to FreeRTOS. Just enough info to get started and begin experimenting. Will definitely be taking a look at your project.
FreeRTOS has a few tricky parts with it. For the most part it is very straight forward.
Interrupts, stacks, ISA/pipeling, etc. create problems in some cases. (Resource management) DMA, ram functions, caches, etc. are also capable of driving certain issues. (Networking) Certain memory things like data structures and UMA coherency/concurrency can appear. (Scheduling and Algorithms) Note I left a few things implied.
Now most of this is mitigable with processes aka pipes and malloc. (These drive down performance and drive up costs.) Same rough story you have with processors but with different interfaces and price points.
T es incroyable mon reuf. Sache le
Merci beaucoup monsieur ;-)
Nice video. I have a few examples of FreeRTOS projects on my channel too on the Pico and Pico-W. I think FreeRTOS can be scary but in fact is quite straightforward. Once you start using on a Pico-W with LwIP it enables so much as you gain a task looking after the IP stack and providing Sockets.
Thank you @DrJonEA for your comment. I had exactly the same feeling about FreeRTOS when I first saw it, but quickly realised that it's really simple to use. Funny you mentioned PicoW and lwIP, because last year I built a simple contraption using these just for fun. Maybe I'll show it in a future video as it may be a good starting project for people wanting their PicoW to use the Internet very easily. I used lwIP together with mbedTLS for HTTPS.
@@SladorSoft That sounds great. Perhaps we can do a few cross overs between our two channels.
Nice vídeo introducing FreeRTOS. Can It handle interrupts as well? I have a project that needs read USB keyboard input keys and send It to a LCD after some processing, using the RPI2040. The main problem is the firmware is getting slow as far I send more keys to processing and display them (It's a single thread).
Yes it can. Eg: You can make tasks wait for events. And than throw a event in an interruptq
Yes, it does support interrupts as @riaganbogenspanner just pointed out. You still implement your interrupt handler yourself. There are versions of some system function calls with the "FromISR" postfix, which are intended to be called from the interrupt handlers specifically.
What's great about FreeRTOS is that it has something called "Direct To Task Notifications" which can notify the task of your choice about an event, which effectively switches context from the interrupt directly to that task to minimise latency.
I am also interested in such a project. Are you using the main USB port, or are you bit banging another one via GPIO?
@@helmutzollner5496 Hi, I'm using the main USB Port with TinyUSB lib provided by RPi Pico SDK. It works with interrupts (Idk If It is software or hardware one).
@@cleverson_sa_ thank you.
It would be interesting to produce the three tasks using arguments, making sure the code is re-entrant. If coders are to write for multi-tasking systems, then it's useful to learn the rules about making functions re-entrant and, for that matter, to make them thread-safe.
In any event, a very useful intro into the basics. Many, many years ago I had to write an embedded system using a Z80 in assembler code and that was fully interrupt driven with pre-emptive multi-tasking and had seven tasks. I had to write a code to do things like message passing via buffers, mutex control, timer routines and so on. It was fun, but would be so much easier with something like RTOS.
nb. is RTOS fully pre-emptive, or does it rely on calling system routines for a task to give up control?
"nb. is RTOS fully pre-emptive,?" I don't know, but at 15:22 we see a define for configUSE_PREEMPTION.
Thank you very much @TheEulerID. Yes, this was just a trivial example just to introduce the idea, so I barely scratched the surface (intentionally). FreeRTOS is fully pre-emptive and switches context on both: the system calls and the system tick interrupt. As @Graham_Wideman correctly pointed out, pre-emption can be switched off (never tried that), so I assume, if you did that, the context switch would only happen on a system call.
BTW, in the "portable/ThirdParty/Community-Supported-Ports" directory of the FreeRTOS-Kernel you can also find a port for the Z80 as well :-)
@@Graham_Wideman I did a bit more research, and FreeRTOS does have full pre-emption, but it's optional. I can see why, as using a co-operative MT system does help mask some potential subtle programming errors, especially if you have code shared between functions and haven't been rigorous in making sure its re-entrant and thread safe.
@@SladorSoft Thanks. The video gave me enough info to see how it could be used. A few years ago I wrote some software to drive a WW II Battle of Britain sector slave clock (a very rare thing) using an Arduino, and had a whole bunch of timer-related things, like de-bouncing switches, driving timing pulses for the slave clock and maintaining a user interface. The whole process of writing it as a single master-loop whilst keeping multiple timer functions going and polling for user input was horrible. The multi-tasking approach is so much easier.
I'm thinking of re-implementing it on a Pi Pico W with a more accessible used interface and using Internet time servers and so on, and I will definitely be looking at using FreeRTOS for the purpose as it looks ideal for my needs.
Great RTOS introduction!
Was thinking about trying controlling multiple ws2812b led strips over spi at multiple gpio at same time on the rpi pico!
For that purpose the pico implements something better, the PIO units, you could use the eight state machines to control each one a different software defined SPI port.
Thanks @crckdns! As @drgusman just said, the PIO is a much better choice to do that. You may want to look at my older video were I did exactly that. Some viewers pointed out that my solution there wasn't perfect as it was not keeping all the timings right, but it is still a good starting point I hope.
... why does it take so long to build such a simple .c ?
does it recompile the entire OS? How big is that thing?
The OS itself is very small - just a few .c files. The build takes time because of the components of the Pico SDK. Not only need it to build the libraries used in your project, but also a few tools used on the way, like for example the PIO assembler. The good news it that it only does that first time - consequent builds a much quicker.
Protogens go beep boop
What is RTOS?
That is a good question. I didn't answer it in this video as I just wanted to quickly introduce it to the viewers. RTOS stands for: "Real-Time Operating System". The "real-time" part says, that it is designed for timely processing events and switching threads. For example, in simple words, if there is one thread doing something and another thread with higher priority waiting for processing, you know exactly how long at most it will take to process the latter (this time is defined by the system tick). There is more to it, like for example, the distinction between hard- and soft- RTOSes etc. But in general RTOS gives some guarantees in terms of timing.
FreeRTOS on rp2040 very interesting
Microsoft Threads has been rereleased as Eclipse Threads under the MIT License.
*Threadx
Yes, I've heard the news, but I've never used ThreadX before, honestly. I'm going to have a look and maybe share my experience here in the future. Thanks!
@@SladorSoftThe interesting part of Threadx is its picokernel. There is no single kernel. The core kernel, the filesystem driver and network stack all run on base hardware with their own application specific kernels independent of one another. Same with the optional GUI component.