Communicating different messages via RPMSG

[D_TTSA]

Good day

I would like to use RPMSG to communicate two different types of messages between the M4 and M7 cores on the RT1170-EVK. Using the evkmimxrt1170_rpmsg_lite_pingpong_cm4 and _cm7 examples, I am able to communicate a message between the M4 and M7.

However, I would like to communicate two different types of messages, with completely different structure. I thought I could perhaps create a union for the message struct, but this won't work for my application. The reason is as follows: I send the one type of message periodically, and the other message on-demand (ie. aperiodically). This means the periodicity of my one message type would be lost if the processor tries to send the aperiodic message when the periodic message should be sent.

Is there a way to create two endpoints on the M7 core and two endpoints on the M4 core? I tried doing this but it stops the rpmsg_lite_is_link_up(my_rpmsg) function call in the M4's project from testing true. Or is there another way of facilitating communication between the two cores?

[Alexis_A]

Hello @D_TTSA,

For this particular application I will suggest to use the examples that shows how to use Messaging Unit (MU), the MU has multiple channels that can be used to sent the structures that you mention separately, the example that I mention are the following ones:

Let me know if this helps you.

Best Regards,
Alexis Andalon

[D_TTSA]

Thank you for your response @Alexis_A 

This was very helpful! I am looking into these examples.

Is there a performance difference between using RPMSG-lite and MU for inter-core communication? I know that RPMSG-lite uses a copy-less communication mechanism, making it very fast. It can also send as many bytes as required in a single message.

From inspecting the code, it seems that MU writes the message to a register, instead of passing a pointer to shared memory like RPMSG-lite. I imagine that RPMSG would be faster as a result? Could you please confirm this.

Also, I see that MU only sends one uint32_t per message. Is there a way to transfer more information? The only solution I can think of is using MU to send a pointer to a shared memory location that contains a known number of bytes of information. However, this introduces another problem - I will need to ensure that this shared memory region is not cached by the M4 or M7... What is your suggestion here?

Kind regards

[Alexis_A]

Hello @D_TTSA,

As you mention performance-wise, using the MU would be slower since your sending byte per byte through the MU interface to the other core.

About your suggestion, in the following post it explain how to set the MPU to set a memory region to Non-cacheable but as an other way to set this is that instead of a pointer to a shared memory region using a flag to let know the other core which buffer is placed in a fixed region could be another option.

Best Regards,

Alexis Andalon

[D_TTSA]

Hi @Alexis_A 

Thank you for your response.

Could you possibly expand on the alternative you mention "as another way"?

I'm not sure if I understand how I could use buffers to pass information between the two cores without placing the buffers in shared memory that is configured as non-cacheable.

Kind regards

[Alexis_A]

Hello @D_TTSA,

The only thing that I suggest different to your approach is that instead of sharing a pointer, only share a flag and a fixed memory space.

Best Regards,

Alexis Andalon

[D_TTSA]

Hi @Alexis_A 

Thank you for your response, that makes sense.

Could you perhaps explain how to set a memory region to non-cacheable?

I know you provided a link on the ARM MPU, but I am new to this. I don't think I understand how to translate the information given there into code.

Kind regards

[Alexis_A]

Hello @D_TTSA,

Please check the API BOARD_ConfigMPU, this has some comments that explain in detail the input parameters for the registers RBAR and RASR.

Best Regards,

Alexis Andalon

[D_TTSA · Accepted solution]

Thank you @Alexis_A 

For those who want to do something similar to me:

I found the easiest solution was to simply place the data buffer in the NCACHE_REGION, as defined in the memory configuration by default.

I did this using a macro from cr_section_macros.h.