Rproc bandwidth - threading


We building an application to use a PRU to do realtime DAQ using an ADC. The PRU code is done, but due to the datarate (52.7ksps at 24 bit/sample * 8 channels) we are having problems with the buffers in the rpmsg framework. The PRU does the DAQ, and pushes it trough the rproc/rpmsg framework to our linux userspace application. There we recuperate the data and write it to a file.

Now the problem we are experiencing is that the VRing buffers are probably overflowingl due to threading of our userspace program. The retrieval of the data from the character device goes well for a while, and suddenly we get some data loss, and it goes back to working for a while,… In Dmesg we get messages like this:


[ 2591.809917] rpmsg_pru rpmsg0: Message length table is full


We already tried grouping samples to make maximum use of the 512byte buffers, and in the resource table we increased the number of buffers to the maximum of 256. This improved the behaviour a bit, but the problem persists although less frequent. Increasing the userspace process priority does not improve this nor does setting the cpu governor to performance

Is there a way to increase the buffer size of the RPMSG messages so more samples can be grouped together in a single message? Changing these definitions in the kernel module and recompiling it?

#define MAX_RPMSG_NUM_BUFS (512)
#define RPMSG_BUF_SIZE (512)


Or is there a way to increase processing time for our userspace application to reduce the time not reading the buffers?

Thanks in advance


Have you thought about using carveouts in your resource table instead of rpmsg? I have a program that reads a camera and writes to a carveout, then uses debugfs on the Linux side to map the carveout into userspace. Doing this you can cut out the overhead of the message passing and just have a big chunk of shared memory between the PRU and the application processor, and you can handle the flow control yourself.