Implementing Message Communication Between Dual-Core MCUs Using RTOS

You may often see multi-core CPUs in phones and computers, but multi-core microcontrollers are relatively rare. With the increasing demand and technological advancements, microcontrollers are no longer limited to single-core, and in recent years, dual-core microcontrollers have emerged.

You might be curious about how dual-core microcontrollers communicate with each other. In fact, there are many ways and methods for communication. This article describes how to use FreeRTOS message buffers to achieve simple asymmetric multi-processing (AMP) core-to-core communication, taking the STM32H7 (M4 and M7) dual-core processor as an example.

Overview

Implementing communication between STM32H7 dual cores is a solution provided by FreeRTOS, based on FreeRTOS message buffers. This message buffer is a lock-free circular buffer that can pass data packets of different sizes from a single sender to a single receiver.

Note that this message buffer only provides data transmission and does not handle communication-related protocol processing.

Basic Principles

The basic principle of implementing communication between dual cores: the sending and receiving tasks are located on different cores of a multi-core microcontroller (MCU) in an asymmetric multi-processor (AMP) configuration, which means that each core runs its own FreeRTOS program.

At the same time, one core has the ability to generate interrupts in the other core, and both cores have access to a memory area (shared memory). The message buffer is placed in shared memory at an address known to the application running on each core, as shown in the figure below:

Implementing Message Communication Between Dual-Core MCUs Using RTOS

Ideally, there will also be a memory protection unit (MPU) to ensure that the message buffer can only be accessed through the core’s message buffer API, and it is best to mark the shared memory as unavailable to other programs.

Single Message Code Description

Here, the official provides basic code to implement this solution (for reference only).

Code to send data to the stream buffer:

xMessageBufferSend(){    /* If a time out is specified and there isn't enough    space in the message buffer to send the data, then    enter the blocked state to wait for more space. */    if( time out != 0 )    {        while( there is insufficient space in the buffer &amp;&amp;               not timed out waiting )        {            Enter the blocked state to wait for space in the buffer        }    }
    if( there is enough space in the buffer )    {        write data to buffer        sbSEND_COMPLETED()    }}

Code to read data from the stream buffer:

xMessageBufferReceive(){    /* If a time out is specified and the buffer doesn't    contain any data that can be read, then enter the    blocked state to wait for the buffer to contain data. */    if( time out != 0 )    {        while( there is no data in the buffer &amp;&amp;               not timed out waiting )        {            Enter the blocked state to wait for data        }    }
    if( there is data in the buffer )    {        read data from buffer        sbRECEIVE_COMPLETED()    }}

If a task enters a blocked state in xMessageBufferReceive() while waiting for data to be present in the buffer, sending data to the buffer must unblock that task so it can complete its operation.

Additionally, when xMessageBufferSend() calls sbSEND_COMPLETED(), the task will not be blocked.

The ISR unblocks the task by passing the message buffer handle to the xMessageBufferSendCompletedFromISR() function.

As shown by the arrows in the figure, the sending and receiving tasks are located on different MCU cores:

The receiving task attempts to read data from an empty message buffer and enters a blocked state to wait for data to arrive.
The sending task writes data to the message buffer.
sbSEND_COMPLETED() triggers an interrupt in the core where the receiving task is executing.
The interrupt service routine calls xMessageBufferSendCompletedFromISR() to unblock the receiving task, which can now read from the buffer since it is no longer empty.

Multi-Message Code Description

When there is only one message buffer, it is easy to pass the message buffer handle to xMessageBufferSendCompletedFromISR().

However, in cases where there are two or more message buffers, the ISR must first determine which message buffer contains data.

If the number of message buffers is small, there are several methods to achieve this:

If hardware permits, each message buffer can use different interrupt lines, maintaining a one-to-one mapping between the interrupt service routine and the message buffer.
The interrupt service routine can simply query each message buffer to see if it contains data.
Instead of multiple message buffers, a single message buffer can carry metadata (what the message is, what the expected receiver of the message is, etc.) as well as the actual data.

However, if there are many or unknown message buffers, these techniques are inefficient.

In such cases, a scalable solution is to introduce a separate control message buffer. As shown in the code below, sbSEND_COMPLETED() uses the control message buffer to pass the handle of the message buffer containing data to the interrupt service routine.

Implementation using sbSEND_COMPLETED():

/* Added to FreeRTOSConfig.h to override the default implementation. */#define sbSEND_COMPLETED( pxStreamBuffer ) vGenerateCoreToCoreInterrupt( pxStreamBuffer )
/* Implemented in a C file. */void vGenerateCoreToCoreInterrupt( MessageBufferHandle_t xUpdatedBuffer ){size_t BytesWritten.
    /* Called by the implementation of sbSEND_COMPLETED() in FreeRTOSConfig.h.    If this function was called because data was written to any message buffer    other than the control message buffer then write the handle of the message    buffer that contains data to the control message buffer, then raise an    interrupt in the other core.  If this function was called because data was    written to the control message buffer then do nothing. */    if( xUpdatedBuffer != xControlMessageBuffer )    {        BytesWritten = xMessageBufferSend(  xControlMessageBuffer,                                            &amp;xUpdatedBuffer,                                            sizeof( xUpdatedBuffer ),                                            0 );
        /* If the bytes could not be written then the control message buffer        is too small! */        configASSERT( BytesWritten == sizeof( xUpdatedBuffer );
        /* Generate interrupt in the other core (pseudocode). */        GenerateInterrupt();    }}

Then, the ISR reads the control message buffer to obtain the handle and passes it as a parameter to xMessageBufferSendCompletedFromISR():

void InterruptServiceRoutine( void ){MessageBufferHandle_t xUpdatedMessageBuffer;BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    /* Receive the handle of the message buffer that contains data from the    control message buffer.  Ensure to drain the buffer before returning. */    while( xMessageBufferReceiveFromISR( xControlMessageBuffer,                                         &amp;xUpdatedMessageBuffer,                                         sizeof( xUpdatedMessageBuffer ),                                         &amp;xHigherPriorityTaskWoken )                                           == sizeof( xUpdatedMessageBuffer ) )    {        /* Call the API function that sends a notification to any task that is        blocked on the xUpdatedMessageBuffer message buffer waiting for data to        arrive. */        xMessageBufferSendCompletedFromISR( xUpdatedMessageBuffer,                                            &amp;xHigherPriorityTaskWoken );    }
    /* Normal FreeRTOS "yield from interrupt" semantics, where    xHigherPriorityTaskWoken is initialised to pdFALSE and will then get set to    pdTRUE if the interrupt unblocks a task that has a priority above that of    the currently executing task. */    portYIELD_FROM_ISR( xHigherPriorityTaskWoken );}

As shown in the figure above, the sequence when using the control message buffer is:

The receiving task attempts to read data from an empty message buffer and enters a blocked state to wait for data to arrive.
The sending task writes data to the message buffer.
sbSEND_COMPLETED() sends the handle of the message buffer that now contains data to the control message buffer.
sbSEND_COMPLETED() triggers an interrupt in the core where the receiving task is executing.
The interrupt service routine reads the handle of the message buffer containing data from the control message buffer, then passes that handle to the xMessageBufferSendCompletedFromISR() API function to unblock the receiving task, which can now read from the buffer since it is no longer empty.

Of course, the above only provides basic principles and methods; specific implementations should combine the actual project situation. For more related content, please refer to the official relevant materials.

END

Source: strongerHuang

Copyright belongs to the original author. If there is any infringement, please contact us for deletion.

▍Recommended Reading

Huawei C/C++ coding standards leaked

C language includes are not as simple as you think!

After joining as a Linux driver engineer, I discovered the truth…

→ Follow us to stay updated ←

Leave a Comment Cancel reply