-
Notifications
You must be signed in to change notification settings - Fork 1
/
LPD8806DBL.cpp
345 lines (301 loc) · 10.8 KB
/
LPD8806DBL.cpp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
/*
Arduino library to control LPD8806-based RGB LED Strips
Copyright (C) Adafruit Industries
MIT license
Clearing up some misconceptions about how the LPD8806 drivers work:
The LPD8806 is not a FIFO shift register. The first data out controls the
LED *closest* to the processor (unlike a typical shift register, where the
first data out winds up at the *furthest* LED). Each LED driver 'fills up'
with data and then passes through all subsequent bytes until a latch
condition takes place. This is actually pretty common among LED drivers.
All color data bytes have the high bit (128) set, with the remaining
seven bits containing a brightness value (0-127). A byte with the high
bit clear has special meaning (explained later).
The rest gets bizarre...
The LPD8806 does not perform an in-unison latch (which would display the
newly-transmitted data all at once). Rather, each individual byte (even
the separate G, R, B components of each LED) is latched AS IT ARRIVES...
or more accurately, as the first bit of the subsequent byte arrives and
is passed through. So the strip actually refreshes at the speed the data
is issued, not instantaneously (this can be observed by greatly reducing
the data rate). This has implications for POV displays and light painting
applications. The 'subsequent' rule also means that at least one extra
byte must follow the last pixel, in order for the final blue LED to latch.
To reset the pass-through behavior and begin sending new data to the start
of the strip, a number of zero bytes must be issued (remember, all color
data bytes have the high bit set, thus are in the range 128 to 255, so the
zero is 'special'). This should be done before each full payload of color
values to the strip. Curiously, zero bytes can only travel one meter (32
LEDs) down the line before needing backup; the next meter requires an
extra zero byte, and so forth. Longer strips will require progressively
more zeros. *(see note below)
In the interest of efficiency, it's possible to combine the former EOD
extra latch byte and the latter zero reset...the same data can do double
duty, latching the last blue LED while also resetting the strip for the
next payload.
So: reset byte(s) of suitable length are issued once at startup to 'prime'
the strip to a known ready state. After each subsequent LED color payload,
these reset byte(s) are then issued at the END of each payload, both to
latch the last LED and to prep the strip for the start of the next payload
(even if that data does not arrive immediately). This avoids a tiny bit
of latency as the new color payload can begin issuing immediately on some
signal, such as a timer or GPIO trigger.
Technically these zero byte(s) are not a latch, as the color data (save
for the last byte) is already latched. It's a start-of-data marker, or
an indicator to clear the thing-that's-not-a-shift-register. But for
conversational consistency with other LED drivers, we'll refer to it as
a 'latch' anyway.
* This has been validated independently with multiple customers'
hardware. Please do not report as a bug or issue pull requests for
this. Fewer zeros sometimes gives the *illusion* of working, the first
payload will correctly load and latch, but subsequent frames will drop
data at the end. The data shortfall won't always be visually apparent
depending on the color data loaded on the prior and subsequent frames.
Tested. Confirmed. Fact.
*/
#include "LPD8806DBL.h"
#ifdef __AVR_ATtiny85__
// Teensy/Gemma-specific stuff for hardware-assisted SPI @ 2 MHz
#if(F_CPU > 8000000L)
#define SPI_DELAY asm volatile("rjmp .+0"); // Burn 2 cycles
#elif(F_CPU > 4000000L)
#define SPI_DELAY asm volatile("nop"); // Burn 1 cycle
#else
#define SPI_DELAY // Run max speed
#endif
#define SPIBIT \
USICR = ((1<<USIWM0)|(1<<USITC)); \
SPI_DELAY \
USICR = ((1<<USIWM0)|(1<<USITC)|(1<<USICLK)); \
SPI_DELAY
static void spi_out(uint8_t n) {
USIDR = n;
SPIBIT
SPIBIT
SPIBIT
SPIBIT
SPIBIT
SPIBIT
SPIBIT
SPIBIT
}
#else
// All other boards support Full and Proper Hardware SPI
#include <SPI.h>
#define spi_out(n) (void)SPI.transfer(n)
#endif
/*****************************************************************************/
// Constructor for use with hardware SPI (specific clock/data pins):
LPD8806DBL::LPD8806DBL(uint16_t n) {
pixels = NULL;
begun = false;
updateLength(n);
updatePins();
}
// Constructor for use with arbitrary clock/data pins:
LPD8806DBL::LPD8806DBL(uint16_t n, uint8_t dpin, uint8_t cpin) {
pixels = NULL;
begun = false;
updateLength(n);
updatePins(dpin, cpin);
}
// via Michael Vogt/neophob: empty constructor is used when strip length
// isn't known at compile-time; situations where program config might be
// read from internal flash memory or an SD card, or arrive via serial
// command. If using this constructor, MUST follow up with updateLength()
// and updatePins() to establish the strip length and output pins!
LPD8806DBL::LPD8806DBL(void) {
numLEDs = latchBytes = 0;
pixels = NULL;
begun = false;
updatePins(); // Must assume hardware SPI until pins are set
}
// Activate hard/soft SPI as appropriate:
void LPD8806DBL::begin(void) {
if(hardwareSPI == true) startSPI();
else startBitbang();
begun = true;
}
// Change pin assignments post-constructor, switching to hardware SPI:
void LPD8806DBL::updatePins(void) {
pinMode(datapin, INPUT); // Restore data and clock pins to inputs
pinMode(clkpin , INPUT);
datapin = clkpin = 0;
hardwareSPI = true;
// If begin() was previously invoked, init the SPI hardware now:
if(begun == true) startSPI();
// Otherwise, SPI is NOT initted until begin() is explicitly called.
}
// Change pin assignments post-constructor, using arbitrary pins:
void LPD8806DBL::updatePins(uint8_t dpin, uint8_t cpin) {
if(begun == true) { // If begin() was previously invoked...
// If previously using hardware SPI, turn that off:
if(hardwareSPI) {
#ifdef __AVR_ATtiny85__
DDRB &= ~(_BV(PORTB1) | _BV(PORTB2));
#else
SPI.end();
#endif
} else {
pinMode(datapin, INPUT); // Restore prior data and clock pins to inputs
pinMode(clkpin , INPUT);
}
}
datapin = dpin;
clkpin = cpin;
#ifdef __AVR__
clkport = portOutputRegister(digitalPinToPort(cpin));
clkpinmask = digitalPinToBitMask(cpin);
dataport = portOutputRegister(digitalPinToPort(dpin));
datapinmask = digitalPinToBitMask(dpin);
#endif
// If previously begun, enable 'soft' SPI outputs now
if(begun == true) startBitbang();
hardwareSPI = false;
}
// Enable SPI hardware and set up protocol details:
void LPD8806DBL::startSPI(void) {
#ifdef __AVR_ATtiny85__
PORTB &= ~(_BV(PORTB1) | _BV(PORTB2)); // Outputs
DDRB |= _BV(PORTB1) | _BV(PORTB2); // DO (NOT MOSI) + SCK
#else
SPI.begin();
SPI.setBitOrder(MSBFIRST);
SPI.setDataMode(SPI_MODE0);
// SPI bus is run at 2MHz. Although the LPD8806 should, in theory,
// work up to 20MHz, the unshielded wiring from the Arduino is more
// susceptible to interference. Experiment and see what you get.
#if defined(__AVR__) || defined(CORE_TEENSY)
SPI.setClockDivider(SPI_CLOCK_DIV8);
#else
SPI.setClockDivider((F_CPU + 1000000L) / 2000000L);
#endif
#endif
// Issue initial latch/reset to strip:
for(uint16_t i=((numLEDs*2+31)/32); i>0; i--) spi_out(0);
}
// Enable software SPI pins and issue initial latch:
void LPD8806DBL::startBitbang() {
pinMode(datapin, OUTPUT);
pinMode(clkpin , OUTPUT);
#ifdef __AVR__
*dataport &= ~datapinmask; // Data is held low throughout (latch = 0)
for(uint16_t i=((numLEDs*2+31)/32)*8; i>0; i--) {
*clkport |= clkpinmask;
*clkport &= ~clkpinmask;
}
#else
digitalWrite(datapin, LOW);
for(uint16_t i=((numLEDs*2+31)/32)*8; i>0; i--) {
digitalWrite(clkpin, HIGH);
digitalWrite(clkpin, LOW);
}
#endif
}
// Change strip length (see notes with empty constructor, above):
void LPD8806DBL::updateLength(uint16_t n) {
uint16_t dataBytes;
numLEDs = 0;
if(pixels) free(pixels); // Free existing data (if any)
dataBytes = n * 3;
latchBytes = (n*2 + 31) / 32;
if((pixels = (uint8_t *)malloc(dataBytes))) { // Alloc new data
numLEDs = n;
memset( pixels, 0x80, dataBytes); // Init to RGB 'off' state
}
// 'begun' state does not change -- pins retain prior modes
}
uint16_t LPD8806DBL::numPixels(void) {
return numLEDs;
}
void LPD8806DBL::show(void) {
uint8_t *ptr = pixels;
uint16_t i = numLEDs;
uint8_t *p;
if(hardwareSPI) {
while(i--){
p = ptr;
for(uint8_t j = 0; j<2; j++){
ptr = p;
for(uint8_t k = 0; k<3; k++){
spi_out(*ptr++);
}
}
}
i = latchBytes;
while(i--){
spi_out(0);
}
} else {
uint8_t bit;
while(i--) {
p = ptr;
for(uint8_t j = 0; j<2; j++){
ptr = p;
for(uint8_t k = 0; k<3; k++){
for(bit=0x80; bit; bit >>= 1) {
#ifdef __AVR__
if(*ptr & bit) *dataport |= datapinmask;
else *dataport &= ~datapinmask;
*clkport |= clkpinmask;
*clkport &= ~clkpinmask;
#else
if(*ptr & bit) digitalWrite(datapin, HIGH);
else digitalWrite(datapin, LOW);
digitalWrite(clkpin, HIGH);
digitalWrite(clkpin, LOW);
#endif
}
ptr++;
}
}
}
#ifdef __AVR__
*dataport &= ~datapinmask; // Data is held low throughout (latch = 0)
for(uint16_t i=latchBytes*8; i>0; i--) {
*clkport |= clkpinmask;
*clkport &= ~clkpinmask;
}
#else
digitalWrite(datapin, LOW);
for(uint16_t i=latchBytes*8; i>0; i--) {
digitalWrite(clkpin, HIGH);
digitalWrite(clkpin, LOW);
}
#endif
}
}
// Convert separate R,G,B into combined 32-bit GRB color:
uint32_t LPD8806DBL::Color(byte r, byte g, byte b) {
return ((uint32_t)(g | 0x80) << 16) |
((uint32_t)(r | 0x80) << 8) |
b | 0x80 ;
}
// Set pixel color from separate 7-bit R, G, B components:
void LPD8806DBL::setPixelColor(uint16_t n, uint8_t r, uint8_t g, uint8_t b) {
if(n < numLEDs) { // Arrays are 0-indexed, thus NOT '<='
uint8_t *p = &pixels[n * 3];
*p++ = g | 0x80; // Strip color order is GRB,
*p++ = r | 0x80; // not the more common RGB,
*p++ = b | 0x80; // so the order here is intentional; don't "fix"
}
}
// Set pixel color from 'packed' 32-bit GRB (not RGB) value:
void LPD8806DBL::setPixelColor(uint16_t n, uint32_t c) {
if(n < numLEDs) { // Arrays are 0-indexed, thus NOT '<='
uint8_t *p = &pixels[n * 3];
*p++ = (c >> 16) | 0x80;
*p++ = (c >> 8) | 0x80;
*p++ = c | 0x80;
}
}
// Query color from previously-set pixel (returns packed 32-bit GRB value)
uint32_t LPD8806DBL::getPixelColor(uint16_t n) {
if(n < numLEDs) {
uint16_t ofs = n * 3;
return ((uint32_t)(pixels[ofs ] & 0x7f) << 16) |
((uint32_t)(pixels[ofs + 1] & 0x7f) << 8) |
(uint32_t)(pixels[ofs + 2] & 0x7f);
}
return 0; // Pixel # is out of bounds
}