Good evening,
I’m currently designing my embedded device, which includes a Toradex SoM (running a Qt5-based GUI on Embedded Linux) interfacing with a SAME70Q21 32-bit MCU. The MCU is used for all time-sensitive hardware interfacing (SPI, I2C, UART/USART, CAN, GPIO, etc.), and for data acquisition and temporary buffer storage (64 inputs @ 1000 samples per second per input).
This approach seems solid, but I would be remiss if I didn’t also investigate the potential for using one of the Toradex SoMs which includes a discrete MCU (e.g. Colibri iMX7D). I believe the Cortex M4 @ 200MHz should be sufficient for my needs, but I’m concerned about only having a dual core ARM processor for running the Embedded Linux OS and Qt5 GUI. Short of buying a range of Colibri SoMs for testing on the Colibri evaluation board, is there any discernible means for determining the performance of a given application on a specific SoM? To clarify, does the Cortex M4 MCU on the iMX7D have FPU?
If the dual core ARM is sufficient and the M4 on the iMX7D has FPU, then my last consideration is interfacing. Do the ARM processor and MCU have shared memory? I.e. will my ARM userspace application be able to access data stored in memory/registers of the MCU (DMA?)?
Any guidance, suggested reading or experience on this matter would be greatly appreciated. I’m acutely aware that the upcoming Colibri iMX8X is the perfect solution for my application, but unfortunately I don’t think I can wait any longer for its release.
The dual Core Cortex-A7 of the i.MX 7Dual SoC is actually rather powerful, but it is missing a GPU. Qt5 Qt Quick 2 based user interfaces typically use the OpenGL backend. If you are using higher resolution and some more involved Qt Quick 2 elements, this might be a bottleneck. Newer Qt5 versions do have a Qt Quick 2D Renderer which does not require a OpenGL backend while providing decent performance.
The Cortex-M4 in the i.MX 7 Dual does have a FPU.
The primary A7 cores as well as the secondary M4 core are connected to the same bus (shared bus topology). All peripherals and all memory can be accessed from both cores. The M4 core has some restrictions when it comes to caching (not all DDR memory is cacheable).
From a user space application it is typically not possible to access memory locations using physical addresses. The kernel provides a communication mechanism which uses shared memory (RPmsg). I suggest to make use of RPmsg for any communication requirements.
Brilliant response, thank you @stefan.tx! I had missed the lack of GPU on the iMX7, which entirely rules it out unfortunately as my application makes extensive use of OpenGL. In that case, I see my options as either waiting for the iMX8X to come out, or continue with my external MCU. Do we have any update on when we’re likely to see the Colibri iMX8X?
About the Colibri iMX8X availability:
The product is planned to launch late Q4 2018 / early Q1 2019, parallel to the official launch with NXP. Currently we’re evaluating an early access program, same as we’ve already started with the Apalis iMX8QM. If you want to be kept posted automatically, I recommend you to subscribe to updates on this page.
Great, thanks @stefan_o.tx. I’ll continue with my external MCU for the time being 
