Hi beezerlm! Am Mittwoch, 5. Oktober 2016 18:11:18 UTC+2 schrieb beezerlm: > > 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 > <http://www.google.com/url?q=http%3A%2F%2Fprocessors.wiki.ti.com%2Findex.php%2FPRU_Training%3A_Hands-on_Labs%23Hardware&sa=D&sntz=1&usg=AFQjCNHGd-ovDR-Bp8b8I9wIJfnievtImQ> > >
I didn't use JTag yet. And I don't use the bloated TI tools. Instead I use the lightweight pasm assembler and uio_pruss driver. > 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. > You can develop everything from scratch, the subsystem configuration and your controller loop. Or you can use the configuration from libpruio, use the high level API to set the registers in a convenient way and just add some individual controller loop code. 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. > Your costomized code can run either on the ARM or at the other PRU. > 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. > What is eQEP0? There're three PWMSS (subsystems), each of them have one eQEP module with the same features. So there is PWMSS-0.eQEP, PWMSS-1.eQEP and PWMSS-2.eQEP. All of them have the same interrupt features. And you don't need them. Better poll the current state for lower latency. 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 > The pin names are input A, input B, index and strobe. You could also use PWMSS-2 (@ P8_12, P8_11, P8_16). Or -- when HDMI is disabled -- PWMSS-1 (@ P8_35, P8_33, P8_31) or PWMSS-2 (@ P8_41, P8_42, P8_39). 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? > I also coudn't find tutorials. I figured it out by trail and error. I have some trouble when dynamically switching between modes, see this thread <http://e2e.ti.com/support/arm/sitara_arm/f/791/p/390207/1377566#1377566>. But TI couldn't help. (This isn't related to your use case.) 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/fe2ef005-004a-4d61-be22-8e2a47e2e9bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
