Choosing i.MX for embedded project : double Cortex-A cores or Cortex-A + Cortex-M4?

[Anonymous]

Hello, we have embedded project based on ARM Cortex-M7 MCU nearly complete. It is built as a bare-metal, controls many different peripherals in real time with many sensors mostly driven by timers with callbacks.

I am considering to switch to the multi-core i.MX primarily to simplify it by removing all USB and SPI operations and placing them in a separate Linux core, leaving only true real time tasks in another core. (There are other reasons too).

Typical solution according to the information I found so far would be something like i.MX6SoloX where Cortex-A8 core would run Linux with slower USB and SPI connections, while Cortex-M4 would run real time tasks where latency must be minimal.

But I don't understand the following: why nobody is using homogeneous SoC like i.MX6D to use them as follows: one core runs Linux and another core of the same type runs real time? Looking in the peripherals in each core - they seems to be well capable to run real time if they are not burdened by running OS such as Linux...

Can't the Cortex-A8 core be programmed as bare-metal and made perform like a real time MCU ? After all it is even faster than M4. I think in such design the messaging between those 2 cores can be very fast . If it is not possible, why so ? Is it possible to access in Cortex-A core the I2C interface , timers, GPIO, PWM peripherals directly from C code just like MCU? Does library exist to do that?

Or is there the only way to implement real time in Cortex-M4 co-processor ?

Please advice, thanks

Vlad

[Anonymous · Accepted solution]

While continuing searching all over internet I finally found the information which seems to render the answer to my question. So for all those who are searching for the same here it is...

The intent of Cortex-A architecture is high speed high volume data processing, graphics and mass volume communication such as USB with terminal, etc... To accomplish this Cortex-A series  incorporated cache and memory management systems - these techniques make each CPU cycle of unpredictable and unreliable for true real time application where Cortex-M is "the king" . Cortex-M is fast and predictable without use of memory management and with highly reduced set of RISC command set - these make them the best for sensor signal processing and for the real time activators control.

Whence having both architectures on chip SoC gives the best solution for a complex project: Cortex-M is driving real time peripherals, while Cortex-A takes care of large volume of processing and communication of large streams of data without even need for the speed of "Preempt-Linux" kind of OS. If the architecture is smartly organized, then only those tasks will be passed to Linux which make a "standard" Linux fast enough for the project.

Hope this info will help others too.

Regards