Exchanging buffers with the coprocessor

1. Introduction

In the STM32MPU Embedded Software distribution, the RPMsg protocol allows the communication between the Cortex-A and the Cortex-M .

To implement a feature relying on RPMsg protocol, it is important to understand that this protocol has not been designed to directly transfer high data rate streams. In consequence, the implementation has to be adapted depending on the use case constraints:

• For control and low data rate exchange RPMsg is enough.
• For high rate transfer, large data buffers, an indirect buffer exchange mode should be preferred.

2. RPMsg protocol awarness

The RPMsg provides through the virtio framework a basic transport layer based on a shared ring buffer:

• The buffers are pre-negociated and preallocated during coprocessor loading (size , number of buffers).
• The buffers are allocated in non cacheable memory.
• There is no direct access from RPMSG client to these buffers, they are filled by a copy (no zero copy or DMA transfers).
• No bandwidth is guarantied. Buffers can be shared between several RPMsg clients.

The size of the buffers is hard-coded (512 bytes), but it is possible to customize the number of buffers used. Acting on this parameter will impact the number of buffers allocated in both direction ( refer to resource table for details).
Associated to a RPMsg transfer a doorbell signal is sent to the destination processor via the stm32 IPCC mailbox, generating an IRQ for each message transfer.

3. Direct Buffer exchange mode

This mode consists in using the RPMsg buffer to transfer the data between the processor.

• The RPMsg message contains effective data.
• Memory allocation is limited to the RPMsg buffers allocation.
• RPMsg client implementation is quite straight forward in term of code implementation.

This implementation is recommended:

• for control message, for instance to control a remote processor application,
• to exchange low data rate stream (similar to a slow data rate bus).

For application sample, please refer to List of Availables Projects and have a look into OpenAMP_TTY_echo application.

4. Indirect buffer exchange mode

This mode also called "Big Data" or "large data buffers exchange" mode consists in using RPMsg to carry references to some other buffers that contain the effective data. These other buffers can be:

• any size,
• allocated by multiple means, in cached or non cached memory, in DDR or MCU SRAM, ...
• mmapped for direct access by application,
• accessed by DMA or any master peripheral.

This implementation allows to limit data copy between producer and consumer, offering direct data access to buffer clients such as applications.

In the overview above, rpmsg_sdb is a driver provided as example, offering to the application an interface to allocate and exchange buffers with the remote processor.

This implementation is recommended:

• for high bit rate transfer (e.g. visual buffers),
• for real time transfer (e.g. audio buffers),
• to privilege dynamic buffers allocation,
• ...

For details on mechanisms put in place for buffer exchanges please refer to: how to exchange large data buffers with the coprocessor principle article
For application sample, please refer to How to exchange large data buffers with the coprocessor example article.

Cortex^®

Remote processor messaging

Direct memory access

Open Asymmetric Multi-Processing (See https://www.openampproject.org/)

TeleTYpewriter

Doubledata rate (memory domain)

Microcontroller unit (MCUs have internal flash memory and are intended to operate with a minimum amount of external support ICs. They commonly are a self-contained, system-on-chip (SoC) designs.)