I am using BeagleBone, not BeagleBone Black.
I just tried to output a PWM, and I expected potential frequencies of some megahertz on such a fast device. I found out that 100 Hz is the exact maximum I can set through sysfs.
I started digging online for examples and they did not mention a limit, but they also did not show a value faster than 100 Hz.
Example:
root@beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 10000000 > period_ns
root@beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 1000000 > period_ns
-sh: echo: write error: Invalid argument
root@beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 200 > period_freq
-sh: echo: write error: Invalid argument
root@beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 101 > period_freq
-sh: echo: write error: Invalid argument
root@beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 100 > period_freq
root@beaglebone:/sys/class/pwm/ehrpwm.0:0#
Any decent AVR microcontroller can do a faster PWM than that. Is there some trick I missed?
Do I really have to create a custom PWM by manually toggling GPIOs if I want a faster frequency than 100 Hz?!
The PWM frequency is of course not limited like that on a 1 GHz device; the kernel driver is just not working in the same way one would expect.
If you enter a duty_percent value (like 1 percent) then the driver seems to just calculate the duty_ns value out of it and forget about percent afterward.
A normal user would think he is in "percent mode", but actually the percentage file is just bound to a wrapper to help. The same counts for the frequency!
If you now change the frequency to a higher value than, then the kernel checks if the duty_ns cycle period fits into the new total period_ns! It ignores that you actually set a percentage!
So of course you can not have an on-period which is larger than the whole period, so it fails.
Long text short summary:
Always set duty_cycle to zero before you set the frequency if the previous value will not fit into the new period, this avoids frustration.