On 8/4/2015 10:56 AM, Nicholas Piegdon wrote: > 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.
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. :) 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). -- 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/d/optout.
