Theoretically, what would be the most efficient way to move data from the PRU to an external drive?
I’m currently using both PRUs on a Beaglebone Enhanced (Black) to capture ADC data and write it to DDR memory for the main ARM processor to access. Allocating space in the device tree and then using mmap to access the DDR from Linux user space works. Currently, one address in that block is being polled by a user space program to determine if the data is ready. I’m certain there is a better way to notify the main system processor and user space program that data is ready, like an interrupt, but the system is working.
My question is, if I wanted to store this data on a USB thumb drive or disk, would it be possible to bypass the main processor altogether? The PRUs can access system memory, and memory can be mapped to a file, so can they write directly to it?
Yes, there are PRU interrupts to the ARM host processor, and vice versa. If you are using remoteproc, check the vring driver implementation for PRU.
You may also try to implement your algorithm using a “blocking” RPMSG call in the PRU firmware. I.e., modify the echo example to return data only when PRU is actually ready.
I tend to agree with dinux. While anything is possible given enough time and effort, if you are asking what’s easiest/feasible/practical, then you are far better off letting the PRU do it’s real-time work, deliver the artifacts of that work to the main processor, then have the logic on the main processor do the data management of transferring that data to a storage medium.
Now if you are just looking for a project and something to do, and the feasibility of it isn’t a concern, then you’ll be on an adventure to figure out how to program the USB communications interface standard along with the USB Mass Storage Device Interface into a PRU…then you’ll have to use that interface to push your data into a file. While it MIGHT be possible, I can’t imagine why someone would want to go through that brain-damage voluntarily when that’s not really the PRU’s legerdemain. PRU’s are excellent at performing demanding real-time tasks that require low latency reaction & response times. But once their primary task has been accomplished and the work-product is no longer within the real-time envelope (i.e. saving data that’s already in RAM to non-volatile storage), then you are far better off using existing tried-n-true solutions. In fact, even if you did succeed in accomplishing this feat, you may find that the code to perform these USB tasks would hinder or out-right prevent the PRU from also performing its current primary function (if that’s at all a concern). You’d likely want to coordinate those two tasks between multiple PRU processors so one managed the USB while the other continued to do what it does with your ADC. But if you are going to have to coordinate the transfer of data between two PRUs, then you might as well just coordinate between the PRU and the main processor…IMO.
But if you just need to live in a world where PRUs can write data to files via USB, who am I to say that you shouldn’t make that happen.