I'm running on a 3B+ , essentially using the pi as an sACN receiver and to control some dotstars.

I have 690 pixels daisy chained with dotstars of different lengths.

I'm kind of pinned between two issues - at 32mHz spi there's a bunch of really bad multicolored flicker happening, just noise. Does this suggest anything? Data line is like 1 meter long, I have like a 150 ohm resistor in series on each wire before going into the dotstar. Power jumps running long the length between different strips.

If I go as low as 4mHz, it looks great. But while receiving on 1 universe, with updates coming in at 100 hz, .show() lags a lot at 690 pixels. At like 350 pixel length it's fine. Is this expected performance, or am I doing something wrong?

I've tried increasing the spi buffer but I don't really know what that's for, didn't make a difference.

How can I get this level of performance? With this number of strips, are people bitbanging but then using multiple pins and then running each out to different strips?

Here's my code:
`#!/usr/bin/env python

"""
Receives dmx over ethernet (e1.31/sACN) and outputs dotstar LED strip control
via SPI.
"""

import time
from dotstar import Adafruit_DotStar
from ola.ClientWrapper import ClientWrapper
from functools import partial

Scale brightness by percent 0 to 100

BRIGHTNESS_SCALAR = 80
NUM_PIXELS = 690 # Number of LEDs in strip(s)

NUM_PIXELS = 144 # Number of LEDs in strip(s)

UNIVERSES_LIST = [15, 16, 17, 3, 2, 4] # order doesn't matter

SPI (pins 10=MOSI, 11=SCLK)

Full pi clock speed:

strip = Adafruit_DotStar(NUM_PIXELS)

More conservative 32MHz SPI:

strip = Adafruit_DotStar(NUM_PIXELS, 4000000, order="bgr")

If colors are wrong, try adjusting order of rgb letters above

strip.begin() # Initialize pins for output
strip.setBrightness(BRIGHTNESS_SCALAR) # Limit brightness
strip.show() # Refresh strip

OLA calls this per universe whenever a new piece of data is received over sACN

def NewData(universe, data):
u = universe
print(data)
strip.show() # Refresh strip

values = enumerate(data)
rgb = []
pixel_i = 0

pixel_offset = 0
# each universe controls up to a certain index (not necessarily using full universe):
max_u_pixel = 512

if u is 15:
    pixel_offset = 0
    max_u_pixel = 282
if u is 16:
    pixel_offset = 94
    max_u_pixel = 392
elif u is 17:
    pixel_offset = 226
    max_u_pixel = 393
elif u is 2:
    pixel_offset = 390
    max_u_pixel = 429
elif u is 4:
    pixel_offset = 643
    max_u_pixel = 512
elif u is 3:
    max_u_pixel = 429
# if universe is 3, also see below

for i, val in values:
    # Keeps us from setting values in other universe's territory
    if (i < max_u_pixel):
        rgb_index = i % 3
        # Every 3rd index, set the pixel color
        if i != 0 and rgb_index == 0:
            if u is 3:
                if i < 331:
                    pixel_offset = 533
                elif i >= 331:
                    pixel_offset = 357

            # Send values for previous 3 indexes to pixel
            strip.setPixelColor(pixel_i + pixel_offset, rgb[0], rgb[1], rgb[2])

            # Start over
            rgb = []
            rgb.append(val)
            pixel_i += 1
        else:
            rgb.append(val)

wrapper = ClientWrapper()
client = wrapper.Client()

for u in UNIVERSES_LIST:
client.RegisterUniverse(u, client.REGISTER, partial(NewData, u))
wrapper.Run()`

hi, I am new to the pi and Python and get this error when trying to run the strandtst.py.

I am using a piZero. Also I see there is an SPI and a bitbang mode, where do I switch the mode?

Also, am I correct to run the code by typing "python strandtest.py"

Thanks.

pi@raspberrypi:~/LED/Adafruit $ python strandtest.py
Can't open /dev/mem (try 'sudo')
Traceback (most recent call last):
File "strandtest.py", line 28, in
strip.begin() # Initialize pins for output
SystemError: error return without exception set

The hardware SPI mode code does wacky things when brightness is not 0 (usually leaves a green pixel, but it flickers during updates.) This is because you're transmitting the raw mode IOCTL structures as data rather than the header and footer payload. Here's the fix:

https://gist.github.com/EricBayer/d1be199ec684c425c0a8

Will this library/module work in Python 3.x? I got it working to an extent in 2.7, I was getting the error about SystemError: error return without exception set. I will run it as sudo and see if that executes the code correctly.

Why I ask if this works on Python 3.x is because I have written my gui in 3.x and would like to keep it in 3.x to kind of future proof my program.

Is there a way to install this library/module into Python 3.x or does it need to be rewritten?

Line 21 of strandtest.py says rpi spi pins 11,12 while dotstar.c has 10,11 (which I believe is the correct one)

I'm hitting a very weird hard limit of 256 LEDs per Pi. In both SPI and bitbang mode. I increased the BLOCK_SIZE and spidev.bufsize by several factors but no effect. This seems like a software defined limit but I'm not quite sure where it comes from. I'm using a PI2.
What I read in bug #10 this can't be a hardware limitation as the default values for BLOCK_SIZE and spidev.bufsize should allow already more than 256 LEDs.

Any insight why this might happen?

E: I noticed this happens because I'm using the c code directly. Maybe I should have started with that info..
One major thing that I changed was in
instead of DotStarObject *self = NULL;
I assigned this DotStarObject *self = malloc(sizeof(DotStarObject));
So I can omit these python specific C API functions if((self = (DotStarObject *)type->tp_alloc(type, 0))) {

I find it really hard to debug. This definitely looks like a type or allocation issue.

Getting the following error when I run strandtest.py:

Traceback (most recent call last): File "./strandtest.py", line 11, in <module> from dotstar import Adafruit_DotStar ImportError: /usr/local/lib/python2.7/dist-packages/dotstar.so: undefined symbol: bcm_host_get_peripheral_address

This is on a Raspberry Pi 3 with a fresh install of Raspbian Stretch Lite. My Dotstar strip lights up, so I think I have it wired correctly. I turned on SPI in raspi-config and have the strip hooked into MOSI and SCLK for data and clock. I also tried pins 20 and 21, modding strandtest.py appropriately, but I can't get past the import step.

bcm_host.h is in /opt/vc/include. I installed this module with sudo python setup.py install.

Packages I've installed:

• build-essential
• python-pip
• python-dev
• python-smbus
• git
• python-imaging
• libraspberrypi-dev
• raspberrypi-kernel-headers

Any ideas?

strip.setPixelColor(pixel, 0,0,255) -> Green (should be Blue)
strip.setPixelColor(pixel, 0,255,0) -> Red (should be Green)
strip.setPixelColor(pixel, 255,0,0) -> Blue (should be Red)

If the brightness is max, SPI is quite fast. All the writes slow the whole thing down. Bitbanging is always really fast. As SPI is a more system friendly way, I wanted this to work fast. To accomplish this, I allocated a secondary buffer and I fill it first and then transmit it with raw_write. This appears to work very fast. NOTE: This has the other SPI fix mixed in too.

https://gist.github.com/EricBayer/67dc79cdc65ce2247f73

On a new install from 2017-09-07-raspbian-stretch.img on a Pi 2b v1.1.
I've installed libsdl2 using apt-get, but other than that it's a pretty fresh install. Looks like including bcm_host.h was just added a few days ago.

pi@lightwall:~/Adafruit_DotStar_Pi $ sudo python setup.py install
running install
running build
running build_ext
building 'dotstar' extension
arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-9xgeTe/python2.7-2.7.13=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c dotstar.c -o build/temp.linux-armv7l-2.7/dotstar.o
dotstar.c:62:22: fatal error: bcm_host.h: No such file or directory
#include <bcm_host.h>

On line 349 or so, the LED index is checked against numLEDs, but it does not protect against negative numbers. The demo python script 'strandtest.py' that you supply explicitly calls this function with negative LED indices for variable 'i', which probably leads to some interesting (and out of bounds) pointer arithmetic on this line:

uint8_t *ptr = &self->pixels[i * 4 + 1];

Here's a patch.

349c349

< if(i < self->numLEDs) {

  if(i >=0 && i < self->numLEDs) {

• Platform/operating system (i.e. Raspberry Pi with Raspbian operating system,
  Windows 32-bit, Windows 64-bit, Mac OSX 64-bit, etc.): Raspberry Pi with Jessie operating system

• Python version (run python -version or python3 -version): **Python 2.7.9 (default, Mar 8 2015, 00:52:26) **

• Error message you are receiving, including any Python exception traces: **Memory leak in PyObject *getPixelColor(DotStarObject *self, PyObject *arg) * **

• List the steps to reproduce the problem below (if possible attach code or commands
  to run): LIST REPRO STEPS BELOW
  A routine that uses the getPixelColor function will cause an increase in memory usage in the python process, eventually causing the process to bail out. The snippet below can be altered by commenting the getPixelColor line in and out, and using top to see the process memory heap.

def addToPixelColor(pixel,color):
	# pixColor =strip.getPixelColor(pixel)
	orig_r=pixColor  >>16
	orig_g=pixColor  >> 8 & 0xff
	orig_b=pixColor & 0x000000ff
	add_r=color  >>16
	add_g=color  >> 8 & 0xff
	add_b=color & 0x000000ff
	strip.setPixelColor(pixel,min(orig_r+add_r,255),min(orig_g+add_g,255),min(orig_b+add_b,255))

Included is the entire .py script if you wanted to try it for yourself.
If you run it, try python pixelmatrix.py flurry
pixelmatrix.py.zip

When running the strand test, LEDs flicker red periodically. It's a bit complicated to explain which ones, so I'll need a few bullets:

• All LEDs flicker at once in a low brightness red color
• The flicker starts at the end, i.e. the end of the strip always flicker. The closer to the start of the strip, the less the LEDs flicker. So sometimes almost the entire strip flickers, sometimes only the last 50 or so.
• If "numpixel" LEDs are defined, then LEDs up to (numpixel-1) flicker. LEDs beyond don't (i.e. if the strip contains more pixels than defined as "numpixels", then these extra LEDs never light up). The "numpixel" LED works fine when the strand test reaches it, but it never flickers.
• LEDs flicker only while the strand test is running, so I think it's a software issue, not hardware.

The C file 'dotstar.c' uses 0xFFFFFFFF for the footer value, but using that value results in the numLEDs + 1 LED to be illuminated bright white. According to the blog linked below, the footer is used to clock out data since the clock is delayed at each LED. The data value is not important, and will be pushed 'off the end' of a strip of exactly numLEDs LEDs. When you have a longer strip, that data value will be used for the numLEDs +1 LED (the value starts with '111' which signals an LED frame).

Also, if there are > 64 LEDs, a single 32 bit footer is not sufficient to correctly push out the remaining data. Please change the footer to be 32 * ((numLEDs - 1) div 64 + 1) ZERO bits long.

The blog post: https://cpldcpu.wordpress.com/2014/11/30/understanding-the-apa102-superled/

This has been asked before, but the issue was closed without a resolution: has anyone used this library with Python 3 and/or can it easily be made compatible? That would be great.

With the default config, the hardware spi device can only send 4096 bytes at a time. This becomes a problem if you want to control >1000 LEDs (as each LED takes up 4 bytes). Software SPI is similarly limited by the BLOCK_SIZE define. The constructor should probably check against those limits.

Note that it is possible to increase the hardware spi device buffersize to eg 8192 (enabling up to ~2000 LEDs):
https://www.raspberrypi.org/forums/viewtopic.php?p=837140#p837140 (newer kernels/RPI2)
https://www.raspberrypi.org/forums/viewtopic.php?p=309582#p309582 (older kernels)

(Edit: Note that the following analysis is basically all wrong; just to let anybody reading this understand that the issue was a jump-start to an improved driver, but nobody should actually attempt to apply or use the code below, or learn anything about the workings of the Broadcom ARM chip GPIO therefrom. The driver has since been updated, and solves the problem.)

I have identified a problem with dotstar.c that prevents the bit-bang mode from ever working properly. The error is that gpioSet and gpioClr are pointers to 32-bit unsigned integers, but the pointers are set to the gpio memory map at gpio[7] and gpio[10], respectively. This produces a 1-byte overlap between the set and clear spaces. In practice, this is (was) showing up for me as "glitches" in the light strip. On occasion, some portion of the light strip would spontaneously light up the red pixels dimly, regardless of what was written. The random nature of the error suggested either a noise or timing issue. I tried adjusting the bit-bang clock pulse timing but could not make it go away. I tried filtering the data signal lines but that didn't cause the behavior to change at all. I finally concluded that the error was in the driver code. After finding the set and clear bit overlap, I decided that what was happening was that the set and clear bits were overwriting each other and/or another byte of the gpio where they were not supposed to.

To fix the problem, I replaced instances of
*gpioSet = mask;
and
*gpioClr = mask;
with
*gpioSet &= 0xff000000;
*gpioSet |= mask;
and
*gpioClr &= 0xff000000;
*gpioClr |= mask;

I did this in clockPulse(), rawWrite(), and show(). The glitching has not occurred since.

By the way, the ultimate problem at the hardware level is caused by the data and clock rising edges happening at the same time. The data are best changed on the falling edge of the clock to achieve the highest possible data rate in bit bang mode. When this is done, there is no need to "throttle" the bit bang clock rate; it can keep up with whatever rate the clock can produce. This reduces the routine clockPulse() to the following:

static void clockPulse(uint32_t mask) {

    *gpioSet &= 0xff000000;
    *gpioSet |= mask;

    *gpioClr &= 0xff000000;
    *gpioClr |= mask;

}

With these corrections, the bit-bang mode can go full-bore. Some code optimizations could make it go even faster, but it's sort of pointless as it is already updating faster than the eye can follow.

I have noticed that all examples of Adafruit_DotStar_Pi use the SPI gpio lines, which is probably because everybody sees the bit-bang mode glitching and avoids it. That's unfortunate, because bit-bang mode can be very fast on the Pi-3 and allows for many light strips to be run simultaneously in parallel (I am working on a project with eight strips in parallel). The set and clear masks can accommodate as many parallel LED strips as there are available GPIO signals to drive, although that requires further extensions to the dotstar.c driver (which is a topic for another post).

---Tim

Does anybody know if there is some kind of documentation ?
The only thing I can find, is the documentation for the Circitpython Module