Hi all. I'm trying to cram a lot of realtime work onto a single BBB, and things are getting tight.
I've *fully* consumed PRU1 and I've got a lot of realtime work left to do. One of the things that I need to do is to get a bunch of ADC readings. Specifically I need to get 5 12-bit readings on a 31250Hz sample rate. (31250Hz is not strictly necessary. 31250Hz is in the 20kHz to 60kHz range and is easy to get to off the 200MHz PRU clock, but really anything between 20kHz and 60kHz will do fine) I've implemented this on PRU0 by bit banging SPI to a couple ADCs with 300ksps rates. It works just fine, and I even have a few spare cycles on PRU0 to mess with...but not really enough. The other thing that I need to do is implement my control algorithm which takes the values from the ADC, does its thing, and then feeds values to the program running on PRU1. This also has to happen in realtime and requires some floating point (or quasi-floating-point) calculations. If I'm bit banging my ADCs, then PRU0 just doesn't have enough spare cycles to get the job done. So, I'm looking for options. Based on my reading it seems as though I ought to be able to drive the am335x hardware SPI modules directly from the PRU by reading and writing to the McSPI registers via the constants table. The fact that these are pointed to by the constants table indicates to me that TI was figuring that people would do this all the time! The hope is that this would take a big load off my PRU0 and very likely free it up enough to run my calculations. Nice trick, but I have not been able to dig up any examples of this PRU->McSPI online. I'm also not sure what kind of determinism I could hope for with such a scheme. It looks like the way from the PRU to the MCSPI is over the L4 buss and so read latencies are reported to be 34 PRU cycles... best case... no promises. This is perfectly fine if I can run the McSPI continuously (aka regularly), which appears to be possible, but not clearly straightforward. The not straightforward bit seems to be channelling the interrupts that are generated by the McSPI to the PRU so that the PRU can know when to go and pick up the new data. It appears that this signaling would have to be done through the interrupts because if you have to burn 34 cycles for every register poll you make, then you would again consume a big portion of your PRU cycles and things don't look much better than for bit banging. Anyone out there tried this sort of thing? Is this a good/bad idea? The other option I have is to install the PREEMPT_RT patch and run some of the realtime stuff in the host program, and leave PRU0 bit banging the ADCs. That would likley get me more horsepower in the end, but I am way (way!) more familiar with the PRU's than the linux kernel, and so I am rather intimidated by that path... and I haven't been able to any docs that make it look straightforward. I have found some stuff that make PREEMPT_RT sound possible, but with a big old learning curve to climb. I should say that if I'm bit banging my ADCs and doing the calculations on the host, then I don't need to turn my calculations around on 20kHz. Turning a batch of calculations every 1kHz would be just fine. Suggestions much appreciated. Thanks, Bill -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
