-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for PWM in 4.1+ #108
Conversation
Replace 1 for success and 0/-1 for failure with an enum type.
Addresses #103 |
@MatthewWest: awesome! I'll try it out with set of Debian images that I test with and post my results here. |
@MatthewWest I installed Adafruit_BBIO from your repo: onto the Debian Jessie 8.5 image with Linux 4.4:
test/test_pwm_setup.py encounters several AssertionErrors:
Full test results with full error messages: The issue seems to be that this dir exists:
but the desired subdir does not:
|
For Debian 7.11 with Linux 3.8.13:
Errors from py.test:
Full listing of errors: |
I installed the
Errors from py.test: |
For Debian 8.3 image with 4.1 kernel:
py.test errors messages for pwm: |
@pdp7 Just submitted a pull request to fix the error with Debian 8.5, kernel 4.4. It was a simple case where the exact path can vary in the
I've found that's the best (only?) way to debug the code, seeing what files it attempts to open. If you can't / don't have time to do that, let me know - I might be able to make images for all the different versions and test them that way. |
Should we include any necessary device trees in this library and install them? The 4.1+ code requires that the user have one of the universal device trees loaded: // Make sure that one of the universal capes is loaded
if (!( device_tree_loaded("cape-univ-audio") // from cdsteinkuehler/beaglebone-universal-io
|| device_tree_loaded("cape-univ-emmc") // ""
|| device_tree_loaded("cape-univ-hdmi") // ""
|| device_tree_loaded("cape-universal") // ""
|| device_tree_loaded("cape-universala") // ""
|| device_tree_loaded("cape-universaln") // ""
|| device_tree_loaded("univ-all") // from latest BeagleBone Debian 8 images
|| device_tree_loaded("univ-bbgw") // ""
|| device_tree_loaded("univ-emmc") // ""
|| device_tree_loaded("univ-hdmi") // ""
|| device_tree_loaded("univ-nhdmi"))) // ""
{
return BBIO_CAPE;
} These images, from the beaglebone-universal-io project, are included on new BeagleBone images (from here), but on older images which have been upgraded to include the new kernel, they might be missing. This would also require us to switch tacks and use these overlays for the other functionality as well. From the beaglebone-universal-io project:
So the universal capes are not compatible with the approach used by the UART, SPI, and GPIO sections of this library. |
I've been doing a bit of looking into how other people are handling the differences between kernels 3.8 and 4.1, and it looks like we'll probably have to support both - if the universal cape is present, use it. If not (and possibly other capes are present which would conflict with which the universal cape conflicts), use a custom overlay strategy. That's at least the conclusion that the folks over at PyBBIO came to. |
@MatthewWest Thanks for updating the test. I've updated the results for Debian 8.3 image with Linux 4.1.15-ti-rt-r43: I included strace log for file operations on /sys/devices. Relevant listing of directories:
I should be able to swap in the different SD cards later and run the updated test on Debian 7.11 with Linux 3.8.13 and Debian 8.5 with Linux 4.4. |
Thanks @ladyada for merging. And thanks very much to @MatthewWest!! |
I use Linux kamikaze 4.1.6-bone15 #1 Tue Aug 18 12:45:47 UTC 2015 armv7l GNU/Linux File "testHardPwm.py", line 6, in When I run testing demo, the error I get above. |
@Dark-Guan My guess is that the beaglebone-universal-io capes are not present. Can you list results of the following commands:
Try those first. We may have to resort to |
@MatthewWest Thanks for your reponse. root@kamikaze: There is the result. |
@Dark-Guan Alright, I don't see an easy answer based on what you've provided so far. Can you please run the following commands, and paste the output ( # Install strace somehow (not sure what the package management situation is on kamikaze)
# on Debian it'd be
sudo apt-get install strace
sudo strace -o trace.txt python3 # Or python from Adafruit_BBIO import PWM
PWM.start("P9_14", 50 , 2000, 1)
# press Ctrl-D Then upload the contents of If you're not familiar with it, |
Ok,Thanks @MatthewWest I will test it soon! Trace is very a nice tool ! |
@MatthewWest https://github.com/Dark-Guan/No-Used-Things/blob/master/trace.txt |
I figured it out. Here's the critical part:
The invalid argument when setting the duty cycle happens when the duty cycle is set to longer than the period of the pwm. This was happening because we weren't reading the current duty_ns and period_ns from the files. I've written a short patch which reads the current duty_ns and pwm_ns from the files before setting the default values, in order to set the duty and period in the correct order. That said, I've written the changes but don't have access to a BeagleBone for the next 2 weeks. So I haven't tested my changes at all, even to see if it will compile. You're welcome to try the code in the develop branch of my repository. I won't submit a pull request until I've had a chance to test it. |
@MatthewWest OK, Nice work ! I will spend some time to test yours develop version. Thanks very much ! |
All tests I've run are OK for @MatthewWest's
|
@MatthewWest If you can create a pull request with the fix from your develop branch, then I will test again and merge if no issues. |
This patch does several things. Principally, it:
sysfs
interface in Linux 4.1+enum
error type specific to the library.build_path
implementation with a call toglob
, the system library.Numerous parts of the code were modified, as it was necessary in order to implement the different error handling convention.
One known limitation of the change is that the disable section does not unexport PWMs, it merely disables them. That means that the hardware is still powered (and probably clocked), it simply isn't putting out an output.
Tests are all passing on both Python 2 and Python 3 on Linux kernel 4.1.15-bone11. I haven't been able to test on 3.8 yet (working on it).