any thoughts? on not working on RPi2?

[laboratories]

Hi ya

I'm gonna spend some time trying to get your code up and running on the RPi2
so far the binaries are not working for sure.

I will do the build and see what comes.

Anythoughts? Pointers? Tips?

thx in advance
G

[jgarff]

I haven't yet investigated how to get it running. It may be as simple as
fixing up some peripheral addresses. However if they updated the PWM or
DMA logic it may be much more complicated. As soon as I can get my hands
on one I'll take a look.
On Feb 19, 2015 3:45 AM, "laboratories" notifications@github.com wrote:

Hi ya

I'm gonna spend some time trying to get your code up and running on the
RPi2
so far the binaries are not working for sure.

I will do the build and see what comes.

Anythoughts? Pointers? Tips?

thx in advance
G

—
Reply to this email directly or view it on GitHub
#25.

[laboratories]

Thanks so much for getting back to me..
Your code is very clean and easy to understand (yay!)
(with my limited abilities = as I am an artist not a system coder)
(but thank you!)

I understand that the peripheral base address has changed
I will do what I can
e.g.
0x20000000 vs 0x3f000000
I will try this using your code
and rebuild

'they' [raspberrypi] have now a function to request for the new base address
raspberrypi/userland@3b81b91
so that may be usable in the near future when the firmware gets released
and have the benefit of being more universal

I haven't looked into the issues with DMA which have also changed but I'm not sure of as of yet what that means... (it looks to me as you have bypassed some of the issues already..but I'm not sure yet)

if it's ok with you - leave this issue open and I will collect what information that seems pertinent as I investigate.

thanks
G

[laboratories]

well I've gotten farther than I thought I would...
changing the references to 0x20000000 to 0x3f000000
for both the GPIO and the DMA
sort of worked..

the test program made the lights flash - but not in the right order at all
and the python examples did not work at all

but it worked better than NOT working....
I will continue reading your code....
I'm assuming that it is a matter of clock timing

[laboratories]

I also changed the memory address of 0x40000000 to 0xc0000000
re this discussion http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=98367&start=150

but I have a feeling that the DMA is just looking in the wrong place...

I also tried under and over clocking the board thinking that it might have to do with the clock speed being different..

but no luck - I'm giving up for today

any thoughts or clues would be great... as I'm only ranked above Script Kiddie..

G

[richardghirst]

I have this working on a Pi B 2, and a B. Fairly extensive changes required due to the cache changes on the new board. Calling the gcc builtin to flush the cache doesn't seem to work, so I've changed the code to request the DMA memory from the VideoCore, via the mailbox interface. This gives us uncached memory, and you get a contiguous chunk so no need to mess around with chains of DMA pages or descriptors any more. You can find it here:

https://github.com/richardghirst/rpi_ws281x

Richard

[laboratories]

wow!
so many thanks for the update..richardghirst
I will test tonight... and tell you of my outcome...

& yeah - it seems that much of the DMA handling is very different than the b+ >>> I can only image this will break a lot of programs (GPIO, Audio, etc)

[laboratories]

Hi Richard...
well your fork is not working for me
while it will blink a few random lights
it does not work as the original does.
Also it can only be run once... the second time the terminal says that the device can not be opened.. and the system must be rebooted to be able to run ./test again

and none of the python scripts are working either

I have upgraded and updated and am using the current firmware (as of today)

sorry to be the barer of bad news..

G

[richardghirst]

Thanks for the feedback. It is working for me and one other person, and
doesn't require a reboot to run a second time. The strandtest works too.
I'll try updating to the very latest too and see what happens.
On 22 Feb 2015 03:41, "laboratories" notifications@github.com wrote:

Hi Richard...
well your fork is not working for me
while it will blink a few random lights
it does not work as the original does.
Also it can only be run once... the second time the terminal says that the
device can not be opened.. and the system must be rebooted to be able to
run ./test again

and none of the python scripts are working either

I have upgraded and updated and am using the current firmware (as of today)

sorry to be the barer of bad news..

G

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

[richardghirst]

I did an apt-get upgrade (which found nothing to do) and ran rpi-update.
I'm now running:

$ cat /proc/version
Linux version 3.18.7-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303
(prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) )
#757 SMP PREEMPT Sat Feb 21 14:54:05 GMT 2015

It still works as expected. Note I changed the 'test' program to do
something different (I have a 3x3 matrix and needed a slower changing
pattern so I could see that was updating correctly), but you can run with
the original main.c instead if you want. Anyway, the strandtest.py still
works for me and I can restart.

The "device cannot be opened" message presumably means the new code could
not talk to the VideoCore to allocate memory. One reason for that is if
the device is already opened - at least, I get that if I try top run the
test program again without killing the first instance.

I should say that I don't have a display and keyboard on my Pi, and am
accessing it over WiFi and ssh from my desktop.

Here are my relevant config.txt settings and cmdline:

$ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1
root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
$ sed -e '/^$/d' -e '/^#/d' /boot/config.txt
disable_overscan=1
$

I don't have the camera enabled. I'm running a recent raspbian image
(2015-02-16-raspbian-wheezy.zip) plus the rpi-update.

If you can figure out what the significant difference is between your setup
and mine that would be helpful!

FWIW, I've used the same approach to get memory from the VideoCore for
ServoBlaster and a handful of people have that working, and nobody has
reported problems. It is the approach the guys running FFTs on the GPU use.

Richard

On Sun, Feb 22, 2015 at 9:26 AM, Richard Hirst richardghirst@gmail.com
wrote:

Thanks for the feedback. It is working for me and one other person, and
doesn't require a reboot to run a second time. The strandtest works too.
I'll try updating to the very latest too and see what happens.
On 22 Feb 2015 03:41, "laboratories" notifications@github.com wrote:

Hi Richard...
well your fork is not working for me
while it will blink a few random lights
it does not work as the original does.
Also it can only be run once... the second time the terminal says that
the device can not be opened.. and the system must be rebooted to be able
to run ./test again

and none of the python scripts are working either

I have upgraded and updated and am using the current firmware (as of
today)

sorry to be the barer of bad news..

G

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

[laboratories]

Thanks for you attention and effort

my install is from the same (2015-02-16-raspbian-wheezy.zip)

and

pi@raspberrypi ~ $ cat /proc/version
Linux version 3.18.7-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #757 SMP PREEMPT Sat Feb 21 14:54:05 GMT 2015

I'm also running headless via vnc and ssh

• could the vnc be interfering? because it's using the screen buffer?

and no camera either

the first run I get no response from the LEDs
the error after running the second time is "Can't open device file: /dev/ws2811_mb"

I'm gonna guess that I have something screwed up in my instal
and will make a fresh card... l will re port back in a few..

G

[Mimoja]

Working perfectly fine for me. A charm!
./test and python part.
Thanks for all the work!

[laboratories]

hummm interesting...

so for some reason the ./test now will work but only after I initialize the system with the Python code

the python examples work fine and can be started and stopped
no problem (yay! - blinky lights)

but the ./test will not exit properly
and a second attempt with fail with the C test and the python
"Can't open device file: /dev/ws2811_mb"

so I will look at the test program and see what's changed...

but I'm basically working!!!

many many thanks

G

(PS this was all for a good cause - I'm building a large blinky light screen so that music can be abstractly represented for the deaf for a performance in Chile!)

[richardghirst]

That's a really good cause - I'm happy I could help a little.

The version of code you have opens /dev/ws2811_mb and keeps it open until
the program exits. That stops anything else opening the mailbox, and
anything else that has the mailbox open will stop you opening it. As you
probably realise, the name of the /dev file isn't relevant. anything
creating a device file with the same major/minor and opening it would
prevent you from opening it. The fact that you are getting that "cannot
open" error implies the test program is still running. I was using Ctrl-C
to kill it, and it has always exited ok. However, as it didn't blink your
lights anyway I guess it is stuck in some loop perhaps waiting for the DMA
to complete when it is never going to.

I've just pushed some updates to github which make it only open the mailbox
briefly at startup and shutdown. That isn't going to solve your basic
problem with ./test not working, but it is better behaviour and I needed to
do it for someone who wants to run this software at the same time as
servoblaster.

On Sun, Feb 22, 2015 at 2:49 PM, laboratories notifications@github.com
wrote:

hummm interesting...

so for some reason the ./test now will work but only after I initialize
the system with the Python code

the python examples work fine and can be started and stopped
no problem (yay! - blinky lights)

but the ./test will not exit properly
and a second attempt with fail with the C test and the python
"Can't open device file: /dev/ws2811_mb"

so I will look at the test program and see what's changed...

but I'm basically working!!!

many many thanks

G

(PS this was all for a good cause - I'm building a large blinky light
screen so that music can be abstractly represented for the deaf for a
performance in Chile!)

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

[laboratories]

New version seems perfect
no problems restarting test does not hang on the second launch
lights blink good... yay!

thanks again for the effort

[hooyah]

This is working great. One thing though, i think some part of the pwm isnt initialized properly. The strandtest works fine after reboot. But once you play a sound through the audio jack every subsequent run of the strandtest is horribly random. It's quite interesting to listen to the pulses with headphones plugged in. Nice and regular before playing sound. Nasty and irregular after.
Anyhow, glad you spent the time to get it working at all.

[andreapalisca]

I'm trying to control a neopixel ring (GPIO 18) and also use the audio jack for playback. Is there a way for both to coexist? Or do both require the same PWM capability of the Broadcom chip? Currently I can hear the neopixel data line pulses via the audio output and the pixels don't display what they should.

Thanks for all the work on this library.

[jgarff]

Unfortunately, the audio device and the LED driver both use the PWM. In
this case what I've done to get around the problem is to blacklist the
broadcom audio driver, and use a cheap USB audio device instead.

On Mon, Mar 23, 2015 at 8:31 AM, paf78 notifications@github.com wrote:

I'm trying to control a neopixel ring (GPIO 18) and also use the audio
jack for playback. Is there a way for both to coexist? Or do both require
the same PWM capability of the Broadcom chip? Currently I can hear the
neopixel data line pulses via the audio output and the pixels don't display
what they should.

Thanks for all the work on this library.

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

[laboratories]

another good audio solution while using the GPIO pins is use the audio from the HDMI out. Digital audio (up to 8 channels) that most TV and monitors will decode (mostly only two channel).
there are break out boxes for two channel that are cheap (look for HDMI to VGA boxes- about 15$).
there are also very good breakout boxes that will decode the full 8 channels (about 125 USD).

if you use a "TV" instead of a "monitor" the RPi will often not play audio - you need to change the config.txt file to force the use of the HDMI=2 mode..

peace

[linuxlewis]

👍 @richardghirst Fork confirmed working pi2 on raspbian wheezy w/ python 3.4.2