RT1170, utility of having two cores.

[luiHS]

Hi.
So far I have not seen a microcontroller with two cores. I see NXP announcing the RT1170 series available for February. Looking at the datasheet I see that the BGA is 0.8mm pitch, so I think I will dare to make my own PCB.

What I don't see is the application and utility of having two cores on a single chip, one at 1Ghz and the other at 400Mhz.

1.- Is it like having two microcontrollers on a single chip?
2.- Are they internally communicated with each other, or totally isolated from each other?
3.- What advantages and usefulness can having more than one core on a single microcontroller chip have for developments without an Operating System?

I would have preferred a 1Ghz Cortex M7 micrococontroller, without the other 400Mhz core, if that lowers the cost.

[ajb]

Multi-core MCUs aren't THAT uncommon.  ST has dual M4/M7 parts, the recent Raspberry pi Pico has two M0s, TI has some dual core parts in their Delphino (IIRC?) line, and there are others.

It's sort of like having two MCUs in one chip, the difference is that typically peripherals and memory are shared to some extent, although the details depend on the specific architecture.  The datasheet or reference manual should provide a bus architecture diagram that will show which cores are connected to which buses, which will indicate which peripherals can be accessed by which core.  Even if all cores can access all peripherals and memories, different cores may be able to access those at different speeds, due to different interface widths or needing to go through more than one bus multiplexer to get from the core to the peripheral. 

The different cores can generally communicate with each other via shared memory, although this can be tricky due to concurrency issues.  It's basically the same challenge as having to communicate between threads of execution (IE, between two ISRs, or between an ISR and a main loop, or between OS threads) on a single core, except more so.  Some (most? all?) multi-core architectures will also provide dedicated hardware semaphores or other mechanisms that can be used for easier cross-core communication.  A semaphore can be used on its own to communicate a few bits worth of data, or it can be used to lock/unlock an area of shared memory to exchange larger amounts of data.  These semaphores may also be useful for cross-thread communication within a single core.

There are two main benefits to multi-core designs in the MCU space.  The first is scaling power consumption with workload.  For example, you might have a few tasks that need to run all the time, plus some other intermittent tasks that demand a lot more processing power.  If you can power down one core while keeping another active for housekeeping, and to wake up the other core when it has a job to do, that can save a meaningful amount of power.  This effect can be pronounced when different types of cores at different power/performance levels are combined.  Think about your phone: when you turn the screen off, not only do you save power by turning off the display, but you can also power down the GPU because there's nothing for it to render.  The other benefit is in separation of concerns.  It's quite common to have certain operations with hard realtime requirements, and also other operations that are processing intensive but less time sensitive, like motor control and a user interface, or a complicated protocol stack and general application code.  In many of those cases, putting the hard realtime stuff or the complicated protocol stack on one core and the other, less sensitive stuff on the other core makes the application a lot easier to develop, because you don't have to worry about scheduling the critical stuff and the less critical stuff around each other.  Multitasking (via an OS or otherwise) can accomplish some of these things, but it's not a viable solution in all cases and comes with some disadvantages, like the fact that switching threads incurs a penalty to switch contexts.  There's a third benefit at the higher end of the performance scale, which is that at a certain point it's more practical to increase the number of cores than it is to increase the performance of a single core.  If a single Cortex-M0 core doesn't offer enough performance for an application, you can simply move up to an M4 or M7 or whatever, but if you're running out of horsepower on an M7 you need to add a core or move to a different architecture entirely.  This is why PCs and mobile phones are invariably multi-core; it's way more practical to strap four or eight or however many cores together than it is to increase single-core performance by four or eight times.  It's also more scalable, since the number of cores can be adjusted relatively easily for different applications versus changing cores.

[luiHS]

Thanks for the information, I will have to read the RT1070 reference manual calmly so that I can use the double core.

[brucehoult]

ESP32 has two cores, and the ESP32-C2 replaces one of the Xtensa cores with a RISC-V core so it has one Xtensa, one RISC-V.

[JPortici]

dsPIC have dual core variants, the second core running from RAM with the benefit of higher clock speed and reduced latency (the 2-5 clock penalities due to branches and context save become 1-2) with the purpose being running motor control algorythms on the slave core, in fact the peripherals are highly balanced on the networking/interface side on the master core and on analog/motor control/sensor interface on the slave core

NXP has had dual cores for a long time, the LPC 4300 series, then came the 54000, then also kinetis parts. In these cases the first core is a high perfromance one using caches and such, the second core is a lower power, simpler core for communication/housekeeping/more deterministic IO stuff/name it.
All of these come in more friendly packages if you want to experiment with the concept.

And of course all the multicore Automotive controllers, but they are usually doing multicore with lockstep so it's another can of worms entirely

[iMo]

There is the FreeRtos for dual cores MCUs, afaik..

[SiliconWizard]

ajb makes a couple interesting points about this, in particular power consumption and real-time requirements. Multi-core processors, especially with different types of cores, can definitely help here.
Whereas the "real-time" arguments are relatively common and well-known, the power consumption factor is less often considered, and is well worth noting.

Of course there's also a cost factor: adding a smaller/simpler core can give you the above benefits while the added cost can be relatively minor, both in terms of silicon area and in terms of license when it applies.