Follow+Star Public Account Number, don’t miss wonderful content
Author | strongerHuang
WeChat Official Account | strongerHuang
You may often see multi-core CPUs in mobile phones and computers, but multi-core microcontrollers are relatively rare. With the increase in demand and the advancement of technology, microcontrollers are no longer limited to single-core, thus, in recent years dual-core microcontrollers have emerged.
You might be curious, how do dual-core microcontrollers communicate with each other? In fact, there are many ways and methods to communicate. This article will describe to you: using FreeRTOS message buffer to achieve simple asymmetric multi-processing (AMP) core-to-core communication, taking the STM32H7 (M4 and M7) dual-core processor as an example.
Before sharing the main text, I recommend a platform for embedded job information:
The communication between STM32H7 dual cores is a solution provided by FreeRTOS, based on the FreeRTOS message buffer, which is a lock-free circular buffer that can transfer packets of different sizes from a single sender to a single receiver.
Note that this message buffer only provides data transmission and does not provide communication-related protocol handling.
The basic principle of achieving 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, meaning 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 the shared memory at an address known to the application running on each core, as shown below:
Ideally, there will also be a memory protection unit (MPU) to ensure that the message buffer can only be accessed via the core’s message buffer API and preferably mark the shared memory as not being occupied by other programs.
Single Message Code Description
Here is the basic code provided by the official 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 && 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 && 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() waiting for the buffer to contain data, sending data to the buffer must unblock that task so it can complete its operation.
When xMessageBufferSend() calls sbSEND_COMPLETED(), the task will not be blocked.
ISR unblocks the task by passing the message buffer handle as a parameter to the xMessageBufferSendCompletedFromISR() function.
As shown by the arrows in the figure, where the sending and receiving tasks are located on different MCU cores:
1.The receiving task tries to read data from an empty message buffer and enters a blocking state waiting for data to arrive.
2.The sending task writes data to the message buffer.
3.sbSEND_COMPLETED() triggers an interrupt in the core where the receiving task is executing.
4.The interrupt service routine calls xMessageBufferSendCompletedFromISR() to unblock the receiving task, which can now read from the buffer as 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, considering the case 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 ways to implement:
-
If hardware allows, each message buffer can use a different interrupt line, thus 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.
-
A single message buffer can be used to pass metadata (what the message is, what the expected recipient of the message is, etc.) along with the actual data instead of multiple message buffers.
However, if there are a large number or unknown message buffers, these techniques are not efficient.
In this case, 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 that contains 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, &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 get the handle and passes that handle 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, &xUpdatedMessageBuffer, sizeof( xUpdatedMessageBuffer ), &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, &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, the sequence when using a control message buffer:
1.The receiving task tries to read data from an empty message buffer and enters a blocking state waiting for data to arrive.
2.The sending task writes data to the message buffer.
3.sbSEND_COMPLETED() sends the handle of the message buffer that now contains data to the control message buffer.
4.sbSEND_COMPLETED() triggers an interrupt in the core where the receiving task is executing.
5.The interrupt service routine reads the handle of the message buffer that contains data from the control message buffer and then passes that handle to the xMessageBufferSendCompletedFromISR() API function to unblock the receiving task, which can now read from the buffer as it is no longer empty.
Of course, the above only provides basic principles and methods; specific implementations need to be combined with actual project situations. For more related content, please refer to the official relevant materials.
● Column “Embedded Tools”
● Column “Embedded Development”
● Selected Tutorials in Embedded Column
Follow the public account reply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.
Click “Read Original” to see more shares.
