Pinscape Controller version 1 fork. This is a fork to allow for ongoing bug fixes to the original controller version, from before the major changes for the expansion board project.
Dependencies: FastIO FastPWM SimpleDMA mbed
Fork of Pinscape_Controller by
TLC5940/TLC5940.h@29:582472d0bc57, 2015-09-25 (annotated)
- Committer:
- mjr
- Date:
- Fri Sep 25 18:49:53 2015 +0000
- Revision:
- 29:582472d0bc57
- Parent:
- 28:2097c6f8f2db
- Child:
- 30:6e9902f06f48
Test of direct bit writes instead of SPI.
Who changed what in which revision?
User | Revision | Line number | New contents of line |
---|---|---|---|
mjr | 26:cb71c4af2912 | 1 | // Pinscape Controller TLC5940 interface |
mjr | 26:cb71c4af2912 | 2 | // |
mjr | 26:cb71c4af2912 | 3 | // Based on Spencer Davis's mbed TLC5940 library. Adapted for the |
mjr | 26:cb71c4af2912 | 4 | // KL25Z, and simplified to just the functions needed for this |
mjr | 26:cb71c4af2912 | 5 | // application. In particular, this version doesn't include support |
mjr | 26:cb71c4af2912 | 6 | // for dot correction programming or status input. This version also |
mjr | 26:cb71c4af2912 | 7 | // uses a different approach for sending the grayscale data updates, |
mjr | 26:cb71c4af2912 | 8 | // sending updates during the blanking interval rather than overlapping |
mjr | 26:cb71c4af2912 | 9 | // them with the PWM cycle. This results in very slightly longer |
mjr | 26:cb71c4af2912 | 10 | // blanking intervals when updates are pending, effectively reducing |
mjr | 26:cb71c4af2912 | 11 | // the PWM "on" duty cycle (and thus the output brightness) by about |
mjr | 26:cb71c4af2912 | 12 | // 0.3%. This shouldn't be perceptible to users, so it's a small |
mjr | 26:cb71c4af2912 | 13 | // trade-off for the advantage gained, which is much better signal |
mjr | 26:cb71c4af2912 | 14 | // stability when using multiple TLC5940s daisy-chained together. |
mjr | 26:cb71c4af2912 | 15 | // I saw a lot of instability when using the overlapped approach, |
mjr | 26:cb71c4af2912 | 16 | // which seems to be eliminated entirely when sending updates during |
mjr | 26:cb71c4af2912 | 17 | // the blanking interval. |
mjr | 26:cb71c4af2912 | 18 | |
mjr | 26:cb71c4af2912 | 19 | |
mjr | 26:cb71c4af2912 | 20 | #ifndef TLC5940_H |
mjr | 26:cb71c4af2912 | 21 | #define TLC5940_H |
mjr | 26:cb71c4af2912 | 22 | |
mjr | 26:cb71c4af2912 | 23 | #include "mbed.h" |
mjr | 26:cb71c4af2912 | 24 | #include "FastPWM.h" |
mjr | 26:cb71c4af2912 | 25 | |
mjr | 26:cb71c4af2912 | 26 | /** |
mjr | 26:cb71c4af2912 | 27 | * SPI speed used by the mbed to communicate with the TLC5940 |
mjr | 26:cb71c4af2912 | 28 | * The TLC5940 supports up to 30Mhz. It's best to keep this as |
mjr | 26:cb71c4af2912 | 29 | * high as the microcontroller will allow, since a higher SPI |
mjr | 26:cb71c4af2912 | 30 | * speed yields a faster grayscale data update. However, if |
mjr | 26:cb71c4af2912 | 31 | * you have problems with unreliable signal transmission to the |
mjr | 26:cb71c4af2912 | 32 | * TLC5940s, reducing this speed might help. |
mjr | 26:cb71c4af2912 | 33 | * |
mjr | 26:cb71c4af2912 | 34 | * The SPI clock must be fast enough that the data transmission |
mjr | 26:cb71c4af2912 | 35 | * time for a full update is comfortably less than the blanking |
mjr | 26:cb71c4af2912 | 36 | * cycle time. The grayscale refresh requires 192 bits per TLC5940 |
mjr | 26:cb71c4af2912 | 37 | * in the daisy chain, and each bit takes one SPI clock to send. |
mjr | 26:cb71c4af2912 | 38 | * Our reference setup in the Pinscape controller allows for up to |
mjr | 26:cb71c4af2912 | 39 | * 4 TLC5940s, so a full refresh cycle on a fully populated system |
mjr | 26:cb71c4af2912 | 40 | * would be 768 SPI clocks. The blanking cycle is 4096 GSCLK cycles. |
mjr | 26:cb71c4af2912 | 41 | * |
mjr | 26:cb71c4af2912 | 42 | * t(blank) = 4096 * 1/GSCLK_SPEED |
mjr | 26:cb71c4af2912 | 43 | * t(refresh) = 768 * 1/SPI_SPEED |
mjr | 26:cb71c4af2912 | 44 | * Therefore: SPI_SPEED must be > 768/4096 * GSCLK_SPEED |
mjr | 26:cb71c4af2912 | 45 | * |
mjr | 26:cb71c4af2912 | 46 | * Since the SPI speed can be so high, and since we want to keep |
mjr | 26:cb71c4af2912 | 47 | * the GSCLK speed relatively low, the constraint above simply |
mjr | 26:cb71c4af2912 | 48 | * isn't a factor. E.g., at SPI=30MHz and GSCLK=500kHz, |
mjr | 26:cb71c4af2912 | 49 | * t(blank) is 8192us and t(refresh) is 25us. |
mjr | 26:cb71c4af2912 | 50 | */ |
mjr | 29:582472d0bc57 | 51 | #define USE_SPI 1 |
mjr | 26:cb71c4af2912 | 52 | #define SPI_SPEED 3000000 |
mjr | 26:cb71c4af2912 | 53 | |
mjr | 26:cb71c4af2912 | 54 | /** |
mjr | 26:cb71c4af2912 | 55 | * The rate at which the GSCLK pin is pulsed. This also controls |
mjr | 26:cb71c4af2912 | 56 | * how often the reset function is called. The reset function call |
mjr | 26:cb71c4af2912 | 57 | * rate is (1/GSCLK_SPEED) * 4096. The maximum reliable rate is |
mjr | 26:cb71c4af2912 | 58 | * around 32Mhz. It's best to keep this rate as low as possible: |
mjr | 26:cb71c4af2912 | 59 | * the higher the rate, the higher the refresh() call frequency, |
mjr | 26:cb71c4af2912 | 60 | * so the higher the CPU load. |
mjr | 26:cb71c4af2912 | 61 | * |
mjr | 26:cb71c4af2912 | 62 | * The lower bound is probably dependent on the application. For |
mjr | 26:cb71c4af2912 | 63 | * driving LEDs, the limiting factor is that lower rates will increase |
mjr | 26:cb71c4af2912 | 64 | * visible flicker. 200 kHz seems to be a good lower bound for LEDs. |
mjr | 26:cb71c4af2912 | 65 | * That provides about 48 cycles per second - that's about the same as |
mjr | 26:cb71c4af2912 | 66 | * the 50 Hz A/C cycle rate in many countries, which was itself chosen |
mjr | 26:cb71c4af2912 | 67 | * so that incandescent lights don't flicker. (This rate is a function |
mjr | 26:cb71c4af2912 | 68 | * of human eye physiology, which has its own refresh cycle of sorts |
mjr | 26:cb71c4af2912 | 69 | * that runs at about 50 Hz. If you're designing an LED system for |
mjr | 26:cb71c4af2912 | 70 | * viewing by cats or drosophila, you might want to look into your |
mjr | 26:cb71c4af2912 | 71 | * target species' eye physiology, since the persistence of vision |
mjr | 26:cb71c4af2912 | 72 | * rate varies quite a bit from species to species.) Flicker tends to |
mjr | 26:cb71c4af2912 | 73 | * be more noticeable in LEDs than in incandescents, since LEDs don't |
mjr | 26:cb71c4af2912 | 74 | * have the thermal inertia of incandescents, so we use a slightly |
mjr | 26:cb71c4af2912 | 75 | * higher default here. 500 kHz = 122 full grayscale cycles per |
mjr | 26:cb71c4af2912 | 76 | * second = 122 reset calls per second (call every 8ms). |
mjr | 26:cb71c4af2912 | 77 | */ |
mjr | 26:cb71c4af2912 | 78 | #define GSCLK_SPEED 500000 |
mjr | 26:cb71c4af2912 | 79 | |
mjr | 26:cb71c4af2912 | 80 | /** |
mjr | 26:cb71c4af2912 | 81 | * This class controls a TLC5940 PWM driver IC. |
mjr | 26:cb71c4af2912 | 82 | * |
mjr | 26:cb71c4af2912 | 83 | * Using the TLC5940 class to control an LED: |
mjr | 26:cb71c4af2912 | 84 | * @code |
mjr | 26:cb71c4af2912 | 85 | * #include "mbed.h" |
mjr | 26:cb71c4af2912 | 86 | * #include "TLC5940.h" |
mjr | 26:cb71c4af2912 | 87 | * |
mjr | 26:cb71c4af2912 | 88 | * // Create the TLC5940 instance |
mjr | 26:cb71c4af2912 | 89 | * TLC5940 tlc(p7, p5, p21, p9, p10, p11, p12, 1); |
mjr | 26:cb71c4af2912 | 90 | * |
mjr | 26:cb71c4af2912 | 91 | * int main() |
mjr | 26:cb71c4af2912 | 92 | * { |
mjr | 26:cb71c4af2912 | 93 | * // Enable the first LED |
mjr | 26:cb71c4af2912 | 94 | * tlc.set(0, 0xfff); |
mjr | 26:cb71c4af2912 | 95 | * |
mjr | 26:cb71c4af2912 | 96 | * while(1) |
mjr | 26:cb71c4af2912 | 97 | * { |
mjr | 26:cb71c4af2912 | 98 | * } |
mjr | 26:cb71c4af2912 | 99 | * } |
mjr | 26:cb71c4af2912 | 100 | * @endcode |
mjr | 26:cb71c4af2912 | 101 | */ |
mjr | 26:cb71c4af2912 | 102 | class TLC5940 |
mjr | 26:cb71c4af2912 | 103 | { |
mjr | 26:cb71c4af2912 | 104 | public: |
mjr | 26:cb71c4af2912 | 105 | /** |
mjr | 26:cb71c4af2912 | 106 | * Set up the TLC5940 |
mjr | 26:cb71c4af2912 | 107 | * @param SCLK - The SCK pin of the SPI bus |
mjr | 26:cb71c4af2912 | 108 | * @param MOSI - The MOSI pin of the SPI bus |
mjr | 26:cb71c4af2912 | 109 | * @param GSCLK - The GSCLK pin of the TLC5940(s) |
mjr | 26:cb71c4af2912 | 110 | * @param BLANK - The BLANK pin of the TLC5940(s) |
mjr | 26:cb71c4af2912 | 111 | * @param XLAT - The XLAT pin of the TLC5940(s) |
mjr | 26:cb71c4af2912 | 112 | * @param nchips - The number of TLC5940s (if you are daisy chaining) |
mjr | 26:cb71c4af2912 | 113 | */ |
mjr | 26:cb71c4af2912 | 114 | TLC5940(PinName SCLK, PinName MOSI, PinName GSCLK, PinName BLANK, PinName XLAT, int nchips) |
mjr | 29:582472d0bc57 | 115 | #if USE_SPI |
mjr | 26:cb71c4af2912 | 116 | : spi(MOSI, NC, SCLK), |
mjr | 29:582472d0bc57 | 117 | #else |
mjr | 29:582472d0bc57 | 118 | : sin(MOSI), sclk(SCLK), |
mjr | 29:582472d0bc57 | 119 | #endif |
mjr | 26:cb71c4af2912 | 120 | gsclk(GSCLK), |
mjr | 26:cb71c4af2912 | 121 | blank(BLANK), |
mjr | 26:cb71c4af2912 | 122 | xlat(XLAT), |
mjr | 26:cb71c4af2912 | 123 | nchips(nchips), |
mjr | 28:2097c6f8f2db | 124 | newGSData(true) |
mjr | 26:cb71c4af2912 | 125 | { |
mjr | 26:cb71c4af2912 | 126 | // allocate the grayscale buffer |
mjr | 26:cb71c4af2912 | 127 | gs = new unsigned short[nchips*16]; |
mjr | 28:2097c6f8f2db | 128 | memset(gs, 0, nchips*16*sizeof(gs[0])); |
mjr | 26:cb71c4af2912 | 129 | |
mjr | 29:582472d0bc57 | 130 | #if USE_SPI |
mjr | 26:cb71c4af2912 | 131 | // Configure SPI format and speed. Note that KL25Z ONLY supports 8-bit |
mjr | 26:cb71c4af2912 | 132 | // mode. The TLC5940 nominally requires 12-bit data blocks for the |
mjr | 26:cb71c4af2912 | 133 | // grayscale levels, but SPI is ultimately just a bit-level serial format, |
mjr | 26:cb71c4af2912 | 134 | // so we can reformat the 12-bit blocks into 8-bit bytes to fit the |
mjr | 26:cb71c4af2912 | 135 | // KL25Z's limits. This should work equally well on other microcontrollers |
mjr | 26:cb71c4af2912 | 136 | // that are more flexible. The TLC5940 appears to require polarity/phase |
mjr | 26:cb71c4af2912 | 137 | // format 0. |
mjr | 26:cb71c4af2912 | 138 | spi.format(8, 0); |
mjr | 26:cb71c4af2912 | 139 | spi.frequency(SPI_SPEED); |
mjr | 29:582472d0bc57 | 140 | #else |
mjr | 29:582472d0bc57 | 141 | sclk = 1; |
mjr | 29:582472d0bc57 | 142 | #endif |
mjr | 29:582472d0bc57 | 143 | |
mjr | 26:cb71c4af2912 | 144 | // Set output pin states |
mjr | 26:cb71c4af2912 | 145 | xlat = 0; |
mjr | 26:cb71c4af2912 | 146 | blank = 1; |
mjr | 26:cb71c4af2912 | 147 | |
mjr | 26:cb71c4af2912 | 148 | // Configure PWM output for GSCLK frequency at 50% duty cycle |
mjr | 26:cb71c4af2912 | 149 | gsclk.period(1.0/GSCLK_SPEED); |
mjr | 26:cb71c4af2912 | 150 | gsclk.write(.5); |
mjr | 26:cb71c4af2912 | 151 | blank = 0; |
mjr | 29:582472d0bc57 | 152 | } |
mjr | 29:582472d0bc57 | 153 | |
mjr | 29:582472d0bc57 | 154 | // start the clock running |
mjr | 29:582472d0bc57 | 155 | void start() |
mjr | 29:582472d0bc57 | 156 | { |
mjr | 26:cb71c4af2912 | 157 | // Set up the first call to the reset function, which asserts BLANK to |
mjr | 26:cb71c4af2912 | 158 | // end the PWM cycle and handles new grayscale data output and latching. |
mjr | 26:cb71c4af2912 | 159 | // The original version of this library uses a timer to call reset |
mjr | 26:cb71c4af2912 | 160 | // periodically, but that approach is somewhat problematic because the |
mjr | 26:cb71c4af2912 | 161 | // reset function itself takes a small amount of time to run, so the |
mjr | 26:cb71c4af2912 | 162 | // *actual* cycle is slightly longer than what we get from counting |
mjr | 26:cb71c4af2912 | 163 | // GS clocks. Running reset on a timer therefore causes the calls to |
mjr | 26:cb71c4af2912 | 164 | // slip out of phase with the actual full cycles, which causes |
mjr | 26:cb71c4af2912 | 165 | // premature blanking that shows up as visible flicker. To get the |
mjr | 26:cb71c4af2912 | 166 | // reset cycle to line up exactly with a full PWM cycle, it works |
mjr | 26:cb71c4af2912 | 167 | // better to set up a new timer on each cycle, *after* we've finished |
mjr | 26:cb71c4af2912 | 168 | // with the somewhat unpredictable overhead of the interrupt handler. |
mjr | 26:cb71c4af2912 | 169 | // This ensures that we'll get much closer to exact alignment of the |
mjr | 26:cb71c4af2912 | 170 | // cycle phase, and in any case the worst that happens is that some |
mjr | 26:cb71c4af2912 | 171 | // cycles are very slightly too long or short (due to imperfections |
mjr | 26:cb71c4af2912 | 172 | // in the timer clock vs the PWM clock that determines the GSCLCK |
mjr | 26:cb71c4af2912 | 173 | // output to the TLC5940), which is far less noticeable than a |
mjr | 26:cb71c4af2912 | 174 | // constantly rotating phase misalignment. |
mjr | 26:cb71c4af2912 | 175 | reset_timer.attach(this, &TLC5940::reset, (1.0/GSCLK_SPEED)*4096.0); |
mjr | 26:cb71c4af2912 | 176 | } |
mjr | 26:cb71c4af2912 | 177 | |
mjr | 26:cb71c4af2912 | 178 | ~TLC5940() |
mjr | 26:cb71c4af2912 | 179 | { |
mjr | 26:cb71c4af2912 | 180 | delete [] gs; |
mjr | 26:cb71c4af2912 | 181 | } |
mjr | 26:cb71c4af2912 | 182 | |
mjr | 26:cb71c4af2912 | 183 | /** |
mjr | 26:cb71c4af2912 | 184 | * Set the next chunk of grayscale data to be sent |
mjr | 26:cb71c4af2912 | 185 | * @param data - Array of 16 bit shorts containing 16 12 bit grayscale data chunks per TLC5940 |
mjr | 26:cb71c4af2912 | 186 | * @note These must be in intervals of at least (1/GSCLK_SPEED) * 4096 to be sent |
mjr | 26:cb71c4af2912 | 187 | */ |
mjr | 26:cb71c4af2912 | 188 | void set(int idx, unsigned short data) |
mjr | 26:cb71c4af2912 | 189 | { |
mjr | 26:cb71c4af2912 | 190 | // store the data, and flag the pending update for the interrupt handler to carry out |
mjr | 26:cb71c4af2912 | 191 | gs[idx] = data; |
mjr | 29:582472d0bc57 | 192 | // newGSData = true; |
mjr | 26:cb71c4af2912 | 193 | } |
mjr | 26:cb71c4af2912 | 194 | |
mjr | 26:cb71c4af2912 | 195 | private: |
mjr | 26:cb71c4af2912 | 196 | // current level for each output |
mjr | 26:cb71c4af2912 | 197 | unsigned short *gs; |
mjr | 26:cb71c4af2912 | 198 | |
mjr | 29:582472d0bc57 | 199 | #if USE_SPI |
mjr | 26:cb71c4af2912 | 200 | // SPI port - only MOSI and SCK are used |
mjr | 26:cb71c4af2912 | 201 | SPI spi; |
mjr | 29:582472d0bc57 | 202 | #else |
mjr | 29:582472d0bc57 | 203 | DigitalOut sin; |
mjr | 29:582472d0bc57 | 204 | DigitalOut sclk; |
mjr | 29:582472d0bc57 | 205 | #endif |
mjr | 26:cb71c4af2912 | 206 | |
mjr | 26:cb71c4af2912 | 207 | // use a PWM out for the grayscale clock - this provides a stable |
mjr | 26:cb71c4af2912 | 208 | // square wave signal without consuming CPU |
mjr | 26:cb71c4af2912 | 209 | FastPWM gsclk; |
mjr | 26:cb71c4af2912 | 210 | |
mjr | 26:cb71c4af2912 | 211 | // Digital out pins used for the TLC5940 |
mjr | 26:cb71c4af2912 | 212 | DigitalOut blank; |
mjr | 26:cb71c4af2912 | 213 | DigitalOut xlat; |
mjr | 26:cb71c4af2912 | 214 | |
mjr | 26:cb71c4af2912 | 215 | // number of daisy-chained TLC5940s we're controlling |
mjr | 26:cb71c4af2912 | 216 | int nchips; |
mjr | 26:cb71c4af2912 | 217 | |
mjr | 26:cb71c4af2912 | 218 | // Timeout to end each PWM cycle. This is a one-shot timer that we reset |
mjr | 26:cb71c4af2912 | 219 | // on each cycle. |
mjr | 26:cb71c4af2912 | 220 | Timeout reset_timer; |
mjr | 26:cb71c4af2912 | 221 | |
mjr | 26:cb71c4af2912 | 222 | // Has new GS/DC data been loaded? |
mjr | 26:cb71c4af2912 | 223 | volatile bool newGSData; |
mjr | 26:cb71c4af2912 | 224 | |
mjr | 26:cb71c4af2912 | 225 | // Function to reset the display and send the next chunks of data |
mjr | 26:cb71c4af2912 | 226 | void reset() |
mjr | 26:cb71c4af2912 | 227 | { |
mjr | 26:cb71c4af2912 | 228 | // turn off the grayscale clock, and assert BLANK to end the grayscale cycle |
mjr | 26:cb71c4af2912 | 229 | gsclk.write(0); |
mjr | 26:cb71c4af2912 | 230 | blank = 1; |
mjr | 26:cb71c4af2912 | 231 | |
mjr | 26:cb71c4af2912 | 232 | // If we have new GS data, send it now |
mjr | 29:582472d0bc57 | 233 | if (true) // (newGSData) |
mjr | 26:cb71c4af2912 | 234 | { |
mjr | 26:cb71c4af2912 | 235 | // Send the new grayscale data. |
mjr | 26:cb71c4af2912 | 236 | // |
mjr | 26:cb71c4af2912 | 237 | // Note that ideally, we'd do this during the new PWM cycle |
mjr | 26:cb71c4af2912 | 238 | // rather than during the blanking interval. The TLC5940 is |
mjr | 26:cb71c4af2912 | 239 | // specifically designed to allow this. However, in my testing, |
mjr | 26:cb71c4af2912 | 240 | // I found that sending new data during the PWM cycle was |
mjr | 26:cb71c4af2912 | 241 | // unreliable - it seemed to cause a fair amount of glitching, |
mjr | 26:cb71c4af2912 | 242 | // which as far as I can tell is signal noise coming from |
mjr | 26:cb71c4af2912 | 243 | // crosstalk between the grayscale clock signal and the |
mjr | 26:cb71c4af2912 | 244 | // SPI signal. This seems to be a common problem with |
mjr | 26:cb71c4af2912 | 245 | // daisy-chained TLC5940s. It can in principle be solved with |
mjr | 26:cb71c4af2912 | 246 | // careful high-speed circuit design (good ground planes, |
mjr | 26:cb71c4af2912 | 247 | // short leads, decoupling capacitors), and indeed I was able |
mjr | 26:cb71c4af2912 | 248 | // to improve stability to some extent with circuit tweaks, |
mjr | 26:cb71c4af2912 | 249 | // but I wasn't able to eliminate it entirely. Moving the |
mjr | 26:cb71c4af2912 | 250 | // data refresh into the blanking interval, on the other |
mjr | 26:cb71c4af2912 | 251 | // hand, seems to entirely eliminate any instability. |
mjr | 26:cb71c4af2912 | 252 | // |
mjr | 26:cb71c4af2912 | 253 | // Note that there's no CPU performance penalty to this |
mjr | 26:cb71c4af2912 | 254 | // approach. The KL25Z SPI implementation isn't capable of |
mjr | 26:cb71c4af2912 | 255 | // asynchronous DMA, so the CPU has to wait for the |
mjr | 26:cb71c4af2912 | 256 | // transmission no matter when it happens. The only downside |
mjr | 26:cb71c4af2912 | 257 | // I see to this approach is that it decreases the duty cycle |
mjr | 26:cb71c4af2912 | 258 | // of the PWM during updates - but very slightly. With the |
mjr | 26:cb71c4af2912 | 259 | // SPI clock at 30 MHz and the PWM clock at 500 kHz, the full |
mjr | 26:cb71c4af2912 | 260 | // PWM cycle is 8192us, and the data refresh time is 25us. |
mjr | 26:cb71c4af2912 | 261 | // So by doing the data refersh in the blanking interval, |
mjr | 26:cb71c4af2912 | 262 | // we're effectively extending the PWM cycle to 8217us, |
mjr | 26:cb71c4af2912 | 263 | // which is 0.3% longer. Since the outputs are all off |
mjr | 26:cb71c4af2912 | 264 | // during the blanking cycle, this is equivalent to |
mjr | 26:cb71c4af2912 | 265 | // decreasing all of the output brightnesses by 0.3%. That |
mjr | 26:cb71c4af2912 | 266 | // should be imperceptible to users. |
mjr | 26:cb71c4af2912 | 267 | update(); |
mjr | 26:cb71c4af2912 | 268 | |
mjr | 26:cb71c4af2912 | 269 | // the chips are now in sync with our data, so we have no more |
mjr | 26:cb71c4af2912 | 270 | // pending update |
mjr | 26:cb71c4af2912 | 271 | newGSData = false; |
mjr | 26:cb71c4af2912 | 272 | |
mjr | 26:cb71c4af2912 | 273 | // latch the new data while we're still blanked |
mjr | 26:cb71c4af2912 | 274 | xlat = 1; |
mjr | 26:cb71c4af2912 | 275 | xlat = 0; |
mjr | 26:cb71c4af2912 | 276 | } |
mjr | 26:cb71c4af2912 | 277 | |
mjr | 26:cb71c4af2912 | 278 | // end the blanking interval and restart the grayscale clock |
mjr | 26:cb71c4af2912 | 279 | blank = 0; |
mjr | 26:cb71c4af2912 | 280 | gsclk.write(.5); |
mjr | 26:cb71c4af2912 | 281 | |
mjr | 26:cb71c4af2912 | 282 | // set up the next blanking interrupt |
mjr | 26:cb71c4af2912 | 283 | reset_timer.attach(this, &TLC5940::reset, (1.0/GSCLK_SPEED)*4096.0); |
mjr | 26:cb71c4af2912 | 284 | } |
mjr | 26:cb71c4af2912 | 285 | |
mjr | 26:cb71c4af2912 | 286 | void update() |
mjr | 26:cb71c4af2912 | 287 | { |
mjr | 29:582472d0bc57 | 288 | #if USE_SPI |
mjr | 26:cb71c4af2912 | 289 | // Send GS data. The serial format orders the outputs from last to first |
mjr | 26:cb71c4af2912 | 290 | // (output #15 on the last chip in the daisy-chain to output #0 on the |
mjr | 26:cb71c4af2912 | 291 | // first chip). For each output, we send 12 bits containing the grayscale |
mjr | 26:cb71c4af2912 | 292 | // level (0 = fully off, 0xFFF = fully on). Bit order is most significant |
mjr | 26:cb71c4af2912 | 293 | // bit first. |
mjr | 26:cb71c4af2912 | 294 | // |
mjr | 26:cb71c4af2912 | 295 | // The KL25Z SPI can only send in 8-bit increments, so we need to divvy up |
mjr | 26:cb71c4af2912 | 296 | // the 12-bit outputs into 8-bit bytes. Each pair of 12-bit outputs adds up |
mjr | 26:cb71c4af2912 | 297 | // to 24 bits, which divides evenly into 3 bytes, so send each pairs of |
mjr | 26:cb71c4af2912 | 298 | // outputs as three bytes: |
mjr | 26:cb71c4af2912 | 299 | // |
mjr | 26:cb71c4af2912 | 300 | // [ element i+1 bits ] [ element i bits ] |
mjr | 26:cb71c4af2912 | 301 | // 11 10 9 8 7 6 5 4 3 2 1 0 11 10 9 8 7 6 5 4 3 2 1 0 |
mjr | 26:cb71c4af2912 | 302 | // [ first byte ] [ second byte ] [ third byte ] |
mjr | 29:582472d0bc57 | 303 | for (int i = 61 /* (16 * nchips) - 2 */ ; i >= 0 ; i -= 2) |
mjr | 26:cb71c4af2912 | 304 | { |
mjr | 26:cb71c4af2912 | 305 | // first byte - element i+1 bits 4-11 |
mjr | 26:cb71c4af2912 | 306 | spi.write(((gs[i+1] & 0xFF0) >> 4) & 0xff); |
mjr | 26:cb71c4af2912 | 307 | |
mjr | 26:cb71c4af2912 | 308 | // second byte - element i+1 bits 0-3, then element i bits 8-11 |
mjr | 26:cb71c4af2912 | 309 | spi.write((((gs[i+1] & 0x00F) << 4) | ((gs[i] & 0xF00) >> 8)) & 0xFF); |
mjr | 26:cb71c4af2912 | 310 | |
mjr | 26:cb71c4af2912 | 311 | // third byte - element i bits 0-7 |
mjr | 26:cb71c4af2912 | 312 | spi.write(gs[i] & 0x0FF); |
mjr | 26:cb71c4af2912 | 313 | } |
mjr | 29:582472d0bc57 | 314 | #else |
mjr | 29:582472d0bc57 | 315 | // Send GS data, from last output to first output, 12 bits per output, |
mjr | 29:582472d0bc57 | 316 | // most significant bit first. |
mjr | 29:582472d0bc57 | 317 | for (int i = 16*3 - 1 ; i >= 0 ; --i) |
mjr | 29:582472d0bc57 | 318 | { |
mjr | 29:582472d0bc57 | 319 | unsigned data = gs[i]; |
mjr | 29:582472d0bc57 | 320 | for (unsigned int mask = 1 << 11, bit = 0 ; bit < 12 ; ++bit, mask >>= 1) |
mjr | 29:582472d0bc57 | 321 | { |
mjr | 29:582472d0bc57 | 322 | sclk = 0; |
mjr | 29:582472d0bc57 | 323 | sin = (data & mask) ? 1 : 0; |
mjr | 29:582472d0bc57 | 324 | sclk = 1; |
mjr | 29:582472d0bc57 | 325 | } |
mjr | 29:582472d0bc57 | 326 | } |
mjr | 29:582472d0bc57 | 327 | #endif |
mjr | 26:cb71c4af2912 | 328 | } |
mjr | 26:cb71c4af2912 | 329 | }; |
mjr | 26:cb71c4af2912 | 330 | |
mjr | 26:cb71c4af2912 | 331 | |
mjr | 26:cb71c4af2912 | 332 | #endif |