On 11/22/2013 5:08 AM, Ozan Çağlayan wrote: > On Thu, Nov 21, 2013 at 10:49 PM, Charles Steinkuehler > <[email protected]> wrote: >> On 11/20/2013 9:30 AM, Ozan Çağlayan wrote: >>> I enabled the virtual PRU cape using device tree overlay and >>> successfully compiled and launched the blink code I found on the >>> internet but I'm quite confused in finding out which GPIO pins are >>> accessible/available from PRU. There are a lot of documents, specs, >>> pin names, gpio offsets, pinmuxes, etc. Do I need to apply a dtbo for >>> having 2xGPIO or are there already available ones that the PRU can >>> access? >> >> The PRU can control all GPIO pins, just write directly to the set and >> clear registers. > > So are the pr_pru[01]_* modes for some pins are just for faster GPI/GPO > access?
Yes, those are the direct PRU I/O, and have virtually no delay. It takes about 100 nS to write to an arbitrary GPIO pin using the PRU to talk to the GPIO registers. >> There are many ways to create a delay. The easiest would just be a >> software loop, or you can use the IEP timer documented in the latest PRU >> reference manual, or many other options. More detail about exactly what >> you're trying to do, what you've tried, and your design constraints will >> probably get you more useful help. > > Thanks for the pointers. A timer will be much easy if it is easy to implement > :) > > What I'm trying to do is to flicker 2 LEDs with different flickering > rates, say 15Hz and 18Hz or 18Hz and 19Hz (but not much than ~25Hz). > A userspace code will trigger this flickering and do another stuff. > Once it decides to stop the flickerings, it will notify the PRU and > the PRU will stop flickering/driving the LEDs. > But after some while the userspace code may again decide to start > flickering. So one possibility is to launch and terminate the firmware > each time but I don't know if loading the firmware and executing it > has a big overhead or not. Another is to use some busy waiting in the > firmware so that the code just does nothing unless the userspace code > tells him to start flickering. > > I don't know which one is easier though. I would suggest you leave the PRU code running all the time, but have settings for always off and always on as well as "blink rate". Then once everything is setup your application can do whatever it wants without having to worry about (re)loading the PRU code. Also, for 25 Hz pulse rates, you can get pretty good performance without using the PRU, unless your blinking needs to be very precise or low jitter for some reason. Using the PRU for this really seems like overkill. As for timers, I've got example code using the IEP timer to blink some LED's in my LinuxCNC repository: https://github.com/cdsteinkuehler/linuxcnc/blob/MachineKit-ubc/configs/ARM/PRU-Debugger/pruexample.p -- Charles Steinkuehler [email protected] -- 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/groups/opt_out.
