-
Notifications
You must be signed in to change notification settings - Fork 622
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
Python hangs when trying to start communication channel on Raspberry Pi 2 #32
Comments
Check out the fork mentioned in the thread here for a version that some folks have luck with on a Pi 2: #25 The Pi 2 has some differences with the PWM & DMA behavior so the current library isn't compatible right now. It sounds like there are some non-trivial changes to port over support for the pi 2 to the original library here so for now your best bet is to check out that fork. |
Thanks for the direction. Looked into it and found another group that makes Unicornhats has fully integrated new PWM/DMA implementations compatible with the Rasp Pi2. https://github.com/pimoroni/unicorn-hat Looks like this person started the process: https://github.com/richardghirst/rpi_ws281x - I had volatility with the fork I took from there, but the unicorn-hat code worked like a charm with the Pi2. |
The changes in @richardghirst's branch appear to merge into this repo just fine, and worked for me (at the native library level anyway - didn't test the Python wrapper). |
Python wrapper almost works for me. Until I try to delete the object then I get a "munmap error -1". Anyone have any ideas of what I'm doing wrong....
|
Huh that's odd, on delete the python wrapper is calling the ws2811_fini function from the C code to clean up and shutdown all the PWM so I don't think it's anything specific to the python wrapper. To check though if you run the C example code and quit with control C so it calls ws2811_fini too, does that also have a munmap -1 error? |
I found this commit somewhere in the network-graph that presumably addresses an issue with munmap. I haven't looked at it in depth but maybe that helps here: euang@73997a5 |
I ran the example C code getting a vibrant display of lights then ctrl-C to quit. I did not get a munmap error but neither did the LEDs turn off.
Running the python strandtest.py example worked fine too and the ctrl-C also leaves the lights on but I do see the munmap error.
|
Thanks usefulthink!! I did a git clone of euang's repo and BINGO!!! It works! |
Thanks for the hint! Only problem is that the LEDs still stay lit. Is that normal? |
Nope....LEDs turn off for me. Every once in awhile I'll have an issue On Sat, Sep 5, 2015 at 7:42 AM, kuenzelIT [email protected] wrote:
|
The C level cleanup code doesn't turn off the leds. This allows the user to write a program to set the leds and terminate in case they need a static display. We should probably add a callback to allow the user to do something differently. As for supporting the Pi2, I just created a rpi2 branch which supports newer kernels and the Raspberry Pi 2. This is a testing branch, so please give it a shot and let me know if you run into problems. Thanks |
There seems to be something going wrong when swig runs the initialization for the ws281x channel. You can trace it back to there from strip.begin() in the example file -
samplethread.py
Any ideas on where to look for fixing this? Am working on a project that uses Pi to communicate with WS2812s, but will probably just old Pi instead of Pi 2 due to this error. However, I'd be happy to put some work into fixing it up for Pi 2 if I can get any guidance on where to start. As a beginner with swig, it's hard to say what the culprit may be in the C or whether it's the SWIG interface itself.
The text was updated successfully, but these errors were encountered: