Supporting multiple cores from bare metal C
-
I always wondered what a bare metal C implementation - the kind you'd use to write even parts of low level boot loader code would do to expose things like a 2nd core. Or rather, how do you use a 2nd core without a scheduler? I've always kinda wondered about that. The answer is simple. You activate the core in the bootloader and then get the core to JMP to your code. One main() in effect, for each core.
extern "C" void aux_core_main()
{
// 2nd core just starts here. Spin a loop. Be happy.
}Synchronization is a whole different story, but if you don't need to synchronize, why waste any overhead on scheduling?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I always wondered what a bare metal C implementation - the kind you'd use to write even parts of low level boot loader code would do to expose things like a 2nd core. Or rather, how do you use a 2nd core without a scheduler? I've always kinda wondered about that. The answer is simple. You activate the core in the bootloader and then get the core to JMP to your code. One main() in effect, for each core.
extern "C" void aux_core_main()
{
// 2nd core just starts here. Spin a loop. Be happy.
}Synchronization is a whole different story, but if you don't need to synchronize, why waste any overhead on scheduling?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
That's using a scheduler and an OS. The point of my post was what happens with 2nd core activation in the absence of a scheduler.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
That's using a scheduler and an OS. The point of my post was what happens with 2nd core activation in the absence of a scheduler.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Nice. It's always interesting to go more and more "bare" in bare metal development. Regarding RTOS - I am surprised, that it is called OS, I always think about it as kind of multitasking library. Not full-featured OS like embedded Linux, and available in bare metal projects.
-
Nice. It's always interesting to go more and more "bare" in bare metal development. Regarding RTOS - I am surprised, that it is called OS, I always think about it as kind of multitasking library. Not full-featured OS like embedded Linux, and available in bare metal projects.
Well for the purposes of what I'm talking about an RTOS (which is a kind of OS, albeit a RealTime OS) is an operating system. It has a scheduler to handle context switching. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I always wondered what a bare metal C implementation - the kind you'd use to write even parts of low level boot loader code would do to expose things like a 2nd core. Or rather, how do you use a 2nd core without a scheduler? I've always kinda wondered about that. The answer is simple. You activate the core in the bootloader and then get the core to JMP to your code. One main() in effect, for each core.
extern "C" void aux_core_main()
{
// 2nd core just starts here. Spin a loop. Be happy.
}Synchronization is a whole different story, but if you don't need to synchronize, why waste any overhead on scheduling?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
This is not as complicated as you might think. It is just another processor - you set up a 'context' (stack, memory & code spaces and an entry point), initialize the core as needed and 'start' - it will run. I played with a very early open multicore processor maybe 15 years ago. After you get over the initial buzz, it is just like running tasks on any other processor (so, ho-hum). Chopping up a C program to efficiently take advantage of multiple cores, on the other hand, is something else entirely and not for the faint of heart - and something I have never thought would stop you.
-
This is not as complicated as you might think. It is just another processor - you set up a 'context' (stack, memory & code spaces and an entry point), initialize the core as needed and 'start' - it will run. I played with a very early open multicore processor maybe 15 years ago. After you get over the initial buzz, it is just like running tasks on any other processor (so, ho-hum). Chopping up a C program to efficiently take advantage of multiple cores, on the other hand, is something else entirely and not for the faint of heart - and something I have never thought would stop you.
I just thought it was interesting that it was effectively a second main(). I was expecting something more complicated for some reason. And yeah, synchronization is the real mess, especially when you need to build up the primitives from scratch. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix