GUYS! I FIXED MY PICO AND THE EXAMPLE! Inside the task code, I forgot to put the tasks in an infinite loop. Because of this, the blink only executes once, and the board appears as though its crashing. I made both of those tasks infinite loops and the board came back to life (was never dead xd) and behaved as expected. Thanks to @max from Discord for finding this bug
Found it the hard way, that if the task finish (without deleting itself), it crashes the whole system (i.e. I imagine the scheduler never gets the execution back) ;-)
@@LowLevelTV haha, I meant, "I found it the hard way" too .... But OK, it's better if smart people say they are idiots, than when idiots think they are geniuses .. ;-)
The rp2040 on the pi pico has PIO's that can do this. They're like independent cores that manage gpio pins for you. Using the PIO assembly code you can implement just about any protocol. In this case one PIO to blink the LEDs in sync with the clock, maybe add an interupt for the button. Then one PIO for the serial bus. Any pin can go with any PIO (kinda). You can then do what you need to inside of your main program loop and not worry about timing. The rp2040 is neat.
That's not the point. The point is that there are tasks you may want to run concurrently, that the PIOs CAN'T do. This was a blinking LED EXAMPLE. And don't tell me that the RP4020 has two cores, because then what do you do when you have THREE things to run simultaneously?
I read about this too! But i always wondered like, how would this fit into a development scenario? like how/where would i use these features? if I'm trying to stick to a reasonable, modifiable codebase.. where on earth am i going to find it appropriate to write assembly in my c++ and make it all seamless and portable with a larger project? Like it always seems so easy to throw the asm example in and go "oh that's neat!" but how do people juggle all that when they have a whole system to think about :
@@kenwood_9474 how about implementing CANbus on PIO so you don't need an external chip to do it? or VGA, LED 1-Wire, etc. That's what I've used the PIO for so far.
@@zachbrown7272 Yeah but i mean like implementation wise in a larger project, not like "x feature" where do you put assembly code in your project?! XD What framework would you use? can you even use a framework when you require such low level access? Thats what i mean by implementation.
i've done a bit of RTOS on older PICs. Now returning to the concept for some robotics. I hope you will cover what might be possible with FreeRTOS on one core and more linear C code on the other core of the pico. Also, i am really liking the OpenOCD/swd/GDB setup with rpi pico, pretty much the best debug capabilities i've ever had. However, i remember having very difficult time debugging RTOS code in earlier days. Hope you can cover some practical RTOS debugging with GDB and dual core. Thanks for video!!
What really sucks (even worse than completely frying it to death) is if only a single subsystem on the chip gets damaged but everything else still works fine, so you do not notice that but get funny bugs :)
As it seems happened with the maker of the video, I usually find that I didn't really fry the microcontroller; I just put it into a state that the USB or serial port method of programming isn't able to deal with, which is solved by hooking it up to a proper programmer. In almost all cases, using an SPI or JTAG based programmer (which can be made out of yet another cheap dev board) clears things up.
@Low Level Learning, Awesome tutorials!!!!! Thank you. A suggestion: Allegedly, there is now Symmetric Multiprocessing Branch of FreeRTOS available for RP2040 (=RTOS on both cores), would be nice to show how to enable it ...
@@LowLevelTV yep, that would be nice... I didn't have patience with it. But I managed to run 1 RTOS on each core simultaneously (just some simple blinking), surprisingly it worked, but 1) it's not the same thing and 2) probably asking for troubles (race conditions) since they share memory etc and don't know when it breaks
A simpler solution than using an RTOS is to use a Parallax Propeller or P2 which each have 8 cores and programmable pins (any pin can be serial, spi, i2c, audio, custom, etc). In other words, it's like having an RTOS built into hardware. Also, the determinism required for signal generation and receipt (including custom signals) can be rock solid because of programming without interrupts and a system clock register that is common across all cores.
An IDE is only just that - an Integrated Development Environment. It is not the IDE's fault if your code is inefficient. You can use a horrible resource hog of an IDE to create beautiful code, because that code does not need to run under the IDE, and does not need to load all of the libraries that the IDE requires. You are barking up the wrong tree.
Hi there is a big question in me about Freertos! Imaging if we have 3 functions and compiler needs to run every function in 1us so all functions needs 3us to run Can Freertos do all of these 3 functions just in 1us and same time?
I didn't see any configuration changes to indicate multiple cores (which may also need some RP2040-specific code for communicating between cores). I'm guessing this is all running on a single core.
Yup! This all runs in one core. You probably could get it multicore ready, you'd just need to implement some synchronization mechanisms to keep it safe.
I think, all the scheduling done by processor for user programs if not specified , so same goes for this program as well, if not specified it will be run on multiple processors without asking along with memory management, unless you want to do your own scheduling. *I'm a noob* *Plz forgive my foolishness if i am wrong.*
I'm disconnecting the USB cable at my computer and holding the BOOTSEL button when I plug it back in. This is my ONLY complaint about the Pi Pico: the lack of a RESET button D:
@@LowLevelTV Oh, I thought you had found a better hack that I don't know about. If you are not aware of it you can connect a button to the ground pin and the 3v run pin to make a reset button.
If you use TinyUSB (included in the SDK, and enabled if you enable TTY over USB) you can just "picotool load -f" and it automatically reboots the Pico to bootsel and flashes it.
Answer to your opening question: I'd write a round-robin core that would do the job just as well without all the nightmares of pre-emption and the pretence that "everything would just work like magic" which unless you are very careful it won't, but in a way that is horrendous to debug. And the architecture would scale just fine. (also "operating system" in the title is disingenuous as it will typically be interpreted as something like linux - should say "RTOS")
@Low Level Learning, so you didn't actually brick your raspberry by putting the LED in the wrong way? i was wondering if that was actually possible? I'm just starting out with this stuff and this seems exactly like the sort of thing I would do :D
@@LowLevelTV phew, I was thinking, I need to buy a couple of extra units, just in case I start bricking things :D haha, although I am quite interested to try FreeRTOS and connect multiple boards together and see if I can use I2C to transmit information between them, using each individual board to do different kinds of processing and use I2C to send the results between the cpu's. If you know what I mean? That sounds an interesting project.
Common misconception and a typo; real-time OS does not necessarily mean executing tasks concurrently. Only, scheduled-based, and guarenteed execution (and, finishing ..) in a pre-determined time range).
you should check if the board is really burned, and redo the video, it is not a recommended practice since you notice a beginner's error in electronics
More than one Microcomputer used BASIC as it's OS, and you already have the Micropython interpreter that should easily be at least as fully functional.
BASIC is a language. Micropython is a language. FreeRTOS is an operating system which is intended to simplify the design of more complicated systems. Blinking LEDs doesn't really show off its strengths.
Interesting. It makes programing easier but what about the overhead? I had to laugh that you only had one pico lying around despite spending so much time on it. Especially these days I order a lot more if it's a universal part. I needed one pico but ordered 10.
You are making assumptions on how the sleep function works. Most time libraries use a central time count that keeps a count of microseconds, or hundreds of microseconds, or some other constant unit of time, and has retriggerable sleep functions. That is, rather than just calling a function that goes to sleep for 1 second from now, you keep resetting an alarm for so many system clock ticks from the last alarm. So if you start a 1-second loop counter at system clock 123000 milliseconds, then when your thread gets that alarm event, you reset the alarm to 124000 milliseconds, then 125000, and so on. It's really up to the programmer - you can either let the blinks free run, if you really don't care, or you set it up so they can stay in sync, if that's important to you. Or to put it another way, just because you can't imagine a planet where blinking out of sync is acceptable, does not mean that such a planet does not exist.
GUYS! I FIXED MY PICO AND THE EXAMPLE!
Inside the task code, I forgot to put the tasks in an infinite loop. Because of this, the blink only executes once, and the board appears as though its crashing. I made both of those tasks infinite loops and the board came back to life (was never dead xd) and behaved as expected.
Thanks to @max from Discord for finding this bug
Ahhh the ol' forgot to put it in a loop trick hey
Found it the hard way, that if the task finish (without deleting itself), it crashes the whole system (i.e. I imagine the scheduler never gets the execution back) ;-)
@@lighthunt yeah im just an idiot XD
@@LowLevelTV haha, I meant, "I found it the hard way" too .... But OK, it's better if smart people say they are idiots, than when idiots think they are geniuses .. ;-)
I have found myself out of the loop thing using a debugger and googled the error message.
The rp2040 on the pi pico has PIO's that can do this. They're like independent cores that manage gpio pins for you. Using the PIO assembly code you can implement just about any protocol. In this case one PIO to blink the LEDs in sync with the clock, maybe add an interupt for the button. Then one PIO for the serial bus. Any pin can go with any PIO (kinda). You can then do what you need to inside of your main program loop and not worry about timing. The rp2040 is neat.
That's not the point. The point is that there are tasks you may want to run concurrently, that the PIOs CAN'T do. This was a blinking LED EXAMPLE. And don't tell me that the RP4020 has two cores, because then what do you do when you have THREE things to run simultaneously?
I'd just buy a second pico so then I have 4 cores.
I read about this too! But i always wondered like, how would this fit into a development scenario? like how/where would i use these features? if I'm trying to stick to a reasonable, modifiable codebase.. where on earth am i going to find it appropriate to write assembly in my c++ and make it all seamless and portable with a larger project?
Like it always seems so easy to throw the asm example in and go "oh that's neat!" but how do people juggle all that when they have a whole system to think about :
@@kenwood_9474 how about implementing CANbus on PIO so you don't need an external chip to do it? or VGA, LED 1-Wire, etc. That's what I've used the PIO for so far.
@@zachbrown7272 Yeah but i mean like implementation wise in a larger project, not like "x feature" where do you put assembly code in your project?! XD What framework would you use? can you even use a framework when you require such low level access? Thats what i mean by implementation.
i've done a bit of RTOS on older PICs. Now returning to the concept for some robotics. I hope you will cover what might be possible with FreeRTOS on one core and more linear C code on the other core of the pico. Also, i am really liking the OpenOCD/swd/GDB setup with rpi pico, pretty much the best debug capabilities i've ever had. However, i remember having very difficult time debugging RTOS code in earlier days. Hope you can cover some practical RTOS debugging with GDB and dual core. Thanks for video!!
Frying a dev board is one of most hated experiences for me in the electronics field! Thanks for the tutorial.
What really sucks (even worse than completely frying it to death) is if only a single subsystem on the chip gets damaged but everything else still works fine, so you do not notice that but get funny bugs :)
always buy in bulk
As it seems happened with the maker of the video, I usually find that I didn't really fry the microcontroller; I just put it into a state that the USB or serial port method of programming isn't able to deal with, which is solved by hooking it up to a proper programmer. In almost all cases, using an SPI or JTAG based programmer (which can be made out of yet another cheap dev board) clears things up.
Great stuff, I’m super interested in freeRTOS and love all the pico videos, thanks!
Man, your vids are really great and helpful! Please just don't stop uploading!!!
Glad you like them!
Thanks for the FreeRTOS tutorial! Can you please post a follow-up video showing the results on the Pico? We need closure. 😁
Super useful intro. Thanks!
@Low Level Learning, Awesome tutorials!!!!! Thank you.
A suggestion: Allegedly, there is now Symmetric Multiprocessing Branch of FreeRTOS available for RP2040 (=RTOS on both cores), would be nice to show how to enable it ...
Thanks for the tip!
@@LowLevelTV yep, that would be nice... I didn't have patience with it. But I managed to run 1 RTOS on each core simultaneously (just some simple blinking), surprisingly it worked, but 1) it's not the same thing and 2) probably asking for troubles (race conditions) since they share memory etc and don't know when it breaks
@@lighthunt why are my finances the business of theirs
@@Stopinvadingmyhardware I have no idea about your fiance. In other words, WHAT?
@@lighthunt The Pico SDK has constructs for SMP; mutex and critical section calls, etc.
my new favourite programming channel.
Nice, a short and sweet tutorial -- will take some time to absorb ;-)
Enjoy!
A simpler solution than using an RTOS is to use a Parallax Propeller or P2 which each have 8 cores and programmable pins (any pin can be serial, spi, i2c, audio, custom, etc). In other words, it's like having an RTOS built into hardware. Also, the determinism required for signal generation and receipt (including custom signals) can be rock solid because of programming without interrupts and a system clock register that is common across all cores.
That's lazy, just get an FPGA and include as many cores as you have LEDs to blink!
Pico has 2 PIO blocks, each with 4 state machines, for a total of 8 little cores.
nice intro, please bring more tutorials on freeRTOS.
Great! Exactly what I was looking for!
great video. Do you know if the two tasks run on separate cores and how to enforce this?
TH-cam needs more stuff like this over bullshit Windows based IDEs that are 2Gb+
An IDE is only just that - an Integrated Development Environment. It is not the IDE's fault if your code is inefficient. You can use a horrible resource hog of an IDE to create beautiful code, because that code does not need to run under the IDE, and does not need to load all of the libraries that the IDE requires. You are barking up the wrong tree.
Any cool projects using FreeRTOS? Do tell ;)
I use it to run my customized firmware on my pacemaker xD
LwIP MQTT and FreeRTOS? :)
@@jochen_schueller balls of steel.
Could you make a video about working with MicroPython in VS Code with the Raspberry Pi Pico?
Many thanks. it helped alot.
Hi there is a big question in me about Freertos!
Imaging if we have 3 functions and compiler needs to run every function in 1us so all functions needs 3us to run
Can Freertos do all of these 3 functions just in 1us and same time?
Hi this is awesome where can I find more information on FRTOS? I'm new to RPi Pico. Thank you Don
Great video!
Glad you enjoyed it
Can we make Gateway using RPi Pico, FreeRTOS, Node-Red ?
I didn't see any configuration changes to indicate multiple cores (which may also need some RP2040-specific code for communicating between cores). I'm guessing this is all running on a single core.
Yup! This all runs in one core. You probably could get it multicore ready, you'd just need to implement some synchronization mechanisms to keep it safe.
I think, all the scheduling done by processor for user programs if not specified , so same goes for this program as well, if not specified it will be run on multiple processors without asking along with memory management, unless you want to do your own scheduling.
*I'm a noob* *Plz forgive my foolishness if i am wrong.*
@@LowLevelTV Pico SDK has all the multicore calls.
Thank you very much!
You're welcome!
How are you rebooting the pico into programing mode? It doesn't look like you are pulling out the plug every time. Are you using a reset button?
I'm disconnecting the USB cable at my computer and holding the BOOTSEL button when I plug it back in. This is my ONLY complaint about the Pi Pico: the lack of a RESET button D:
@@LowLevelTV Oh, I thought you had found a better hack that I don't know about. If you are not aware of it you can connect a button to the ground pin and the 3v run pin to make a reset button.
I've been meaning to do that.... I've just been too lazy to order the button :D
@@LowLevelTV May be using USB hub that built-in with individual on/off switch can reduce the frequency of unplug/plug back for each reset ...
If you use TinyUSB (included in the SDK, and enabled if you enable TTY over USB) you can just "picotool load -f" and it automatically reboots the Pico to bootsel and flashes it.
What if i tell you, that freertos runs even on atmega328p ? 1$ chip (hehe)
can you add to this tutorial by making a part 2 covering uart?
Does free RTOS utilize both rp2040 cores?
Answer to your opening question: I'd write a round-robin core that would do the job just as well without all the nightmares of pre-emption and the pretence that "everything would just work like magic" which unless you are very careful it won't, but in a way that is horrendous to debug. And the architecture would scale just fine. (also "operating system" in the title is disingenuous as it will typically be interpreted as something like linux - should say "RTOS")
it's not misleading, it is an operating system, a system which operates. if someone can't grasp that concept that's their problem
any way to have a raspberry pi to act as a storage device and run a program?
What kind of program?
Shouldn't the LED tasks be implemented as infinite loops?
Tasks must not attempt to return from their implementing
function or otherwise exit
2:25 shouldn't this be the smp branch that we need to clone.. as per the docs it's the smp branch which is intended for pico
@Low Level Learning, so you didn't actually brick your raspberry by putting the LED in the wrong way? i was wondering if that was actually possible? I'm just starting out with this stuff and this seems exactly like the sort of thing I would do :D
I didn't, I was just an idiot and forgot to put the task into a loop -_- LOL
@@LowLevelTV phew, I was thinking, I need to buy a couple of extra units, just in case I start bricking things :D haha, although I am quite interested to try FreeRTOS and connect multiple boards together and see if I can use I2C to transmit information between them, using each individual board to do different kinds of processing and use I2C to send the results between the cpu's. If you know what I mean? That sounds an interesting project.
Common misconception and a typo; real-time OS does not necessarily mean executing tasks concurrently. Only, scheduled-based, and guarenteed execution (and, finishing ..) in a pre-determined time range).
fried board makes a nice pendant ? or 2 for earrings ...
A fine necklace! LOL
My girlfriend has a lot of pendents.
Still better than windows
Not forget to use 330 Ohm resistor with LED.
The blue smoke came out of my LED now what
@@LowLevelTV Use a smaller resistor to compensate that xD
you should check if the board is really burned, and redo the video, it is not a recommended practice since you notice a beginner's error in electronics
You did not brick your Pi Pico, you just blew it up. It seems that the definition of software people is those who overuse terminology to sound cool.
Hello, else it's not big deal to make your own scheduler with setjmp longjmp
You can say that, but if someone has already made an efficient scheduler, why would you insist on writing your own?
i'd write a web service on a real computer to assist the pico. it's the easiest solution
Neat
More than one Microcomputer used BASIC as it's OS, and you already have the Micropython interpreter that should easily be at least as fully functional.
What is the point here?
BASIC is a language. Micropython is a language. FreeRTOS is an operating system which is intended to simplify the design of more complicated systems. Blinking LEDs doesn't really show off its strengths.
@7:27 - I guess this will be known as "The Great $4 Disaster of 2021" =)
Interesting. It makes programing easier but what about the overhead?
I had to laugh that you only had one pico lying around despite spending so much time on it.
Especially these days I order a lot more if it's a universal part. I needed one pico but ordered 10.
Pretty anticlimatic at the end. Still good video.
On no planet, setting a pin, then sleeping, then setting it again is acceptable blinking behaviour. Delays, etc will cause this to desync on any OS
You are making assumptions on how the sleep function works. Most time libraries use a central time count that keeps a count of microseconds, or hundreds of microseconds, or some other constant unit of time, and has retriggerable sleep functions. That is, rather than just calling a function that goes to sleep for 1 second from now, you keep resetting an alarm for so many system clock ticks from the last alarm. So if you start a 1-second loop counter at system clock 123000 milliseconds, then when your thread gets that alarm event, you reset the alarm to 124000 milliseconds, then 125000, and so on. It's really up to the programmer - you can either let the blinks free run, if you really don't care, or you set it up so they can stay in sync, if that's important to you. Or to put it another way, just because you can't imagine a planet where blinking out of sync is acceptable, does not mean that such a planet does not exist.
You made fun of the old man boomer and that back fired on you 🤣
Thumbs down because of burnt out board. Just get a new board and finish the video....
cmake 🤥🤥
I can not dowload the FreeRTOS_Config.h