Thanks for the explanation of this FIFO feature. Nevertheless, there is important note in the doc about the FIFO usage: "The inter-core FIFOs are a very precious resource and are frequently used for SDK functionality (e.g. during core 1 launch or by the lockout functions). Additionally they are often required for the exclusive use of an RTOS (e.g. FreeRTOS SMP). For these reasons it is suggested that you do not use the FIFO for your own purposes unless none of the above concerns apply; the majority of cases for transferring data between cores can be eqaully well handled by using a queue"
@@pjforde1978 Boy, I have no idea what happened there LOL ... The point is, of course, that they have provided a push pull queue for moving information between cores in a thread safe manner. Not sure where I got 260 from ... that was a pretty big OOPS. Thank you for pointing it out.
Great intro into multi-core programming especially the graphical explaination before the coding. 1K subs, well done! Could you take it a step further and do some deep-sleep explaination?
I do embedded work for a living and just ordered a Pi pico to play with. In particular the programmable PIO looks interesting. This was a useful video for exposing the "C" apis for me. I had only ever seen micropython examples for the pico. Now to start working out the details of hooking up a fancy JLINK pod and use a graphical debugger!
exactly what I was looking for. thanks! I need to figure out the non blocking way of doing it otherwise it doesn't actually increase the performance but that is a beautiful introduction.
From the raspberry pi pico docs: " uint32_t multicore_fifo_pop_blocking ( void ) Pop data from the read FIFO (data from the other core). This function will block until there is data ready to be read Use multicore_fifo_rvalid() to check if data is ready to be read if you don't want to block. See the note in the fifo section for considerations regarding use of the inter-core FIFOs Returns 32 bit data from the read FIFO. " So apparently you just " if( multicore_fifo_rvalid() ) { do-blocking-stuff } else { do-other-stuff } "
Is there a way to have a shared buffer? Maybe using spinlocks and what not? The use case would be having a class with a lot of data, and having the other core doing the communication with such data. So one core can manage the data, one core can send/receive that data
cant you use a simple semaphore to ensure the shared resource gets written by only one core at a time.A simple producer-consumer example might be good to demonstrate that.
Shock to know that Pico uses FIFO design. It's an easy, low cost, low power way to combine two cores.... But for the performance and future scale up consideration, believe, the FIFO will not be the choice...
Thanks! Can’t wait to use both cores. So far I’ve got 2 separate instructions running on my project but this is helping me know how to push data between cores. I saw another video talk about having interrupts for each core that will run when it’s moving data over, is that going to work better when the cores are running more complex tasks?
is this possible? Like having two separate OS running on each of the cores. The reason I ask is I have a program that uses a PIR sensor to play a song(when it plays a song, it overclocks from 125Mhz to 175Mhz. The reason for overclocking is to match 44Hz audio out. I was hoping to run the overclocking on one core and have a peaceful PIR code on the other). However, since the other core would trigger the overclock I think it affects the "peaceful" core (PIR Code), assuming you can run two separate codes on different languages and run each on unique cores.
@@mrlobbyist2061 well you can certainly write C to operate on one or both of the cores simultaneously. Running python on one and c on the other would probably need to be in mind when beginning the port of python to the uP. So the answer is yes with a qualification that the code must be designed in such a way as to support the ability. I doubt that has been done.
@@mr1enrollment ahh i see, that was fast 😂 get it? Anyhow, could you help me with something else, I'm still new to this, do you know if overclocking effects my PIR in any way? Any help is great appreciated!
Is there any reference about the data in multicore_fifo_push_blocking (uint32_t data)? How do you know GPIO_ON is 1 and GPIO_OFF is 0?. I tried to search in PICO C SDK but cannit found.
Interesting. Although a bit of a silly example. Could you put the Fifo service into an interrupt? And let an unsynchronzed service routine on core0 update the LED, when it has time? Is the memory for each core completely off limits for the other core, or could you inplement semaphores via the fifos to regulate synchronized memory access?
Thanks for watching! Definitely a bit of a contrived example. Both core's have access to the full memory map, you'd just need to use a mutex to lock out certain regions. The RP2040 multicore API has these. The FIFO is more for intercore communication, less about access control.
This has been one of the most frustrating and annoying projects I have ever worked on. finally got standard blink working after manually installing gcc and g++ and many other packages finally gave up and upgraded Ubuntu 6 versions to finally get the many compilers and packages this 4 lines of code needs to be built) what a nightmare. Tried this and now make cant find multicore.h what the hell? I tried all the different versions of include. what a brittle framework and architecture.
Thanks for the great video! Does anyone know how core1 can reconize the fifo commands and run the code spedcified by core0. In the src file of multicore.c line 145, there is a specifal cmd sequence consisting vec_table, sp, and entry point for core1. Core1 recognizes these cmds because there is already some code running in core1 after boot?
No need for an OS, just a program that makes use of the second core. The hard part in design would be figuring out what task the second core does, the inter-core-communication scheme, etc
Thanks for the explanation of this FIFO feature. Nevertheless, there is important note in the doc about the FIFO usage:
"The inter-core FIFOs are a very precious resource and are frequently used for SDK functionality (e.g. during core 1 launch or by the lockout functions). Additionally they are often required for the exclusive use of an RTOS (e.g. FreeRTOS SMP). For these reasons it is suggested that you do not use the FIFO for your own purposes unless none of the above concerns apply; the majority of cases for transferring data between cores can be eqaully well handled by using a queue"
Wouldn't that involve accessing some global memory space or one core accessing the other's memory? I am slightly confused.
@@MikeSims70 I'm trying hard to find page 260 in this 201 page document...
@@pjforde1978 Boy, I have no idea what happened there LOL ... The point is, of course, that they have provided a push pull queue for moving information between cores in a thread safe manner. Not sure where I got 260 from ... that was a pretty big OOPS. Thank you for pointing it out.
I searched so many videos but didn't got my concept cleared about RP2040 dual core coding. You have cleared my whole concept. Thanks.
Great intro into multi-core programming especially the graphical explaination before the coding. 1K subs, well done! Could you take it a step further and do some deep-sleep explaination?
Coming up soon!
I do embedded work for a living and just ordered a Pi pico to play with. In particular the programmable PIO looks interesting. This was a useful video for exposing the "C" apis for me. I had only ever seen micropython examples for the pico.
Now to start working out the details of hooking up a fancy JLINK pod and use a graphical debugger!
This is extremely high quality content, thanks and all the best !!
Thanks for this! Super useful! Gradually binge watching your entire channel! 😍
Damn this video immediately answered a question I was stuck with in my head after watching a pico beginner tutorial somewhere else. (1:27)
Congrats on 1K
Thank you!
exactly what I was looking for. thanks! I need to figure out the non blocking way of doing it otherwise it doesn't actually increase the performance but that is a beautiful introduction.
From the raspberry pi pico docs:
" uint32_t multicore_fifo_pop_blocking ( void )
Pop data from the read FIFO (data from the other core).
This function will block until there is data ready to be read Use multicore_fifo_rvalid() to check if data is ready to be read if you don't want to block.
See the note in the fifo section for considerations regarding use of the inter-core FIFOs
Returns
32 bit data from the read FIFO. "
So apparently you just " if( multicore_fifo_rvalid() ) { do-blocking-stuff } else { do-other-stuff } "
@@Jp-ue8xz I have it working now thanks and it is a dream to double the performance of my application without hardly any effort.
Great Scott! , Looking forward to another great video.
Thanks for the tutorial, but I had to add the pico_multicore library in the target_link_libraries()
I like this very clear explanation. Sub'd. Thank you.
Well done, subscribed.
Awesome, thank you!
brilliant content.
Is there a way to have a shared buffer? Maybe using spinlocks and what not? The use case would be having a class with a lot of data, and having the other core doing the communication with such data. So one core can manage the data, one core can send/receive that data
It was interesting. Thanks
You're welcome
wow，this video does help，thank u
cant you use a simple semaphore to ensure the shared resource gets written by only one core at a time.A simple producer-consumer example might be good to demonstrate that.
Shock to know that Pico uses FIFO design. It's an easy, low cost, low power way to combine two cores....
But for the performance and future scale up consideration, believe, the FIFO will not be the choice...
simple nd great video ✌️
Thnx homie
Thanks! Can’t wait to use both cores. So far I’ve got 2 separate instructions running on my project but this is helping me know how to push data between cores. I saw another video talk about having interrupts for each core that will run when it’s moving data over, is that going to work better when the cores are running more complex tasks?
I use pico as my primary USB DAC. I use core1 for all the interrupt-based tasks, leaving the core0 for USB stack and other simple computations.
Nicely done.
Now: show how to do the same Except one core with C++ and the other Python,...
Please. ;-)
Noted!
@@LowLevel-TV that was FAST!
is this possible? Like having two separate OS running on each of the cores. The reason I ask is I have a program that uses a PIR sensor to play a song(when it plays a song, it overclocks from 125Mhz to 175Mhz. The reason for overclocking is to match 44Hz audio out. I was hoping to run the overclocking on one core and have a peaceful PIR code on the other). However, since the other core would trigger the overclock I think it affects the "peaceful" core (PIR Code), assuming you can run two separate codes on different languages and run each on unique cores.
@@mrlobbyist2061 well you can certainly write C to operate on one or both of the cores simultaneously. Running python on one and c on the other would probably need to be in mind when beginning the port of python to the uP. So the answer is yes with a qualification that the code must be designed in such a way as to support the ability. I doubt that has been done.
@@mr1enrollment ahh i see, that was fast 😂 get it? Anyhow, could you help me with something else, I'm still new to this, do you know if overclocking effects my PIR in any way? Any help is great appreciated!
Hello, I've subscribed. Thanks!
so have I missed it? did you do a vid on-- how to do the same Except one core with C++ and the other Python.
Thank you very much!
You're welcome!
Thank You
Will the example work in the Arduino core for the RP2040? The Arduino package includes the RP2040 SDK.
I havent done any investigation on the Arduino boards yet but given that its the same processor I believe it should work!
Is there an interrupt for when data is available on the FIFO?
Is there any reference about the data in multicore_fifo_push_blocking (uint32_t data)? How do you know GPIO_ON is 1 and GPIO_OFF is 0?. I tried to search in PICO C SDK but cannit found.
Do you have an example where you do multithreading in micropython ?
Interesting.
Although a bit of a silly example.
Could you put the Fifo service into an interrupt?
And let an unsynchronzed service routine on core0 update the LED, when it has time?
Is the memory for each core completely off limits for the other core, or could you inplement semaphores via the fifos to regulate synchronized memory access?
Thanks for watching! Definitely a bit of a contrived example. Both core's have access to the full memory map, you'd just need to use a mutex to lock out certain regions. The RP2040 multicore API has these. The FIFO is more for intercore communication, less about access control.
This has been one of the most frustrating and annoying projects I have ever worked on. finally got standard blink working after manually installing gcc and g++ and many other packages finally gave up and upgraded Ubuntu 6 versions to finally get the many compilers and packages this 4 lines of code needs to be built) what a nightmare. Tried this and now make cant find multicore.h what the hell? I tried all the different versions of include. what a brittle framework and architecture.
Thanks for the great video!
Does anyone know how core1 can reconize the fifo commands and run the code spedcified by core0.
In the src file of multicore.c line 145, there is a specifal cmd sequence consisting vec_table, sp, and entry point for core1.
Core1 recognizes these cmds because there is already some code running in core1 after boot?
Do we need a operating system to do more on core0 instead of waiting?
No need for an OS, just a program that makes use of the second core. The hard part in design would be figuring out what task the second core does, the inter-core-communication scheme, etc
has anybody done this in micropython? can someone direct me to the right recources?
Why does your font size have to be so small?