Skip to content
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

Closed
wannabeCitizen opened this issue Apr 10, 2015 · 11 comments

Comments

@wannabeCitizen
Copy link

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.

@tdicola
Copy link
Contributor

tdicola commented Apr 12, 2015

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.

@wannabeCitizen
Copy link
Author

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.

@piers7
Copy link

piers7 commented Jun 10, 2015

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).

@huckw
Copy link

huckw commented Jul 14, 2015

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....

strip=Adafruit_NeoPixel(LED_COUNT, LED_PIN, LED_FREQ_HZ, LED_DMA, LED_INVERT)
strip.begin()
del strip # this causes the munmap error, so will setting strip=None

@tdicola
Copy link
Contributor

tdicola commented Jul 14, 2015

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?

@usefulthink
Copy link

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

@huckw
Copy link

huckw commented Jul 14, 2015

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.

pi@magpi ~/rpi_ws281x $ sudo ./test
^Cpi@magpi ~/rpi_ws281x $

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.

pi@magpi ~/rpi_ws281x/python/examples $ sudo python strandtest.py
Press Ctrl-C to quit.
^CTraceback (most recent call last):
  File "strandtest.py", line 94, in <module>
    theaterChase(strip, Color(  0,   0, 127))  # Blue theater chase
  File "strandtest.py", line 35, in theaterChase
    time.sleep(wait_ms/1000.0)
KeyboardInterrupt
munmap error -1

@huckw
Copy link

huckw commented Jul 14, 2015

Thanks usefulthink!! I did a git clone of euang's repo and BINGO!!! It works!

@KuenzelIT
Copy link

Thanks for the hint!

Only problem is that the LEDs still stay lit. Is that normal?

@huckw
Copy link

huckw commented Sep 9, 2015

Nope....LEDs turn off for me. Every once in awhile I'll have an issue
where LEDs won't turn off but power cycling usually take care of it.

On Sat, Sep 5, 2015 at 7:42 AM, kuenzelIT [email protected] wrote:

Thanks for the hint!

Only problem is that the LEDs still stay lit. Is that normal?


Reply to this email directly or view it on GitHub
#32 (comment).

@jgarff
Copy link
Owner

jgarff commented Oct 5, 2015

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

@jgarff jgarff closed this as completed Oct 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants