iMX.7 RemoteProc Communication Speed?

Dear All.

I have a Aster Board along with Colibry iMX7. I wish to do some sensing through SPI in M4 Core and transfer 32 Bytes of per mili second i.e. 1000 Times per second to the Linux Core.

  1. How can this be achieved?
  2. Can RPMsg handle this kind of speed or more?

Regards
Kashyap

Dear @gada.kashyap

I never did performance measurements of RpMsg transfers so far. My estimation is:

  • On the M4 side, it should be no problem to achieve the required speed:

    • The SPI transfer takes aproximately 32 Bytes * 8 Bits/Byte / 10e6 Bits/s = 26 µs
    • Access to DRAM is much faster than the requied 32kB/s.
  • There’s probably an issue on the Linux side: Linux is not a real-time operating system, so you will probably struggle to read one message every ms.
    The number of RpMsg buffers is also limited. So if Linux fails to process the buffers in time, the queue will stall and in turn block the M4 from adding new messages.
    Anyway, Linux will likely not be able to process data that often.

I recommend to collect more data on the M4 side, and for example send messages of 3200 bytes once every 100ms.
The additional effort on the M4 is neglectable, but it reduces the Linux overhead massively.

Regards, Andy

Dear @andy.tx

Thanks for you reply.

Collecting the data at M4 controller for a specific period of 100ms and then sending it to A7 processor is a very nice suggestion.

Actually I wouldn’t mind collecting even more data lets say for 10 or 20 seconds and then push the collected data to the processor, though the size of transfer would increase. BTW what is the maximum capacity of RPMsg? and how many buffers are available?

Another question arises that if we are doing the 100ms suggestion by you, will be the Processor be able to keep up to the speed of data being received by it from M4?

I want to Acquire data from ADC SPI tag those with GPS locations. The collected data then would require some processing and then pushed over to a cloud server.

What should be an appropriate way to go about it for distributing the software among A7 and M4.

Thanks for the above suggestion any way. It made my vision broader about developing applications with embedded linux.

Regards

Dear @gada.kashyap

RpMsg Buffers

The size of an RpMsg buffer as well as the number of available buffers are both defined on the Linux side. By default there are 256 buffers, 512 bytes each.

See also the following community post:

On the M4 side, you need to match the defines RPMSG_BUFFER_SIZE in rpmsg_core.h and RPMSG_NUM_BUFS in platform_info.c.

Linux Processing Cycle

A cycle time of 10 - 100ms is usually no issue for Linux. Depending on the CPU load, also 1ms can be achieved

To keeps things simple, you could start with the default RpMsg buffer size, which is sufficient to hold samples for 16ms (16 ms x 32 bytes/ms = 512 Bytes).
As there are 256 buffers, it is even no problem if the Linux side gets delayed exceptionally.

If you want to change the RpMsg buffer size anyway, it doesn’t really matter how big you make them. I would use whatever buffer size is a good fit to structure your samples logically.

A7 vs M4 processing

There’s probably plenty of performance available on both the M4 and A7 side to do the required processing.
Do the processing on the CPU where you feel it is the easiest to implement and debug, and most important to maintain the software in the future.

I would clearly keep the high-level part (cloud connectivity) on Linux. There are much more comfortable cloud libraries available under Linux than under FreeRTOS.

Regards, Andy

Dear Andy,

Thanks for your insights.

Would work on the same and revert if any issues.

One last thing I would like to know with regards to above question, whether we could go in for a pure linux solution with Preempt-rt patch?

Regards
Kashyap

Dear @gada.kashyap

Using the Preempt-rt patch should also work. This approach is expected to have a jitter of about 100µs. If the actual timing of reading the ADC is not too much affected by this figure, you can also go with the pure Linux approach.

Regards, Andy