Best way to get data into PRU

Hi All,

I’m a little confused as to how to get data into the PRU using remoteproc/vrings.

Background:

I have successfully adapted the remoteproc examples to get an LED matrix scrolling message board working with an initial test image. I can also send data to /dev/rpmsg_pru30 to turn the display on and off (echo B >> /dev/rpmsg_pru30).

Now, I want to send the display new display data, which is approximately 1152 bytes (144 pixels by 8 rows). Trying to follow the pru_rpmsg.h/.c code, I see a constant called RPMSG_BUF_SIZE 512 with note that this size includes the header overhead (pru_rpmsg_hdr looks like 17 bytes).

So, if I want to use virtqueues, it looks like I will have to invent some kind of protocol to transmit chunks of data at a time until I get the whole image transferred.

Is this correct?

Can I use the /dev/rpmsg_pru30 device for this purpose?

Is this the standard way to get this kind of data into the PRU, or am I thinking about this incorrectly.

Thanks!

–David

I’m working on a similar problem, but it’s the opposite direction. I’m trying to pull data from the PRU, into the ARM.

What are you using for a data structure in the PRU to hold the data?
Have you looked at the user-space C program in Lab 5 called rpmsg_pru_user_space_echo.c ?
It’s perhaps not the best example to illustrate what to do, but note the “open/read/write/close” functions which are a fundamental POSIX way to read/write data.

I’m thinking that if you have an array declared to hold 1152 bytes in the PRU, you could do three transmissions from user space and fill your array in the PRU.

I’m very new to this, so what I am suggesting may be very inefficient, but I think fundamentally it should work.

Greg

If trying to pull data from the PRU, into userspace Linux. You may wish to consider mmap()ing the 8k PRU data ram, or he 12k shared PRU ram. Then, you just toggle a bit somewhere in that ram, to let the PRU tell the userspace side it’s ok to copy. I’ve done this from userspace to userspace as a way of locking a shared memory file, and it is very fast.

If speed is paramount, You may wish to involve both PRU’s, broadside the data from one to the other, and then have the second PRU communicate with userspace. I’d have to give this some more thought after writing experimental code to make sure of a couple things. But I’m fairly sure this is a good way to approach this sort of problem.

As for remoteproc . . . not idea what remoteproc is capable of. But uio_pruss can do this fairly easily.