I loaded this on Debian 3.8.13 and I can use it for gpio, but when I change P8_13 to use pwm
there are no duty or period or polarity files anywhere. Even after a reboot.
Could somebody please give me a hint.
I haven't played with the hardware PWM much yet. The base timer modules
are enabled by the universal cape, but specific PWM outputs are not. If
there's not a way to turn these on at runtime (similar to exporting a
GPIO pin) they'll need to be added to the device tree.
Also, when creating the universal overlay, I didn't want to do anything
that could not be "undone" since it is currently impossible to unload an
overlay. So you'll likely have to craft a small PWM overlay with the
frequencies you want or add the entries to the universal overlay.
If anyone knows whether or not there are any "unchangeable" values for
the PWM system that have to be altered in the device-tree overlay,
please speak up. If there aren't, the individual PWM signals should all
be added to the universal overlay.
No need to modify cape-universal. Since I’m on the clock what I’ll do is remove the pwm pins I need from
cape-universal .dts and recompile; then load the perfectly good, existing /lib/firmware entries for pwm.
I assume the published cape-universal .dts is in fact valid:
https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universal-00A0.dts
No need to modify cape-universal. Since I'm on the clock what I'll do is
remove the pwm pins I need from
cape-universal .dts and recompile; then load the perfectly good, existing
/lib/firmware entries for pwm.
That will work, of course, but the whole reason I went through this
exercise was to make it unnecessary for folks to fiddle with editing
overlay files.
I assume the published cape-universal .dts is in fact valid:
beaglebone-universal-io/cape-universal-00A0.dts at master · cdsteinkuehler/beaglebone-universal-io · GitHub
Yes, and if you're running one of RCN's recent Debian builds, this is
already checked out for you in /opt/source/beaglebone-universal-io/. A
"git pull origin master" will make sure you have the latest version.
Nevertheless, Charles - what you did brings a lot of rationality to the GPIO environment.
And saves a whole lot of hassles in deciding what to assume about the rest of the pins.
OK, I got a chance to review this, and as I thought you just need to
export the PWM channels so you can play with them via sysfs. Some
details are available on the TI wiki:
http://processors.wiki.ti.com/index.php/Linux_Core_PWM_User's_Guide
Executive summary...as root:
for PWM in 0 1 2 3 4 5 6 7 ; do
echo $PWM > /sys/class/pwm/export
done
...and you'll have your period and duty files:
find /sys/devices/ocp.*/ -name '*_ns'
/sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/duty_ns
/sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/period_ns
/sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/duty_ns
/sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/period_ns
/sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/duty_ns
/sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/period_ns
/sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/duty_ns
/sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/period_ns
/sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/duty_ns
/sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/period_ns
/sys/devices/ocp.3/48300000.epwmss/48300200.ehrpwm/pwm/pwm0/duty_ns
/sys/devices/ocp.3/48300000.epwmss/48300200.ehrpwm/pwm/pwm0/period_ns
/sys/devices/ocp.3/48300000.epwmss/48300200.ehrpwm/pwm/pwm1/duty_ns
/sys/devices/ocp.3/48300000.epwmss/48300200.ehrpwm/pwm/pwm1/period_ns
/sys/devices/ocp.3/48300000.epwmss/48300100.ecap/pwm/pwm2/duty_ns
/sys/devices/ocp.3/48300000.epwmss/48300100.ecap/pwm/pwm2/period_ns
Thank you - unfortunately the boot order of the pwm indexes as applied
to pins is random (i.e. pin P8_13 is 6 one day and something else another.)
I believe Jason indicated the numbering was based on the order they are
listed in the device tree, so it should be consistent if you're not
changing overlays.
Aaaah - that’s the pinmux order; had it wrong. Thanks.