Well I have obtained a BBB along with the PRU cape. I soldered the Jtag header on and I purchased a blackhawk XDS100v2 JTAG Emulator. I istalled CCSv6 and I have completed the PRU labs 1 through 4 - found here: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#Hardware
I am trying to figure out where to go from here. Libpruio looks promising, but I would like to take the path that would offer the best overall determinism & latency characteristics for reading encoder input and controlling IO accordingly. I would think the best case scenario would be to program the PRU directly and skip linux altogether. This may be overkill for my current project, but it seems like it would be useful for more demanding applications I may cross in the future. My current PLC loop just sets an "Upper" stroke limit and a "Lower" stroke limit. It then uses if statements to determine when the current position meets or exceeds one of those two settings which activates a solenoid to change direction. It also counts the strokes and writes to some registers for the "Automatic grinding cycle". It is currently working, but the windows environment doesn't keep up very well. I would think the best case scenario would be to program the PRU directly and skip linux altogether. My understanding is that eQEP0 is the only eQEP that can directly interrupt the PRU's. I think this should be fine because I only need to read 1 encoder. It looks like the eQEP0 pins are on the P9 header as follows: P9 - pin 25 - eQEP0_STROBE P9 - pin 27 - eQEP0B_in P9 - pin 41B - eQEP0B_index P9 - pin 42B - eQEP0A_in I have read through the AM3358 TRM ( wow that is huge ) but I am not quite sure were to start as far as Initializing the eQEP0 and getting readings from the encoder? Are there any tutorials out there for programming the PRU's to read eQEP0 inputs, then use that information to trigger GPIO events? On Monday, September 12, 2016 at 9:53:45 AM UTC-4, TJF wrote: > > > > Am Sonntag, 11. September 2016 21:28:52 UTC+2 schrieb beezerlm: >> >> Hi TJF, >> >> So basically the libpruio is a driver that makes it easier to access >> the PRU and assign I/O and create a subsystem program loop? Is that >> correct? What would be the downside of using this driver? Added Latency? >> > > Not entirely correct. It doesn't provide access to the PRU. > > libpruio is a non-LINUX driver. Instead of one folder in sysfs for any > subsystem, it provides one shared library driving many subsystems. Instead > of reading lots of kernel docs, the user configures a feature for a header > pin and is done. That makes it easy and fast (~10 times lower latency than > kernel drivers) to access the CPU hardware (for digital IO and analog I). > Additionally libpruio provides access to each hardware register, so it's > highly flexible. Therefor it uses SW running on one PRU and a shared > library running on the ARM. > > Downsides: > > - Its limited to ARM335x CPUs (BBW, BBB, BBG). > - Just one PRU is free for your application. > > As far as I understand your target, a reciprocating pneumatic cylinder > isn't that fast and you should be happy with a main loop running in less > than 5 kHz. This you can realise in a high level compiler language running > on the ARM (as long as you don't have high interrupt loads). > > Often, I start my projects that way and when I learn in the concept phase > that the project needs better real-time capabilities, I transform the > controller loop from high-level language to PRU assembler. libpruio is > designed for that process. > > Regards > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/899919fa-940d-462d-afad-403e32a004e8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
