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.
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.
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.
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.