Using GPIO

>>
>>
https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universaln-00A0.dtsmakesme think that P9-31 isn't requested by cape-universaln, yet the
>> conflict still happens. Leaving the .dts files around might be
helpful.

Look in: /opt/source/beaglebone-universal-io/

> I think I found it:
> cape-universaln: remove P9_31 by jadonk · Pull Request #5 · cdsteinkuehler/beaglebone-universal-io · GitHub

Thanks Jason! Merged.

I always disable the HDMI (with audio) so didn't catch this one.

Still getting the error and trying to track it down.

Rename the file and echo it into the slots later once in userspace. (it
has the same name as the file built-into the kernel)

That did it!

BTW, did you see the pull request on cape-firmware? Are we not going to
encourage cape makers to push their .dts files there? Is there a good
upstream for them that doesn't involve our massive patch tree?

>>
>>
https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universaln-00A0.dtsmakesme think that P9-31 isn't requested by cape-universaln, yet the
>> conflict still happens. Leaving the .dts files around might be
helpful.

Look in: /opt/source/beaglebone-universal-io/

> I think I found it:
> cape-universaln: remove P9_31 by jadonk · Pull Request #5 · cdsteinkuehler/beaglebone-universal-io · GitHub

Thanks Jason! Merged.

I always disable the HDMI (with audio) so didn't catch this one.

Still getting the error and trying to track it down.

Rename the file and echo it into the slots later once in userspace. (it
has the same name as the file built-into the kernel)

That did it!

BTW, did you see the pull request on cape-firmware? Are we not going to
encourage cape makers to push their .dts files there? Is there a good
upstream for them that doesn't involve our massive patch tree?

I was able to get PWM output, but I'm struggling with GPIOs for some reason:

root@beaglebone:~# dash -x `which config-pin` P9_18 out
.
.
.
+ sudo -A su -c echo out > /sys/class/gpio/gpio4/direction
+ echo_dbg echo gpio > /sys/devices/ocp.3/P9_18_pinmux.36/state
+ [ -n ]
+ sudo -A su -c echo gpio > /sys/devices/ocp.3/P9_18_pinmux.36/state
+ exit 0

root@beaglebone:~# cat /sys/devices/ocp.3/P9_18_pinmux.36/state
gpio

root@beaglebone:~# cat /sys/class/gpio/gpio4/direction
out

root@beaglebone:~# fgrep P9_18 /sys/devices/ocp.3/cape-universal.48/status
11 P9_18 4 IN 0

Thoughts on why this still says "IN" and I don't see output?

Hmm...probably because the cape-universal status under ocp represents
the device tree that got exported, where all pins are GPIO inputs with
appropriate pull up/down until you change them. Since the settings are
changed via the standard GPIO export sysfs files, this doesn't directly
affect the device tree and likely isn't getting pulled back into the
cape-universal sysfs entries.

The pinmux helper and gpio sysfs entries should contain the proper
values, and you should get correct results if you:

config-pin -q p9.18

> I was able to get PWM output, but I'm struggling with GPIOs for some
reason:
>
> root@beaglebone:~# dash -x `which config-pin` P9_18 out
> .
> .
> .
> + sudo -A su -c echo out > /sys/class/gpio/gpio4/direction
> + echo_dbg echo gpio > /sys/devices/ocp.3/P9_18_pinmux.36/state
> + [ -n ]
> + sudo -A su -c echo gpio > /sys/devices/ocp.3/P9_18_pinmux.36/state
> + exit 0
>
> root@beaglebone:~# cat /sys/devices/ocp.3/P9_18_pinmux.36/state
> gpio
>
> root@beaglebone:~# cat /sys/class/gpio/gpio4/direction
> out
>
> root@beaglebone:~# fgrep P9_18
/sys/devices/ocp.3/cape-universal.48/status
> 11 P9_18 4 IN 0
>
> Thoughts on why this still says "IN" and I don't see output?

Hmm...probably because the cape-universal status under ocp represents
the device tree that got exported, where all pins are GPIO inputs with
appropriate pull up/down until you change them. Since the settings are
changed via the standard GPIO export sysfs files, this doesn't directly
affect the device tree and likely isn't getting pulled back into the
cape-universal sysfs entries.

The pinmux helper and gpio sysfs entries should contain the proper
values, and you should get correct results if you:

config-pin -q p9.18

Fair enough:

beaglebone:~# config-pin -q p9.18
P9_18 Mode: gpio Direction: out Value: 1

Did some probing on the hardware and it looks fine. Guess I was having
another issue.

Jason, could you please let me know how you got cape-universal to let you do
pwm?

If I use the am33xx_pwm and bone_pwm_P9_21 dtbo's I can see
/sys/devices/ocp.3/pwm_test_
P9_21.11 period polarity and run files.

If I use the cape-universal instead and config-pin P9_21 as pwm
all I get is a confirmation that it occurred, but I have difficulty finding
the period, polarity, run files.

Well, be sure *NOT* to load the bone_pwm_* dtbo (dt overlays).
Instead, you should use the standard Linux sysfs entries for PWM.

root@beaglebone:~# config-pin p9.14 pwm
root@beaglebone:~# config-pin -q p9.14
P9_14 Mode: pwm
root@beaglebone:~# echo 3 > /sys/class/pwm/export
root@beaglebone:~# cat /sys/class/pwm/pwm3/run
0
root@beaglebone:~# cat /sys/class/pwm/pwm3/duty_ns
0
root@beaglebone:~# cat /sys/class/pwm/pwm3/period_ns
0
root@beaglebone:~# echo 500000 > /sys/class/pwm/pwm3/period_ns
root@beaglebone:~# echo 100000 > /sys/class/pwm/pwm3/duty_ns
root@beaglebone:~# echo 1 > /sys/class/pwm/pwm3/run
root@beaglebone:~# cat /sys/class/pwm/pwm3/run
1
root@beaglebone:~# cat /sys/class/pwm/pwm3/duty_ns
100000

To figure out the index for performing the export, you need to look at
the order the PWMs are placed in the devicetree. I input these into my
bone.js file that keeps the board specific info
(bonescript/src/bone.js at 427de9494d4f494bd7806ddde10913f1578cdbea · jadonk/bonescript · GitHub).

root@beaglebone:~# node -e "var
p=require('bonescript').bone.pins;for(var x in
p){if(p.pwm)console.log(x+':'+p.pwm.sysfs);}"
P8_13:6
P8_19:5
P8_34:4
P8_36:3
P8_45:5
P8_46:6
P9_14:3
P9_16:4
P9_21:1
P9_22:0
P9_28:7
P9_29:1
P9_31:0
P9_42:2

I’m setting up cape-universal on a production machine - minor item,
but I noticed the syntax in+ works whereas the equivalent in_pu does not.

There was a cut/paste problem with the regular expressions that generate
the desired pin mode. Thanks for the heads-up!

Fix pushed:
https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/4476b207dd3f8b713453d095dd64ff6ec495d929