OK, I want to generate a PWM signal to send to a motor controller. This is simply to communicate the desired speed, the motor controller will do all the heavy lifting.
Unfortunately, the Adafruit_BBIO libraries appear broken and bonescript doesn’t seem any better.
After digging through Google results I found myself in /sys/class/pwm/ using echo to write values into various files and through pure dumb luck was able to get a 2 Khz square wave up on a scope and change its duty cycle. So at least my set up seems to be working at some level.
However, I feel I am missing a bunch of information. Which pwmchip exports to which pwm-X:X and corresponds to which pin? “duty_cycle” is not really duty cycle, it is nanoseconds high. I can’t change the period, even to sensible values like 250000 or 1000000. Some of the information on Stack Exchange is worrying, will pwm-4:0 always correspond to P9_14 or can this change on boot?
Is there a way to restore the functionality of the Adafruit BBIO libraries, short of waiting for an update? I did pip3 install -U. Requirement already satisfied: Adafruit_BBIO in /usr/local/lib/python3.7/dist-packages (1.2.0)
If that’s not possible, is there any documentation on how the /sys/class/pwm is intended to function?
OK, I rechecked and only Pin 8_13 is not working; the other three PWM pins are good using Adafruit.PWM. Pin 8_13 does respond to GPIO.HIGH and GPIO.LOW, so I don’t think I’ve damaged the hardware. Who knows what I have managed to do to the /sys/class files. If it doesn’t clear up on restart, I will reinstall the image. Of course 8_13 is the one I was planning to use, but I can just as well wire something to 8_19 for now.
Thanks for that, I’ll look at it again today. I may have mucked something up while digging into the /sys/class/pwm file structure or forgotten to do GPIO.cleanup() or some other combination of things.
OK, 3 of 4 PWM pins are working, but still no luck with P8_13.
I can see that Adafruit_BBIO is writing values into /sys/class/pwm/pwm-7:1/duty_cycle but no output is being generated.
debian@beaglebone:/sys/class/pwm/pwm-7:1$ cat duty_cycle
200000
debian@beaglebone:/sys/class/pwm/pwm-7:1$ cat period
500000
Pin 8_13 can still be used for GPIO. I have not dug further into the device files. Does this seem like a hardware or software issue? Should I reinstall the base image, accept that the board is flaky, or is there some other possible solution?
Also, the PWM frequency is fixed at 2000 Hz (period = 500000 ns). Is this intended? I can work with 2000, so this is more out of curiosity.
Python returns the following errors:
PWM.start(pin3,50,1000)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Problem with a sysfs file
PWM.set_frequency(pin3,1000)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Could not write to the frequency file
Attempting to write into the period file directly returns the following:
debian@beaglebone:/sys/class/pwm/pwm-7:1$ sudo echo 400000 > period
[sudo] password for debian:
echo: write error: Invalid argument
The arguments 2000 (from Python) and 500000 (echo) are accepted without no error. Any other values are not accepted.
I’ve investigated a bit more. First, and I should have done this sooner, I removed all the capes I’m using and tested the bare Beaglebone black. Success, all four PWMs work.
Then I began adding capes one at a time. I found that when a Prototype Cape is used, PWM is no longer available on P8_13. To be absolutely certain, I connected a brand new out of the box GHI Prototype Cape. No PWM on P8_13. Remove the cape and PWM works.
If I connect a Power Cape, PWM works, this would seem to rule out a bad solder joint or something physical on the BBB.
There is nothing near P8_13 on any of these capes, yet something is affecting that pin.
Is there something in the device tree that allows the cape to grab one of the PWM devices, perhaps for the variable LED that’s on the cape?
After uncommenting the line disable_uboot_overlay_addr3=1 in /boot/uEnv.txt, PWM is working on pin 8_13, even with the Prototype Cape attached.
So I believe something in the overlay stored in EEPROM on this particular cape is interfering with PWM. Here is a link to the cape I purchased in case you want to investigate further: https://www.mouser.com/ProductDetail/958-PROCPE-BBBCAPE/
Disabling loading of cape’s overlay is a workable solution for me, I am using it only to hold some passive circuits and optocouplers, so I am happy with this approach.