FreeRTOS kernel v10.6.0 is now available for download. This release includes several security enhancements to the FreeRTOS ports with Memory Protection Unit (MPU) support. Some security enhancements include saving context in Task Control Block (TCB), executing system calls on a separate privileged-only stack and adding memory bounds checks in system calls with pointer parameters.
Refer to the release history or GitHub for more details. Contact us on the FreeRTOS forums if you have feedback or comments!
The download link does not yet include the new kernel .
Thank you for pointing out. Corrected the download link.
FreeRTOS kernel v10.6.1 is now available for download. See release history or GitHub for more details.
main branch contain FreeRTOS-SMP specific APIs. When will be the release of FreeRTOS with latest smp code?
We intend to have a release out by end of this year.
FreeRTOS-Kernel V11.0.0 is now available for download. Check out the whatâs new post for all the details.
So does it mean that we can now âjust runâ the task and the scheduler will distribute it across available cores?
Or is it only using pico-sdk synchronization primitives? (Demos provided for RP2040 donât seem to use affinity at all)
Yes - if you are using a FreeRTOS port with SMP support, the scheduler will schedule tasks across all available cores.
If a task is not assigned core affinity explicitly, it is eligible to run on any available core.
Note, this means that any given task will run on just one core at a time, but can end up running on any core over time. To run on two cores at once, you need to divide the work into two (or more) tasks and handle the synchronization needed between them (if needed).
âŚand the assumption of sequential execution accidentally designed into your code go out the window
âŚand synchronization by task priority, a cornerstone of your software design, slips awayâŚ
⌠wonders of SMP
So that means that the two tasks in the RP2040 simple blinky demo will run potentially run on different cores? If so, these demos descriptions are horribly wordedâŚ
LOL. yes
I would regard effective multicore, multi threaded that of âexpertâ . Itâs not really that hard as long as you know completely what is going on at all times⌠If you really get stuck, a few IO pins dedicated to multi threaded debug can help (to observe run/stalls of various threads without observation side effects) .
Still, this is quite an advance !
Is this not the way multithreading across multiple cores generally works everywhere else? The scheduler on finding an idle core assigns the next scheduled task to execute on that core.
Unless youâre looking higher level abstractions that segment large job execution into specific worker threads, which may or may not have a defined affinity.
Thatâs a good point, and also a lot of food for thought⌠because, on a certain level, task priorization can be viewed as a construct on the assumption that there is only one CPU which we have to tell what we want it to do more urgently than other things. If we do have more than one CPU, there is less need to prioritize tasks - up to the point that if we had as many cores as tasks, there would be no need for priorization in the first place!
All under the assumption, of course, that our computations are mostly CPU bound which is the scenario where true parallel execution is most beneficial. In predominantly I/O bound computations, a single core might easily suffice.
As for the scheduling scheme of things, @richard-damon has a valid point here that in the light of SMP, the organization of computations into tasks is an important issue to consider now - which brings me back to one of my favorite topics, underrated I/O completion ports. Implementing those critters on FreeRTOS along with SMP would be a real game changer.
I only meant that this:
The project includes the following demos:
Blinky Demo.
Comprehensive Demo.
Multicore Demo.
(SMP Demos for the Raspberry Pi Pico Board - FreeRTOS)
Strongly suggest that the other demos are not multicore⌠(I guess they are and multicore refers to pico/multicore.h library)
It is timely, because many microcontrollers are now appearing with dual cores.
In most embedded systems, what they have to do, and what they will do is VERY different to a high level desktop PC. Embedded systems know their mission profiles and the expected stimulous / workload. high level desktops do not.
The scheduler is one thing ! This is a whole subject in itself. A huge subject.
I had a colleague that did his PhD on a system where there was a core assigned specifically to scheduling⌠IE 4 core system - 3 cores in SMP for user / system threads, and one core dedicated to purely figuring out scheduling and optimizing scheduling performance.
It would be so nice, if moderators would LOCK âAnnouncementsâ posts, because my email is being spammed by some random messages and i think not only mine. I understand, everyone is eager to try it, or be funny. But i didnt signup for that, i signed up for release announcements