Python hangs when trying to start communication channel on Raspberry Pi 2

[wannabeCitizen]

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]

Check out the fork mentioned in the thread here for a version that some folks have luck with on a Pi 2: https://github.com/jgarff/rpi_ws281x/issues/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]

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]

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]

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]

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]

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: https://github.com/euang/rpi_ws281x/commit/73997a5e33f0afdb8cc1f07f09a10a60e8866a9b

[huckw]

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]

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

[KuenzelIT]

Thanks for the hint!

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

[huckw]

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 notifications@github.com 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 https://github.com/jgarff/rpi_ws281x/issues/32#issuecomment-137957321.

[jgarff]

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