SPI Comm between A Core or M Core

Technical Support
1

Hello,

On our board, we have an additional MCU dedicated to managing I/O and sensor measurements and controls. We need to display and configure these I/Os on the Linux side. We are considering using SPI to facilitate communication between the extra MCU and the i.MX8MP MPU.

Should we connect the SPI directly to the A core, or would it be better to use the M core and leverage rpmsg APIs? We are aiming for low latency in our system while ensuring that no data from the MCU is missed.

Which approach would make more sense for our requirements?

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Hello,

I understand you’re evaluating the best approach for SPI communication between an additional MCU and an i.MX8MP MPU, focusing on low latency and reliable data transfer.

For your requirements, both approaches have their merits. Directly connecting the SPI to the A core (Application Processor) would allow for straightforward implementation and direct control over the SPI interface. This method is well-supported in Linux, and with the right driver and configuration, you can achieve efficient communication. However, managing SPI communication directly in the application processor might introduce latency and overhead, especially if the Linux system is under heavy load.

On the other hand, using the M core (Microcontroller) with rpmsg APIs for SPI communication can offload the management of I/O and sensor data from the main application processor. This method can potentially offer lower latency since the M core can be dedicated to handling real-time tasks and communicating with the MCU. The rpmsg (Remote Processor Messaging) framework is designed for inter-processor communication, allowing the A core to communicate with the M core efficiently. This setup can ensure that no data from the MCU is missed, as the M core can prioritize handling SPI messages.

Given your emphasis on low latency and ensuring reliable data transfer, leveraging the M core with rpmsg APIs might be more aligned with your goals. This approach can provide a more real-time capable solution by offloading the SPI communication to a processor dedicated to handling such tasks, thereby reducing the risk of data loss and minimizing latency.

However, this choice depends on your system’s specific requirements, including the processing power of the M core, the complexity of the data to be handled, and the overall system architecture. If real-time processing and minimizing data loss are critical, the M core with rpmsg might be the better choice. If system simplicity and direct control over peripherals are more important, direct SPI communication with the A core could be preferable.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

SPI (Linux) | Toradex Developer Center.

How did you like my response?

:+1: :-1:

3

Hello @Woba,

If you do not intend to use the SOC’s internal M core of the SOC then I do not think it makes sense to tunnel your external communication through the internal M core and then to the A core.

I would interface via SPI in Linux with the external MCU.

Best Regards,

Matthias

1 Like
4

Hello Mathias,

Thank you for the response. So I only need to write a driver to use the incoming data on the userspace right? Are there any examples realizing this kind of application? Do you have any kind of suggestion or roadmap that we can follow for our purpose?

Thanks!

5

Hello @Woba,

That is correct.

We provide an example for Torizon OS, which is generally applicable.

Best Regards,
Bruno

1 Like