Unicorn Hat on Arch Linux | yet another thread

Support
1

Hello,

For the lazy ones | tl;dr:
UNICORN HAT NOT WORKING ON ARCH LINUX ARM SCROLL DOWN TO SEE IMPORT ERROR MESSAGE!

I wanted to use my Unicorn Hat (UH) shield with Arch Linux ARM (ALARM) on my Raspberry Pi 2 (RP2).
I’ve cloned the GIT repo yesterday morning (15.3.) and installed everything in the …/python folder via PIP into a virtualenv. the unicornd daemon was installed via sudo make install arch-linux (although I’m really not happy using make install for anything as it tends to just make everything a mess) and then enabled at boot via systemctl. ALARM is also up to date. Bleeding edge, the way Linux is supposed to be!

If I now start any of the provided example scripts e. g. sudo ./demo.py nothing happens and it’s not ctrl-C stopable. I read that some people hat similar problems running the UH “package” on ALARM but fixed it by downgrading gcc or editing some Makefile’s - however, according to the pull request history of GitHub all the suggested/successful solutions to these problems were already merged. Except for one issue (#35) stating that rpi-ws281x is broken in the newest ALARM, which was untouched since January. Someone commented that the daemon occassionally throws DMA errors but I haven’t noticed any (or I’m looking at the wrong place, also possible).

When I open a python console (remember, virtual env!) and try ‘’‘import unicornhat as uh’’’ I get this:

import unicornhat as uh

Failed to open /dev/vcio, trying old method.

Failed to create mailbox device /dev/mailbox-598: Permission denied

Failed to open /dev/vcio, trying old method.

Failed to create mailbox device /dev/mailbox-598: Permission denied

Failed to open /dev/vcio, trying old method.

Failed to create mailbox device /dev/mailbox-598: Permission denied

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File 
"/home/norphi/Projects/unicorn-hat/python/UnicornHat/unicornhat.py", 
line 14, in <module>

    ws2812.begin()

  File 
"/home/norphi/Projects/bioreactor_building/.env/lib/python3.5/site-packages/neopixel.py", 
line 107, in begin

    raise RuntimeError('ws2811_init failed with code {0}'.format(resp))

RuntimeError: ws2811_init failed with code -1

Permission denied could be a hint but I don’t even get why /dev/mail… So this isn’t really helping me. Anyone an Idea? Is it really the same issue as #35? Something else?

As you can see from my path …/bioreactor_building/… I’m up to no good again. Help a mad scientist, win an ego boost!

Also someone explain me how to highlight inline code in markdown, please, as everything I tried wasn’t working.

The funny part: Actually I just need Python 3.5.1 on my RP2 but installing anything that isn’t obsolete by months on a Debian based system seems to be just not possible at all. I ended up rendering my Rasbian unbootable. Still no idea how that did happen…

Greetings,
NorPhi

2

I think the rpi_ws281x library itself has had some improvements which are not yet merged into Unicorn HAT. This library may work on Arch, and is worth a try. You can grab it from GitHub and manually build/install the Python wrapped version: https://github.com/jgarff/rpi_ws281x

If it does, that may be good news since it might be about time for me to merge those changes back into UnicornHAT. It seems to contain Pi Zero and Pi 3 fixes- although I don’t believe either are strictly necessary.

Unfortunately I don’t have the time to support Arch on top of Raspbian and have very little experience with Arch’s idiosyncrasies anyway, so I have to rely on the community to find/fix any problems.

Edit: rpi_ws281x works on Raspbian with a little coaxing and the help of a Makefile instead of the unnecessary Scons abomination. The pixel order is wrong, however, appears to be GRB instead of RGB which must have been something I fixed.

Contents of Makefile:

all: lib test

lib:
        gcc -o ws2811.o -c -g -O2 -Wall -Werror ws2811.c -fPIC
        gcc -o rpihw.o -c -g -O2 -Wall -Werror rpihw.c -fPIC
        gcc -o pwm.o -c -g -O2 -Wall -Werror pwm.c -fPIC
        gcc -o dma.o -c -g -O2 -Wall -Werror dma.c -fPIC
        gcc -o mailbox.o -c -g -O2 -Wall -Werror mailbox.c -fPIC
        ar rc libws2811.a ws2811.o pwm.o dma.o rpihw.o mailbox.o
        ranlib libws2811.a

test:
        gcc -o main.o -c -g -O2 -Wall -Werror main.c
        gcc -o test main.o libws2811.a

clean:
        -rm ws2811.o pwm.o dma.o board_info.o mailbox.o
        -rm libws2811.a
        -rm test

You will also need SWIG installed since the Python setup.py will try to run swig on rpi_ws281x.i automatically.

make
cd python
python setup.py build
sudo python setup.py install
3

I have updated the Git repo to use the latest version of rpi_ws281x. I recommend trashing your VirtualEnv, grabbing the latest files from Git and attempting the install process again. I haven’t tested it on Arch, but will be interested to know if it somehow fixes the problem.

If it doesn’t, I recommend raising an issue against the original rpi_ws281x library, since those guys are the best lot to fix it: https://github.com/jgarff/rpi_ws281x

4

Not quite yet. It still freezes but import unicornhat as uh now does not yield an error message anymore. It just freezes and ignores ctrl+C, crtl+D, I’ve to kill the process.

I’ve installed /rpi-ws281x, /Unicornhat and /ws2812 via “pip install .” in a new virtualenv. The daemon is running. I’ve to check the logfiles again if it has thrown any errors. Pip list now lists rpi-ws281x (2.0.0), unicornhat (2.0.3) and ws2812 (1.1.0). Did I miss anything? Is maybe the virtualenv a bad idea (I’d really like to habe that in an virtualenv)?

While rebooting I just notices that “A stop job is running for Unicorn HAT daemon” creating a 90s delay. There was some upstream bug that created these “A stob job…” things but I think it’s curious that it was the unicorn hat daemon this time… I’ll investigate that further!

Btw.: There is a space missing infront of the block comment that absol. brightness is set to 50% in unicornhat.py. Which btw. makes me curious: Is there a way to satisfy the unicorn hats hunger for power so the LED can be run with 100 % brightness?

About Arch: The main mantra pretty much boils down to “without unneccessary additions or modifications”. You have to configure almost everything yourself. A bit of a hassle in the beginning but at some point you just know how Linux works and roll with it. Takes about a rainy weekend to set up Arch Linux. Arch ARM is a little bit easier as you just copy it onto an SD card and it’s basically good to go. I believe Rasbian does not use systemd, so writing a daemon for that should be the main difference and that’s already done (althought I’m not sure if it’s working or if just the rpi-ws281x wrapper is faulty).

5

You should uninstall ws2812 and probably stop the daemon also, since neither of these are needed for UnicornHAT to work and the daemon might well be interfering by writing out blank frames to the hardware even if you’re not talking to it.

Unicorn HAT can be driven brighter in some instances, but the brightness cap is there to protect it from the worst possible scenario which is all pixels driven full-white at 100% brightness. In this case it draws not only more power than you could reasonably ever supply to a Pi without modification, but also too much for the soft-start circuitry on UnicornHAT to handle ( which is there to protect the Pi ).

Thanks for the heads up regarding the indent blunder, I’ve fixed it and pushed 2.0.6. D’oh!

6

Makes me wonder, if it’s not needed why do you keep it in the git?

Btw. I’ve just tested the really basic curl installation. It’s not working on Rasbian anymore. Maybe roll back a release.

7

Looks like the brightness set in the examples is now below the threshold for anything useful to show up. I’ve added a warning for this in a new update and edited the examples accordingly.

unicornd is in git because it’s useful for driving the LEDs from userspace, or talking to them from myriad other languages that don’t have a native library.

I think the old ws2812 lib needs dropping though!

8

I just notice that Rasbian thing while trying to discuss the Arch problem at Duesseldofs local CCC hackerspace, but… welll it’s also St. Patrick day and irish people are our friends… I’ll look into that if I’m sober again. I’ll try to keep that thing in mind!

9

Hi @NorPhi , if you want working version for Arch linux, you have to uninstall all unicornhat and rpi-ws281x packages.

sudo pip uninstall unicornhat
sudo pip uninstall rpi-ws281x

run this two commands till pip freeze will not list any of them.
Then clone this repository: git clone https://github.com/bendo/unicorn-hat.git

Go to directory: unicorn-hat/python/rpi-ws281x/
and run:

sudo ./setup.py build
sudo ./setup.py install

Then go to directory: unicorn-hat/python/UnicornHat/
and run same commands:

sudo ./setup.py build
sudo ./setup.py install

After this should everything works. You will haven’t newest version, but all functionality for unicorn HAT should be there. I checked commits and newest version has support for Unicorn PHAT plus brightness was lowered. Other then that it should be more less same.

Happy hacking ;)

10

Hello,

This works for me!

RPi2, running up-to-date ArchARM, with Unicorn Hat.

Thanks for your efforts