Adding PRU eCAP to beaglebone-universal-io

Doing event capture with the PRU’s eCAP peripheral is absolutely perfect for my application. And TI’s newer “pru_ecap.h” header and their (very thorough) Technical Reference Manual make it look pretty easy. I only wish I could get that far!

It looks like the “pr1_ecap0_ecap_capin_apwm_o” signal (which sounds like what I need) is exposed on P9_42 in mode 3 (and maybe P8_15 in mode 5 too?), but beaglebone-universal-io doesn’t expose that pinmux on either pin.

Adding it myself looked pretty straightforward, though I’m still very new to device tree overlays. This is what I’ve come up with so far: http://pastebin.com/TAH2GHFT

That compiles but then config-pin errors out with something like “/bin/bash error on line 0” (not exact; I’m away from that machine). I’m hoping that I’m just missing something obvious and that someone with more device tree experience will spot it right away.

If anyone has any advice, I would be grateful! Hopefully once this is working, it can get rolled back into beaglebone-universal-io so everyone has easier access to this powerful peripheral.

Thanks!
Nicholas

The changes to both the device-tree and config-pin scripts look OK.

Given the error, I'm wondering if you maybe edited the config-pin
script on a Windows machine and got line-endings messed up? That will
confuse bash to no end. :slight_smile:

Otherwise, you can verify the device-tree changes work by poking
around manually in sysfs, and use standard script debugging to figure
out what's wrong with config-pin (try "set -xv" to start).

Thanks for the super fast reply, Charles! (And thanks for beaglebone-universal-io. It makes development on the BBB actually-approachable!)

I have access to the device now, so here is the real error message:

(This is after a reboot, make, make install, and echoing the universal cape to the cape manager)

./config-pin -a P9_42 ecapin

bash: line 0: echo: write error: No such device

Tracking it down a bit, I can produce the same message by doing what config-pin is trying to do:

/sys/devices/ocp.3/P9_42_pinmux.47# echo ecapin > state
bash: echo: write error: No such device

So now my question is which magic word does “state” want to see? (Things like “gpio” and “pwm” work just fine there.) I had picked “ecapin” to try and match the style of the other names. Is there a premade identifier someplace that has to be used instead or is that free-form text that just has to match the line in dts?

Is this something that needs to be added to the kernel before it will work? (I’m using 3.8.13-bone73.)

Thanks again,
Nicholas

Thanks for the super fast reply, Charles! (And thanks for
beaglebone-universal-io. It makes development on the BBB
actually-approachable!)

I have access to the device now, so here is the real error message:

(This is after a reboot, make, make install, and echoing the universal cape
to the cape manager)

# ./config-pin -a P9_42 ecapin
bash: line 0: echo: write error: No such device

Tracking it down a bit, I can produce the same message by doing what
config-pin is trying to do:

/sys/devices/ocp.3/P9_42_pinmux.47# echo ecapin > state
bash: echo: write error: No such device

So now my question is which magic word does "state" want to see? (Things
like "gpio" and "pwm" work just fine there.) I had picked "ecapin" to try
and match the style of the other names. Is there a premade identifier
someplace that has to be used instead or is that free-form text that just
has to match the line in dts?

It just has to match what you put in DTS.

Is this something that needs to be added to the kernel before it will work?
(I'm using 3.8.13-bone73.)

My guess is you're actually using the unmodified overlay and not your
tweaked version. If so, you're tripping over the pre-compiled DT
overlays included in the kernel.

The workaround is to rename your modified *.dtbo overlay file to
something new so it won't be found in the compiled-in list and the
kernel will look for the file in /dev/firmware.

...or update the kernel source and build a new kernel. :wink:

You are my hero! Renaming the dtbo was all it took and my PRU eCAP test worked on the first try.

Now that I know it works, this feels like the kind of thing I should submit as a pull request. Assuming that’s alright with you, I’m guessing my next steps are to clean this up a bit, drop my custom-named version, also add and test the same mapping on P8_15, then duplicate all of that in the universaln and universala versions, too. Is there anything else I’m missing?

Thanks so much! Cheers,
Nicholas

I'm glad it's working! The compiled-in overlay files has bitten me
more than once as well. :slight_smile:

The changes you list sound good, I look forward to the PR. Holler if
you get stuck or have any questions.