has some body experiance with the fastspi_led and the LPD6803 chipset on a teensy3.1

has some body experiance with the fastspi_led and the LPD6803 chipset on a teensy3.1 .( need the teeensy as i’m out off memory on a arduino uno )
This chipset( LPD6803) is also used in the APA101 (5 BIT GRAYSCALE LED ) flexibel led panel .
I can’t used the new FastLed as it does not support the LDP6803 chipset any more and the APA102 and APA101 is not the same protocol.

For the rest if some body can help me ,give me shout .
APA 101 is a very nice replacement for the WS2801 have a look at http://www.neon-world.com ( soon there will be a APA 105 , 3528 smd led with integrated driver … and a lot more from them .

Find me a datasheet for the APA101. The LPD6803 is explicitly not supported anymore because it requires running the clock line in the background on a timer to drive the chip’s PWM. If the APA101 doesn’t need that, then I can implement support for it.

(But really, I’d far rather have the APA102 - full 24-bit color - instead, and a rumor of 8x the data rate of the WS2801 - which I will confirm in a few days).

Also, that neon-world site is pretty useless for finding real details - this datasheet on there - http://www.neon-world.com/pdf/apa-rgb%20color%20led%20contorer(se).pdf - indicates that the APA101 is 24-bit (+5 bit brightness control on top of that) - but also no mention of an actual clock rate.

I suspect to actually put in support for the APA101, I’d need some samples - and at the moment, I’m not finding anyplace that is selling them, searching for APA101 on aliexpress gave me nothing.

Hey Daniel

I will send you all I have from the apa101. I have it running on arduino uno , will send you also the sketch I’m using
The apa 101 has the same clock specs as the apa102 only a 5 bit gray scale value

About info , I have a very good relation with neon- world , and they make the apa102 cheaper then the chinees ( only you need to take the non-English Korean translation as very disturbing confusion factor).

I send all info later today… Regards

(Note - when you say “5 bit gray scale value” - most chip vendors up until now have meant that to mean how many bits per color - e.g. 8 bit gray scale value would mean 24 bit color. Do you mean to say that it is only 5-bit for each of red, green, and blue? Or are you referring to the separate 5-bit brightness scaling value? - because right now you’re saying one thing and the datasheet I saw is saying something else)

assuming the data sheet that i linked to above is actually correct - the only piece of information that I need that the datasheet doesn’t have is what the value for the “verify” field should be.

// apa soccer game layout on shirt , HCr as boss off myself

#include <Bounce.h>

float movement = 0; // original = 0
float brightness = 32; // original 64
float size = 20; // original 10
float worldWidth = 60; //original 40
float worldHeight = 60; // original 40
int ledFactor = 3; // original 3
int minShade = -1;
int maxShade = 1;

#define DATA_PIN (3)
#define CLOCK_PIN (4)
#define LIGHT_COUNT (280)
#define pinModeFast(x, y) pinMode(x, y)
#define digitalWriteFast(x, y) digitalWrite(x, y)
uint32_t pixels[LIGHT_COUNT];

const int buttonPin_L = 14; // the pin that the pushbutton is attached to
const int buttonPin_R = 15;

int buttonPushCounter_L = 0; // counter for the number of button presses
int buttonState_L = 0; // current state of the button
int lastButtonState_L = 0; // previous state of the button
int buttonPushCounter_R = 0; // counter for the number of button presses
int buttonState_R = 0; // current state of the button
int lastButtonState_R = 0;

void setup() {
pinModeFast(DATA_PIN, OUTPUT);
pinModeFast(CLOCK_PIN, OUTPUT);
digitalWriteFast(DATA_PIN, LOW);
digitalWriteFast(CLOCK_PIN, LOW);
movement = random(0,10); //randomize start pattern start 0.2
// initialize the button pin as a input:
pinMode(buttonPin_L, INPUT);
pinMode(buttonPin_R, INPUT);

Serial.begin(9600);

}

static void set_pixel(uint32_t index, uint32_t color) {
pixels[index] = color & 0x1fffffff;
}

static void set_pixel_rgb(uint32_t index, uint32_t r, uint32_t g, uint32_t b) {
set_pixel(index, r | (g << 8) | (b << 16));
}

static void toggle_clock() {
digitalWriteFast(CLOCK_PIN, HIGH);
digitalWriteFast(CLOCK_PIN, LOW);
}

static void write_pixel(uint32_t i) {
const uint32_t MASK = ((uint32_t)(1) << 31);
uint32_t p = pixels[i] | MASK;
int j = 32;
while (j–) {
digitalWriteFast(DATA_PIN, (p & MASK) ? HIGH : LOW);
toggle_clock();
p <<= 1;
}
}

static void write_blank_pixel() {
int j = 31;
while (j–) {
digitalWriteFast(DATA_PIN, 0);

The code that you have there is nothing like the LPD6803, the LPD6803 is a 5-bit per color pixel chipset with a 16-bit data block per RGB pixel, the APA-102 is an 8 bit per color chipset with a 32-bit data block - if you were getting things working using the old FastSPI_LED code set to LPD6803 - that was blind luck.

I think I have enough information from here to be able to implement APA101 support, however, and could probably even check in something in a couple of hours (I’m not at the laptop that I do the led work on, and won’t be for a couple of hours, yet).

What kinds of prices can you get for the APA-101/APA-102 from your distributor? Because I just ordered a bunch of APA-102 at prices pretty close to what I was paying for WS2812Bs, without having to navigate an extra language barrier :slight_smile:

Maybe luck , maybe not

As the data structure I got from apa 101 was exactly the same as the LPD6803
datasheet I had .

I don’t think the info I got from apa on the 101 is not correct

I have a led controller from them and on my scoop I could almost determined
that it is a 5 bit colour pixel in a 16 bit data block …

I send the info on all product on your gmail account if ok .

Hc

Yeah - there’s a disconnect between the documents you sent me and the code you sent me - I really hate suppliers who can’t get their own datasheets correct/accurate, they’re the bane of my existence as someone who is implementing the various data protocols.

I’m going to need to track down some APA101 chips to figure out which is correct, their datasheets, the code they sent you, or something else entirely. (There’s a pretty significant difference between sending 32 bits of data per rgb pixel and 16 bits of data per rgb pixel :slight_smile:

Sadly, from a first look at the apa105 datasheet, I’m not 100% sure that I’m going to be able to provide support for it, as I’m mostly trying to avoid supporting things that require something more complex than attaching a wire to a pin on the MCU (+/- a 3.3-5v level shifter), and the apa105 protocol is based on 3 voltage levels, instead of two, which means the digital pin hi/lo values that are used for everything else aren’t exactly usable. I’m kind of surprised that they weren’t honking about that when putting that chipset together, and I’m not holding my breath on the apa105’s really making much of a splash - at least not in the circles of people that are likely to use this library and the platforms that it runs on.

hey Daniel

i tried to understand the apa101 with apa … but even them are so confused . It 's almost that they do’t make it , but only have the pattent . Even Greeled can’t help me on the prototcol off the apa 101
About the apa105 i agree it will be very tricky to use this on a arduino and co … It will be mainly used in cristimiss decoration . On the other hands they working on a 10 bits graylevel led … lets see already thanks for the support