@@jyvben1520 Thank you for the feedback, still new to this tutorial/youtube game so very useful to know how to improve! I have already increased the font size in my upcoming videos. Happy to hear you found the website useful!
I thought the text size was just fine but the bright white backgrounds of the animations were blinding, maybe a texture a dark mode style would be better? Awesome video.
Hands down the BEST coding video I've ever seen. Your narrative keeps up perfectly with your coding, you explain everything perfectly and you don't have any time-wasting moments in the video where EVERYONE ELSE DOES because they think that we want to sit here and watch them correct their mistakes while they mumble to themselves. NOT YOU! You NAILED IT! NICE WORK!
Agreed. It’s very nicely put together. Controllers Tech videos are also packed with useful info and presented well. (Not everyone will appreciate the presenter’s artificial voice, but the quality content and thoughtful presentation make them worth a look.)
It's quite surprising to me that this would work at all. I would have thought it likely that the USB output would need interrupts to work and usually interrupt systems don't, at least by default, allow interrupts to nest.
Interesting illustration, but normally you’d want to do the bare minimum in an interrupt handler, and defer calculations and printing to a foreground task on the same core.
I have a question. How can you send the value of a variable that has been defined in the core1 back to core0? I've been trying to send the temp variable calculated in the core1 back to the core0 with the "multicore_fifo_push_blocking(temp);" function but it doesn't appear to be working.
I'm surprised you didn't get a watchdog exception for doing so much during an interrupt, unless the Pico SDK doesn't check for that. For the ESP32, if you spend too much time in an interrupt, you'll get a panic and crash. That happened to me trying to use an interrupt handler in ESP32 to process data when available from an external ADC that calculates AC RMS from a current sensor. A better method of handling data transfer signaled by an interrupt is to tell the main program in core1 through a flag that there's data available, or have the interrupt populate a buffer defined in the core1 code. But I realize this is just to get our feet wet using multi-core, FIFO, and interrupt.
Dude - you have a "printf" in an ISR!! it's only because this is such a trivial example that it works at all. ISRs should be short and sweet. Get the data and put it into a queue for the "main" loop for the core to handle.
Thanks. In 25 years of firmware coding I always assumed I'd need multithreading at some point but it just hasn't happened; PC software's a different matter of course. So I come to the Pico wondering what scenarios justify the overhead. Most multicore MCUs have cores specialized for different purposes - eg M0/M4 - which makes sense. I'm thinking it's gonna need some careful design to get the most out of two symmetrical cores. But they're welcome!
Super interesting! Nice to see the whole project being created too rather than just opening Arduino IDE. Although I’m guilty of that I suppose as I just let CubeMX do all the setup 😝 How have you found the discoverability with the pi pico? Is all of this based on examples they provide and is it easy to dig into the HAL files and find what you need or is it provided as a compiled library that you can’t view?
The Pico c/c++ SDK is pretty well documented, and so most of the examples I present in these videos will follow a similar form to the examples so people can jump from these videos into the documentation and vice versa. I will have a few videos (soon-ish) not using the SDK. In terms of discovery, you can poke around the HAL (or SDK as RPi foundation like to call it) all you like, it is not compiled until you compile it, but finding what you are looking for may take a little time. You can have a look at the Github here: github.com/raspberrypi/pico-sdk
The FIFOs do simply quite a wide range of possible applications. The introduction part of the video seems to rather imply the FIFO buffers are the only way to do multi-core on the Pico! Surely not?
Thanks for doing this in C/C++. There are copious amounts of micropython examples out there for the Pico, but very few useful ones in C/C++. Nice pacing, editing and focus.
Is there a similar video but with FreeRTOS on the pico ? The ESP32 has its own slightly modified SMP enabled version of FreeRTOS i was hoping that the pico also has some such implementation Having similar function calls like the ESP-IDF for the pico would make life a lot easier to write multi-core RTOS applications. Especially with the pico W . @LearnEmbeddedSystems
I have my dev machine set up exactly the same way as "Learn Embedded Systems" The issue I am having with setting up the multi-core is that I am getting errors during the CMake configuration process. I get the following errors: [cmake] TinyUSB available at C:/Pico/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; adding USB support. [cmake] Compiling TinyUSB with CFG_TUSB_DEBUG=1 [cmake] -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) [cmake] CMake Error at C:/Pico/pico-sdk/src/rp2_common/pico_stdlib/CMakeLists.txt:26 (set_target_properties): [cmake] set_target_properties Can not find target to add properties to: multicore [cmake] Call Stack (most recent call first): [cmake] CMakeLists.txt:18 (pico_enable_stdio_usb) [cmake] [cmake] [cmake] CMake Error at C:/Pico/pico-sdk/src/rp2_common/pico_stdlib/CMakeLists.txt:22 (set_target_properties): [cmake] set_target_properties Can not find target to add properties to: multicore [cmake] Call Stack (most recent call first): [cmake] CMakeLists.txt:19 (pico_enable_stdio_uart) [cmake] [cmake] [cmake] ELF2UF2 will need to be built [cmake] -- Configuring incomplete, errors occurred! [cmake] See also "C:/Pico/pico-projects/build/CMakeFiles/CMakeOutput.log". [cmake] See also "C:/Pico/pico-projects/build/CMakeFiles/CMakeError.log".
Another great video. I did have to add sleep_ms(1000); after stdio_init_all(); in main to get the program to function correctly. I am looking forward to seeing multi core with the freeRTOS. Thanks!
Nice video however I would advise rather using queues and not the intercore fifos, as those are usually required to be reserved if you implement any real multicore program. Also usage of floats seems very unnecessary, fixed point would have been more than enough, especially in an ISR where you usually want to keep cycles to a minimum.
Good video, but i confused , how can we talk about a multi-core application if there is an external controller (or interrupt)? You can't do two operations at once if you have a controller or loop .In my opinion, a serial processor cannot operate two operations independently of each other. If it's working, *it doesn't return any data to you.* anyway, thanks for sharing, have nice day !
The interrupt was set on Core 1, so it won't have any effect on Core 0. You *can* do two operations at once *if you have two cores* - that's the point of having multiple :D
Can you please make a video on how to make sure that a specific thread is executed in hard real-time? For example a time of 54 micro seconds? How can this be achieved? With a condition variable?
Precise timing will require a real time operating system (RTOS). There has already been a port of freeRTOS to the Pico, and I will eventually get round to making a video on it! If you can't wait then here is a link to the freeRTOS port github.com/PicoCPP/RPI-pico-FreeRTOS
Answering my own question; earlephilhower's arduino-pico, on github, allows the use of both cores. You have the normal setup() and loop() for core 0, and an optional setup1() and loop1(), for core 1. You can install support from there, or by copying the .json link into the settings of the Arduino IDE, then use the Boards Manager, on the Tools->Board menu. Posting the link got my comment blocked, so you'll have to google it, or search on github.
I think it would certainly be possible but it's actual use might be quite limited. These microcontrollers perform well performing fast functions like I/O but don't have particularly much compute horsepower. So as an exercise it would certainly work but in terms of functionality? I think it would be outperformed by the most basic Raspberry Pi cluster. Hope this helps!