Mike R / Mbed 2 deprecated Pinscape_Controller_v1

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 Mike R

TLC5940/TLC5940.h@38:091e511ce8a0, 2016-01-05 (annotated)

Committer:
mjr
Date:
Tue Jan 05 05:23:07 2016 +0000
Revision:
38:091e511ce8a0
Parent:
33:d832bcab089e
Child:
39:b3815a1c3802
USB improvements

Who changed what in which revision?

UserRevisionLine numberNew 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 38:091e511ce8a0 23 // Data Transmission Mode.
mjr 38:091e511ce8a0 24 //
mjr 38:091e511ce8a0 25 // NOTE! This section contains a possible workaround to try if you're
mjr 38:091e511ce8a0 26 // having data signal stability problems with your TLC5940 chips. If
mjr 38:091e511ce8a0 27 // your chips are working properly, you can ignore this part!
mjr 33:d832bcab089e 28 //
mjr 38:091e511ce8a0 29 // The software has two options for sending data updates to the chips:
mjr 38:091e511ce8a0 30 //
mjr 38:091e511ce8a0 31 // Mode 0: Send data *during* the grayscale cycle. This is the way the
mjr 38:091e511ce8a0 32 // chips are designed to be used. While the grayscale clock is running,
mjr 38:091e511ce8a0 33 // we send data for the *next* cycle, then latch the updated data to the
mjr 38:091e511ce8a0 34 // output registers during the blanking interval at the end of the cycle.
mjr 33:d832bcab089e 35 //
mjr 38:091e511ce8a0 36 // Mode 1: Send data *between* grayscale cycles. In this mode, we send
mjr 38:091e511ce8a0 37 // each complete update during a blanking period, then latch the update
mjr 38:091e511ce8a0 38 // and start the next grayscale cycle. This isn't the way the chips were
mjr 38:091e511ce8a0 39 // intended to be used, but it works. The disadvantage is that it requires
mjr 38:091e511ce8a0 40 // the blanking interval to be extended to be long enough for the full
mjr 38:091e511ce8a0 41 // data update (192 bits * the number of chips in the chain). Since the
mjr 38:091e511ce8a0 42 // outputs are turned off for the entire blanking period, this reduces
mjr 38:091e511ce8a0 43 // the overall brightness/intensity of the outputs by reducing the duty
mjr 38:091e511ce8a0 44 // cycle. The TLC5940 chips can't achieve 100% duty cycle to begin with,
mjr 38:091e511ce8a0 45 // since they require a certain minimum time in the blanking interval
mjr 38:091e511ce8a0 46 // between grayscale cycles; however, the minimum is so short that the
mjr 38:091e511ce8a0 47 // duty cycle is close to 100%. With the full data transmission stuffed
mjr 38:091e511ce8a0 48 // into the blanking interval, we reduce the duty cycle further below
mjr 38:091e511ce8a0 49 // 100%. With four chips in the chain, a 28 MHz data clock, and a
mjr 38:091e511ce8a0 50 // 500 kHz grayscale clock, the reduction is about 0.3%.
mjr 33:d832bcab089e 51 //
mjr 38:091e511ce8a0 52 // By default, we use Mode 0, because that's the timing model specified
mjr 38:091e511ce8a0 53 // by the manufacturer, and empirically it works well with the Pinscape
mjr 38:091e511ce8a0 54 // Expansion boards.
mjr 38:091e511ce8a0 55 //
mjr 38:091e511ce8a0 56 // So what's the point of Mode 1? In early testing, with a breadboard
mjr 38:091e511ce8a0 57 // setup, I saw some problems with data signal stability, which manifested
mjr 38:091e511ce8a0 58 // as sporadic flickering in the outputs. Switching to Mode 1 improved
mjr 38:091e511ce8a0 59 // the signal stability considerably. I'm therefore leaving this code
mjr 38:091e511ce8a0 60 // available as an option in case anyone runs into similar signal problems
mjr 38:091e511ce8a0 61 // and wants to try the alternative mode as a workaround.
mjr 38:091e511ce8a0 62 //
mjr 38:091e511ce8a0 63 #define DATA_UPDATE_INSIDE_BLANKING 0
mjr 33:d832bcab089e 64
mjr 26:cb71c4af2912 65 #include "mbed.h"
mjr 26:cb71c4af2912 66 #include "FastPWM.h"
mjr 30:6e9902f06f48 67 #include "SimpleDMA.h"
mjr 26:cb71c4af2912 68
mjr 26:cb71c4af2912 69 /**
mjr 26:cb71c4af2912 70 * SPI speed used by the mbed to communicate with the TLC5940
mjr 26:cb71c4af2912 71 * The TLC5940 supports up to 30Mhz. It's best to keep this as
mjr 33:d832bcab089e 72 * high as possible, since a higher SPI speed yields a faster
mjr 33:d832bcab089e 73 * grayscale data update. However, I've seen some slight
mjr 33:d832bcab089e 74 * instability in the signal in my breadboard setup using the
mjr 33:d832bcab089e 75 * full 30MHz, so I've reduced this slightly, which seems to
mjr 33:d832bcab089e 76 * yield a solid signal. The limit will vary according to how
mjr 33:d832bcab089e 77 * clean the signal path is to the chips; you can probably crank
mjr 33:d832bcab089e 78 * this up to full speed if you have a well-designed PCB, good
mjr 33:d832bcab089e 79 * decoupling capacitors near the 5940 VCC/GND pins, and short
mjr 33:d832bcab089e 80 * wires between the KL25Z and the PCB. A short, clean path to
mjr 33:d832bcab089e 81 * KL25Z ground seems especially important.
mjr 26:cb71c4af2912 82 *
mjr 26:cb71c4af2912 83 * The SPI clock must be fast enough that the data transmission
mjr 26:cb71c4af2912 84 * time for a full update is comfortably less than the blanking
mjr 26:cb71c4af2912 85 * cycle time. The grayscale refresh requires 192 bits per TLC5940
mjr 26:cb71c4af2912 86 * in the daisy chain, and each bit takes one SPI clock to send.
mjr 26:cb71c4af2912 87 * Our reference setup in the Pinscape controller allows for up to
mjr 26:cb71c4af2912 88 * 4 TLC5940s, so a full refresh cycle on a fully populated system
mjr 26:cb71c4af2912 89 * would be 768 SPI clocks. The blanking cycle is 4096 GSCLK cycles.
mjr 26:cb71c4af2912 90 *
mjr 26:cb71c4af2912 91 * t(blank) = 4096 * 1/GSCLK_SPEED
mjr 26:cb71c4af2912 92 * t(refresh) = 768 * 1/SPI_SPEED
mjr 26:cb71c4af2912 93 * Therefore: SPI_SPEED must be > 768/4096 * GSCLK_SPEED
mjr 26:cb71c4af2912 94 *
mjr 26:cb71c4af2912 95 * Since the SPI speed can be so high, and since we want to keep
mjr 26:cb71c4af2912 96 * the GSCLK speed relatively low, the constraint above simply
mjr 26:cb71c4af2912 97 * isn't a factor. E.g., at SPI=30MHz and GSCLK=500kHz,
mjr 26:cb71c4af2912 98 * t(blank) is 8192us and t(refresh) is 25us.
mjr 26:cb71c4af2912 99 */
mjr 38:091e511ce8a0 100 #define SPI_SPEED 28000000
mjr 26:cb71c4af2912 101
mjr 26:cb71c4af2912 102 /**
mjr 26:cb71c4af2912 103 * The rate at which the GSCLK pin is pulsed. This also controls
mjr 26:cb71c4af2912 104 * how often the reset function is called. The reset function call
mjr 38:091e511ce8a0 105 * interval is (1/GSCLK_SPEED) * 4096. The maximum reliable rate is
mjr 26:cb71c4af2912 106 * around 32Mhz. It's best to keep this rate as low as possible:
mjr 26:cb71c4af2912 107 * the higher the rate, the higher the refresh() call frequency,
mjr 26:cb71c4af2912 108 * so the higher the CPU load.
mjr 26:cb71c4af2912 109 *
mjr 38:091e511ce8a0 110 * The lower bound depends on the application. For driving LEDs,
mjr 38:091e511ce8a0 111 * the limiting factor is that lower rates will increase visible flicker.
mjr 38:091e511ce8a0 112 * A GSCLK speed of 200 kHz is about as low as you can go with LEDs
mjr 38:091e511ce8a0 113 * without excessive flicker. That equals about 48 full grayscale
mjr 38:091e511ce8a0 114 * cycles per second. That might seem perfectly good in that it's
mjr 38:091e511ce8a0 115 * about the same as the standard 50Hz A/C cycle rate in many countries,
mjr 38:091e511ce8a0 116 * but the 50Hz rate was chosen to minimize visible flicker in
mjr 38:091e511ce8a0 117 * incandescent lamps, not LEDs. LEDs need a higher rate because they
mjr 38:091e511ce8a0 118 * don't have thermal inertia as incandescents do. The default we use
mjr 38:091e511ce8a0 119 * here is 500 kHz = 122 full grayscale cycles per second. That seems
mjr 38:091e511ce8a0 120 * to produce excellent visual results. Higher rates would probably
mjr 38:091e511ce8a0 121 * produce diminishing returns given that they also increase CPU load.
mjr 26:cb71c4af2912 122 */
mjr 26:cb71c4af2912 123 #define GSCLK_SPEED 500000
mjr 26:cb71c4af2912 124
mjr 26:cb71c4af2912 125 /**
mjr 26:cb71c4af2912 126 * This class controls a TLC5940 PWM driver IC.
mjr 26:cb71c4af2912 127 *
mjr 26:cb71c4af2912 128 * Using the TLC5940 class to control an LED:
mjr 26:cb71c4af2912 129 * @code
mjr 26:cb71c4af2912 130 * #include "mbed.h"
mjr 26:cb71c4af2912 131 * #include "TLC5940.h"
mjr 26:cb71c4af2912 132 *
mjr 26:cb71c4af2912 133 * // Create the TLC5940 instance
mjr 26:cb71c4af2912 134 * TLC5940 tlc(p7, p5, p21, p9, p10, p11, p12, 1);
mjr 26:cb71c4af2912 135 *
mjr 26:cb71c4af2912 136 * int main()
mjr 26:cb71c4af2912 137 * {
mjr 26:cb71c4af2912 138 * // Enable the first LED
mjr 26:cb71c4af2912 139 * tlc.set(0, 0xfff);
mjr 26:cb71c4af2912 140 *
mjr 26:cb71c4af2912 141 * while(1)
mjr 26:cb71c4af2912 142 * {
mjr 26:cb71c4af2912 143 * }
mjr 26:cb71c4af2912 144 * }
mjr 26:cb71c4af2912 145 * @endcode
mjr 26:cb71c4af2912 146 */
mjr 26:cb71c4af2912 147 class TLC5940
mjr 26:cb71c4af2912 148 {
mjr 26:cb71c4af2912 149 public:
mjr 26:cb71c4af2912 150 /**
mjr 26:cb71c4af2912 151 * Set up the TLC5940
mjr 26:cb71c4af2912 152 * @param SCLK - The SCK pin of the SPI bus
mjr 26:cb71c4af2912 153 * @param MOSI - The MOSI pin of the SPI bus
mjr 26:cb71c4af2912 154 * @param GSCLK - The GSCLK pin of the TLC5940(s)
mjr 26:cb71c4af2912 155 * @param BLANK - The BLANK pin of the TLC5940(s)
mjr 26:cb71c4af2912 156 * @param XLAT - The XLAT pin of the TLC5940(s)
mjr 26:cb71c4af2912 157 * @param nchips - The number of TLC5940s (if you are daisy chaining)
mjr 26:cb71c4af2912 158 */
mjr 26:cb71c4af2912 159 TLC5940(PinName SCLK, PinName MOSI, PinName GSCLK, PinName BLANK, PinName XLAT, int nchips)
mjr 26:cb71c4af2912 160 : spi(MOSI, NC, SCLK),
mjr 26:cb71c4af2912 161 gsclk(GSCLK),
mjr 26:cb71c4af2912 162 blank(BLANK),
mjr 26:cb71c4af2912 163 xlat(XLAT),
mjr 33:d832bcab089e 164 nchips(nchips)
mjr 26:cb71c4af2912 165 {
mjr 33:d832bcab089e 166 // set XLAT to initially off
mjr 30:6e9902f06f48 167 xlat = 0;
mjr 33:d832bcab089e 168
mjr 33:d832bcab089e 169 // Assert BLANK while starting up, to keep the outputs turned off until
mjr 33:d832bcab089e 170 // everything is stable. This helps prevent spurious flashes during startup.
mjr 33:d832bcab089e 171 // (That's not particularly important for lights, but it matters more for
mjr 33:d832bcab089e 172 // tactile devices. It's a bit alarming to fire a replay knocker on every
mjr 33:d832bcab089e 173 // power-on, for example.)
mjr 30:6e9902f06f48 174 blank = 1;
mjr 30:6e9902f06f48 175
mjr 33:d832bcab089e 176 // allocate the grayscale buffer, and set all outputs to fully off
mjr 26:cb71c4af2912 177 gs = new unsigned short[nchips*16];
mjr 28:2097c6f8f2db 178 memset(gs, 0, nchips*16*sizeof(gs[0]));
mjr 26:cb71c4af2912 179
mjr 26:cb71c4af2912 180 // Configure SPI format and speed. Note that KL25Z ONLY supports 8-bit
mjr 26:cb71c4af2912 181 // mode. The TLC5940 nominally requires 12-bit data blocks for the
mjr 26:cb71c4af2912 182 // grayscale levels, but SPI is ultimately just a bit-level serial format,
mjr 26:cb71c4af2912 183 // so we can reformat the 12-bit blocks into 8-bit bytes to fit the
mjr 26:cb71c4af2912 184 // KL25Z's limits. This should work equally well on other microcontrollers
mjr 38:091e511ce8a0 185 // that are more flexible. The TLC5940 requires polarity/phase format 0.
mjr 26:cb71c4af2912 186 spi.format(8, 0);
mjr 26:cb71c4af2912 187 spi.frequency(SPI_SPEED);
mjr 33:d832bcab089e 188
mjr 33:d832bcab089e 189 // Send out a full data set to the chips, to clear out any random
mjr 33:d832bcab089e 190 // startup data from the registers. Include some extra bits - there
mjr 33:d832bcab089e 191 // are some cases (such as after sending dot correct commands) where
mjr 33:d832bcab089e 192 // an extra bit per chip is required, and the initial state is
mjr 33:d832bcab089e 193 // somewhat unpredictable, so send extra just to make sure we cover
mjr 33:d832bcab089e 194 // all bases. This does no harm; extra bits just fall off the end of
mjr 33:d832bcab089e 195 // the daisy chain, and since we want all registers set to 0, we can
mjr 33:d832bcab089e 196 // send arbitrarily many extra 0's.
mjr 33:d832bcab089e 197 for (int i = 0 ; i < nchips*25 ; ++i)
mjr 33:d832bcab089e 198 spi.write(0);
mjr 33:d832bcab089e 199
mjr 33:d832bcab089e 200 // do an initial XLAT to latch all of these "0" values into the
mjr 33:d832bcab089e 201 // grayscale registers
mjr 33:d832bcab089e 202 xlat = 1;
mjr 33:d832bcab089e 203 xlat = 0;
mjr 29:582472d0bc57 204
mjr 30:6e9902f06f48 205 // Allocate a DMA buffer. The transfer on each cycle is 192 bits per
mjr 30:6e9902f06f48 206 // chip = 24 bytes per chip.
mjr 30:6e9902f06f48 207 dmabuf = new char[nchips*24];
mjr 38:091e511ce8a0 208 memset(dmabuf, 0, nchips*24);
mjr 26:cb71c4af2912 209
mjr 30:6e9902f06f48 210 // Set up the Simple DMA interface object. We use the DMA controller to
mjr 30:6e9902f06f48 211 // send grayscale data updates to the TLC5940 chips. This lets the CPU
mjr 30:6e9902f06f48 212 // keep running other tasks while we send gs updates, and importantly
mjr 30:6e9902f06f48 213 // allows our blanking interrupt handler return almost immediately.
mjr 30:6e9902f06f48 214 // The DMA transfer is from our internal DMA buffer to SPI0, which is
mjr 30:6e9902f06f48 215 // the SPI controller physically connected to the TLC5940s.
mjr 38:091e511ce8a0 216 sdma.source(dmabuf, true, 8);
mjr 38:091e511ce8a0 217 sdma.destination(&(SPI0->D), false, 8);
mjr 30:6e9902f06f48 218 sdma.trigger(Trigger_SPI0_TX);
mjr 30:6e9902f06f48 219 sdma.attach(this, &TLC5940::dmaDone);
mjr 30:6e9902f06f48 220
mjr 30:6e9902f06f48 221 // Enable DMA on SPI0. SimpleDMA doesn't do this for us; we have to
mjr 30:6e9902f06f48 222 // do it explicitly. This is just a matter of setting bit 5 (TXDMAE)
mjr 38:091e511ce8a0 223 // in the SPI controller's Control Register 2 (C2).
mjr 30:6e9902f06f48 224 SPI0->C2 |= 0x20; // set bit 5 = 0x20 = TXDMAE in SPI0 control register 2
mjr 30:6e9902f06f48 225
mjr 30:6e9902f06f48 226 // Configure the GSCLK output's frequency
mjr 26:cb71c4af2912 227 gsclk.period(1.0/GSCLK_SPEED);
mjr 33:d832bcab089e 228
mjr 33:d832bcab089e 229 // mark that we need an initial update
mjr 33:d832bcab089e 230 newGSData = true;
mjr 33:d832bcab089e 231 needXlat = false;
mjr 30:6e9902f06f48 232 }
mjr 29:582472d0bc57 233
mjr 30:6e9902f06f48 234 // Start the clock running
mjr 29:582472d0bc57 235 void start()
mjr 29:582472d0bc57 236 {
mjr 26:cb71c4af2912 237 // Set up the first call to the reset function, which asserts BLANK to
mjr 26:cb71c4af2912 238 // end the PWM cycle and handles new grayscale data output and latching.
mjr 26:cb71c4af2912 239 // The original version of this library uses a timer to call reset
mjr 26:cb71c4af2912 240 // periodically, but that approach is somewhat problematic because the
mjr 26:cb71c4af2912 241 // reset function itself takes a small amount of time to run, so the
mjr 26:cb71c4af2912 242 // *actual* cycle is slightly longer than what we get from counting
mjr 26:cb71c4af2912 243 // GS clocks. Running reset on a timer therefore causes the calls to
mjr 26:cb71c4af2912 244 // slip out of phase with the actual full cycles, which causes
mjr 26:cb71c4af2912 245 // premature blanking that shows up as visible flicker. To get the
mjr 26:cb71c4af2912 246 // reset cycle to line up exactly with a full PWM cycle, it works
mjr 26:cb71c4af2912 247 // better to set up a new timer on each cycle, *after* we've finished
mjr 26:cb71c4af2912 248 // with the somewhat unpredictable overhead of the interrupt handler.
mjr 26:cb71c4af2912 249 // This ensures that we'll get much closer to exact alignment of the
mjr 26:cb71c4af2912 250 // cycle phase, and in any case the worst that happens is that some
mjr 26:cb71c4af2912 251 // cycles are very slightly too long or short (due to imperfections
mjr 26:cb71c4af2912 252 // in the timer clock vs the PWM clock that determines the GSCLCK
mjr 26:cb71c4af2912 253 // output to the TLC5940), which is far less noticeable than a
mjr 26:cb71c4af2912 254 // constantly rotating phase misalignment.
mjr 38:091e511ce8a0 255 resetTimer.attach(this, &TLC5940::reset, (1.0/GSCLK_SPEED)*4096.0);
mjr 26:cb71c4af2912 256 }
mjr 26:cb71c4af2912 257
mjr 26:cb71c4af2912 258 ~TLC5940()
mjr 26:cb71c4af2912 259 {
mjr 26:cb71c4af2912 260 delete [] gs;
mjr 30:6e9902f06f48 261 delete [] dmabuf;
mjr 26:cb71c4af2912 262 }
mjr 26:cb71c4af2912 263
mjr 26:cb71c4af2912 264 /**
mjr 26:cb71c4af2912 265 * Set the next chunk of grayscale data to be sent
mjr 26:cb71c4af2912 266 * @param data - Array of 16 bit shorts containing 16 12 bit grayscale data chunks per TLC5940
mjr 26:cb71c4af2912 267 * @note These must be in intervals of at least (1/GSCLK_SPEED) * 4096 to be sent
mjr 26:cb71c4af2912 268 */
mjr 26:cb71c4af2912 269 void set(int idx, unsigned short data)
mjr 26:cb71c4af2912 270 {
mjr 26:cb71c4af2912 271 // store the data, and flag the pending update for the interrupt handler to carry out
mjr 26:cb71c4af2912 272 gs[idx] = data;
mjr 30:6e9902f06f48 273 newGSData = true;
mjr 26:cb71c4af2912 274 }
mjr 26:cb71c4af2912 275
mjr 26:cb71c4af2912 276 private:
mjr 26:cb71c4af2912 277 // current level for each output
mjr 26:cb71c4af2912 278 unsigned short *gs;
mjr 26:cb71c4af2912 279
mjr 30:6e9902f06f48 280 // Simple DMA interface object
mjr 30:6e9902f06f48 281 SimpleDMA sdma;
mjr 30:6e9902f06f48 282
mjr 30:6e9902f06f48 283 // DMA transfer buffer. Each time we have data to transmit to the TLC5940 chips,
mjr 30:6e9902f06f48 284 // we format the data into this buffer exactly as it will go across the wire, then
mjr 30:6e9902f06f48 285 // hand the buffer to the DMA controller to move through the SPI port.
mjr 30:6e9902f06f48 286 char *dmabuf;
mjr 30:6e9902f06f48 287
mjr 26:cb71c4af2912 288 // SPI port - only MOSI and SCK are used
mjr 26:cb71c4af2912 289 SPI spi;
mjr 26:cb71c4af2912 290
mjr 26:cb71c4af2912 291 // use a PWM out for the grayscale clock - this provides a stable
mjr 26:cb71c4af2912 292 // square wave signal without consuming CPU
mjr 26:cb71c4af2912 293 FastPWM gsclk;
mjr 26:cb71c4af2912 294
mjr 26:cb71c4af2912 295 // Digital out pins used for the TLC5940
mjr 26:cb71c4af2912 296 DigitalOut blank;
mjr 26:cb71c4af2912 297 DigitalOut xlat;
mjr 26:cb71c4af2912 298
mjr 26:cb71c4af2912 299 // number of daisy-chained TLC5940s we're controlling
mjr 26:cb71c4af2912 300 int nchips;
mjr 26:cb71c4af2912 301
mjr 26:cb71c4af2912 302 // Timeout to end each PWM cycle. This is a one-shot timer that we reset
mjr 26:cb71c4af2912 303 // on each cycle.
mjr 38:091e511ce8a0 304 Timeout resetTimer;
mjr 26:cb71c4af2912 305
mjr 26:cb71c4af2912 306 // Has new GS/DC data been loaded?
mjr 26:cb71c4af2912 307 volatile bool newGSData;
mjr 33:d832bcab089e 308
mjr 33:d832bcab089e 309 // Do we need an XLAT signal on the next blanking interval?
mjr 33:d832bcab089e 310 volatile bool needXlat;
mjr 26:cb71c4af2912 311
mjr 26:cb71c4af2912 312 // Function to reset the display and send the next chunks of data
mjr 26:cb71c4af2912 313 void reset()
mjr 26:cb71c4af2912 314 {
mjr 30:6e9902f06f48 315 // start the blanking cycle
mjr 30:6e9902f06f48 316 startBlank();
mjr 33:d832bcab089e 317
mjr 33:d832bcab089e 318 #if DATA_UPDATE_INSIDE_BLANKING
mjr 33:d832bcab089e 319 // We're configured to send the new GS data entirely within
mjr 33:d832bcab089e 320 // the blanking interval. Start the DMA transfer now, and
mjr 33:d832bcab089e 321 // return without ending the blanking interval. The DMA
mjr 33:d832bcab089e 322 // completion interrupt handler will do that when the data
mjr 33:d832bcab089e 323 // update has completed.
mjr 33:d832bcab089e 324 //
mjr 33:d832bcab089e 325 // Note that we do the data update/ unconditionally in the
mjr 33:d832bcab089e 326 // send-during-blanking case, whether or not we have new GS
mjr 33:d832bcab089e 327 // data. This is because the update causes a 0.3% reduction
mjr 33:d832bcab089e 328 // in brightness because of the elongated BLANK interval.
mjr 33:d832bcab089e 329 // That would be visible as a flicker on each update if we
mjr 33:d832bcab089e 330 // did updates on some cycles and not others. By doing an
mjr 33:d832bcab089e 331 // update on every cycle, we make the brightness reduction
mjr 33:d832bcab089e 332 // uniform across time, which makes it less perceptible.
mjr 33:d832bcab089e 333 update();
mjr 38:091e511ce8a0 334 sdma.start(nchips*24);
mjr 38:091e511ce8a0 335
mjr 33:d832bcab089e 336
mjr 33:d832bcab089e 337 #else // DATA_UPDATE_INSIDE_BLANKING
mjr 33:d832bcab089e 338
mjr 33:d832bcab089e 339 // end the blanking interval
mjr 33:d832bcab089e 340 endBlank();
mjr 33:d832bcab089e 341
mjr 38:091e511ce8a0 342 // if we have pending grayscale data, update the DMA data
mjr 33:d832bcab089e 343 if (newGSData)
mjr 26:cb71c4af2912 344 update();
mjr 38:091e511ce8a0 345
mjr 38:091e511ce8a0 346 // send out the DMA contents
mjr 38:091e511ce8a0 347 sdma.start(nchips*24);
mjr 38:091e511ce8a0 348
mjr 26:cb71c4af2912 349
mjr 33:d832bcab089e 350 #endif // DATA_UPDATE_INSIDE_BLANKING
mjr 30:6e9902f06f48 351 }
mjr 30:6e9902f06f48 352
mjr 30:6e9902f06f48 353 void startBlank()
mjr 30:6e9902f06f48 354 {
mjr 30:6e9902f06f48 355 // turn off the grayscale clock, and assert BLANK to end the grayscale cycle
mjr 30:6e9902f06f48 356 gsclk.write(0);
mjr 30:6e9902f06f48 357 blank = 1;
mjr 30:6e9902f06f48 358 }
mjr 26:cb71c4af2912 359
mjr 33:d832bcab089e 360 void endBlank()
mjr 30:6e9902f06f48 361 {
mjr 33:d832bcab089e 362 // if we've sent new grayscale data since the last blanking
mjr 33:d832bcab089e 363 // interval, latch it by asserting XLAT
mjr 33:d832bcab089e 364 if (needXlat)
mjr 30:6e9902f06f48 365 {
mjr 26:cb71c4af2912 366 // latch the new data while we're still blanked
mjr 26:cb71c4af2912 367 xlat = 1;
mjr 26:cb71c4af2912 368 xlat = 0;
mjr 33:d832bcab089e 369 needXlat = false;
mjr 26:cb71c4af2912 370 }
mjr 26:cb71c4af2912 371
mjr 26:cb71c4af2912 372 // end the blanking interval and restart the grayscale clock
mjr 26:cb71c4af2912 373 blank = 0;
mjr 26:cb71c4af2912 374 gsclk.write(.5);
mjr 26:cb71c4af2912 375
mjr 26:cb71c4af2912 376 // set up the next blanking interrupt
mjr 38:091e511ce8a0 377 resetTimer.attach(this, &TLC5940::reset, (1.0/GSCLK_SPEED)*4096.0);
mjr 26:cb71c4af2912 378 }
mjr 26:cb71c4af2912 379
mjr 26:cb71c4af2912 380 void update()
mjr 26:cb71c4af2912 381 {
mjr 30:6e9902f06f48 382 // Send new grayscale data to the TLC5940 chips.
mjr 30:6e9902f06f48 383 //
mjr 30:6e9902f06f48 384 // To do this, we set up our DMA buffer with the bytes formatted exactly
mjr 30:6e9902f06f48 385 // as they will go across the wire, then kick off the transfer request with
mjr 30:6e9902f06f48 386 // the DMA controller. We can then return from the interrupt and continue
mjr 30:6e9902f06f48 387 // with other tasks while the DMA hardware handles the transfer for us.
mjr 30:6e9902f06f48 388 // When the transfer is completed, the DMA controller will fire an
mjr 30:6e9902f06f48 389 // interrupt, which will call our interrupt handler, which will finish
mjr 30:6e9902f06f48 390 // the blanking cycle.
mjr 30:6e9902f06f48 391 //
mjr 30:6e9902f06f48 392 // The serial format orders the outputs from last to first (output #15 on
mjr 30:6e9902f06f48 393 // the last chip in the daisy-chain to output #0 on the first chip). For
mjr 30:6e9902f06f48 394 // each output, we send 12 bits containing the grayscale level (0 = fully
mjr 30:6e9902f06f48 395 // off, 0xFFF = fully on). Bit order is most significant bit first.
mjr 26:cb71c4af2912 396 //
mjr 26:cb71c4af2912 397 // The KL25Z SPI can only send in 8-bit increments, so we need to divvy up
mjr 26:cb71c4af2912 398 // the 12-bit outputs into 8-bit bytes. Each pair of 12-bit outputs adds up
mjr 26:cb71c4af2912 399 // to 24 bits, which divides evenly into 3 bytes, so send each pairs of
mjr 26:cb71c4af2912 400 // outputs as three bytes:
mjr 26:cb71c4af2912 401 //
mjr 26:cb71c4af2912 402 // [ element i+1 bits ] [ element i bits ]
mjr 26:cb71c4af2912 403 // 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 404 // [ first byte ] [ second byte ] [ third byte ]
mjr 30:6e9902f06f48 405 for (int i = (16 * nchips) - 2, dst = 0 ; i >= 0 ; i -= 2)
mjr 26:cb71c4af2912 406 {
mjr 26:cb71c4af2912 407 // first byte - element i+1 bits 4-11
mjr 30:6e9902f06f48 408 dmabuf[dst++] = (((gs[i+1] & 0xFF0) >> 4) & 0xff);
mjr 26:cb71c4af2912 409
mjr 26:cb71c4af2912 410 // second byte - element i+1 bits 0-3, then element i bits 8-11
mjr 30:6e9902f06f48 411 dmabuf[dst++] = ((((gs[i+1] & 0x00F) << 4) | ((gs[i] & 0xF00) >> 8)) & 0xFF);
mjr 26:cb71c4af2912 412
mjr 26:cb71c4af2912 413 // third byte - element i bits 0-7
mjr 30:6e9902f06f48 414 dmabuf[dst++] = (gs[i] & 0x0FF);
mjr 26:cb71c4af2912 415 }
mjr 30:6e9902f06f48 416
mjr 33:d832bcab089e 417 // we've now cleared the new GS data
mjr 33:d832bcab089e 418 newGSData = false;
mjr 26:cb71c4af2912 419 }
mjr 30:6e9902f06f48 420
mjr 30:6e9902f06f48 421 // Interrupt handler for DMA completion. The DMA controller calls this
mjr 30:6e9902f06f48 422 // when it finishes with the transfer request we set up above. When the
mjr 30:6e9902f06f48 423 // transfer is done, we simply end the blanking cycle and start a new
mjr 30:6e9902f06f48 424 // grayscale cycle.
mjr 30:6e9902f06f48 425 void dmaDone()
mjr 30:6e9902f06f48 426 {
mjr 33:d832bcab089e 427 // mark that we need to assert XLAT to latch the new
mjr 33:d832bcab089e 428 // grayscale data during the next blanking interval
mjr 33:d832bcab089e 429 needXlat = true;
mjr 33:d832bcab089e 430
mjr 33:d832bcab089e 431 #if DATA_UPDATE_INSIDE_BLANKING
mjr 33:d832bcab089e 432 // we're doing the gs update within the blanking cycle, so end
mjr 33:d832bcab089e 433 // the blanking cycle now that the transfer has completed
mjr 33:d832bcab089e 434 endBlank();
mjr 33:d832bcab089e 435 #endif
mjr 30:6e9902f06f48 436 }
mjr 30:6e9902f06f48 437
mjr 26:cb71c4af2912 438 };
mjr 26:cb71c4af2912 439
mjr 26:cb71c4af2912 440 #endif