Arnaud VALLEY / Mbed 2 deprecated Pinscape_Controller_V2_arnoz

Important changes to repositories hosted on mbed.com

Mbed hosted mercurial repositories are deprecated and are due to be permanently deleted in July 2026.

To keep a copy of this software download the repository Zip archive or clone locally using Mercurial.

It is also possible to export all your personal repositories from the account settings page.

Dependencies:   mbed FastIO FastPWM USBDevice

TLC5940/TLC5940.h@39:b3815a1c3802, 2016-01-11 (annotated)

Committer:
mjr
Date:
Mon Jan 11 21:08:36 2016 +0000
Revision:
39:b3815a1c3802
Parent:
38:091e511ce8a0
Child:
40:cc0d9814522b
USB fixes; accelerometer auto un-sticking with watchdog timer.

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 26:cb71c4af2912 176 // Configure SPI format and speed. Note that KL25Z ONLY supports 8-bit
mjr 26:cb71c4af2912 177 // mode. The TLC5940 nominally requires 12-bit data blocks for the
mjr 26:cb71c4af2912 178 // grayscale levels, but SPI is ultimately just a bit-level serial format,
mjr 26:cb71c4af2912 179 // so we can reformat the 12-bit blocks into 8-bit bytes to fit the
mjr 26:cb71c4af2912 180 // KL25Z's limits. This should work equally well on other microcontrollers
mjr 38:091e511ce8a0 181 // that are more flexible. The TLC5940 requires polarity/phase format 0.
mjr 26:cb71c4af2912 182 spi.format(8, 0);
mjr 26:cb71c4af2912 183 spi.frequency(SPI_SPEED);
mjr 33:d832bcab089e 184
mjr 33:d832bcab089e 185 // Send out a full data set to the chips, to clear out any random
mjr 33:d832bcab089e 186 // startup data from the registers. Include some extra bits - there
mjr 33:d832bcab089e 187 // are some cases (such as after sending dot correct commands) where
mjr 33:d832bcab089e 188 // an extra bit per chip is required, and the initial state is
mjr 33:d832bcab089e 189 // somewhat unpredictable, so send extra just to make sure we cover
mjr 33:d832bcab089e 190 // all bases. This does no harm; extra bits just fall off the end of
mjr 33:d832bcab089e 191 // the daisy chain, and since we want all registers set to 0, we can
mjr 33:d832bcab089e 192 // send arbitrarily many extra 0's.
mjr 33:d832bcab089e 193 for (int i = 0 ; i < nchips*25 ; ++i)
mjr 33:d832bcab089e 194 spi.write(0);
mjr 33:d832bcab089e 195
mjr 33:d832bcab089e 196 // do an initial XLAT to latch all of these "0" values into the
mjr 33:d832bcab089e 197 // grayscale registers
mjr 33:d832bcab089e 198 xlat = 1;
mjr 33:d832bcab089e 199 xlat = 0;
mjr 29:582472d0bc57 200
mjr 39:b3815a1c3802 201 // Allocate our DMA buffers. The transfer on each cycle is 192 bits per
mjr 39:b3815a1c3802 202 // chip = 24 bytes per chip.
mjr 30:6e9902f06f48 203 dmabuf = new char[nchips*24];
mjr 38:091e511ce8a0 204 memset(dmabuf, 0, nchips*24);
mjr 26:cb71c4af2912 205
mjr 30:6e9902f06f48 206 // Set up the Simple DMA interface object. We use the DMA controller to
mjr 30:6e9902f06f48 207 // send grayscale data updates to the TLC5940 chips. This lets the CPU
mjr 30:6e9902f06f48 208 // keep running other tasks while we send gs updates, and importantly
mjr 30:6e9902f06f48 209 // allows our blanking interrupt handler return almost immediately.
mjr 30:6e9902f06f48 210 // The DMA transfer is from our internal DMA buffer to SPI0, which is
mjr 30:6e9902f06f48 211 // the SPI controller physically connected to the TLC5940s.
mjr 38:091e511ce8a0 212 sdma.source(dmabuf, true, 8);
mjr 38:091e511ce8a0 213 sdma.destination(&(SPI0->D), false, 8);
mjr 30:6e9902f06f48 214 sdma.trigger(Trigger_SPI0_TX);
mjr 30:6e9902f06f48 215 sdma.attach(this, &TLC5940::dmaDone);
mjr 30:6e9902f06f48 216
mjr 30:6e9902f06f48 217 // Enable DMA on SPI0. SimpleDMA doesn't do this for us; we have to
mjr 30:6e9902f06f48 218 // do it explicitly. This is just a matter of setting bit 5 (TXDMAE)
mjr 38:091e511ce8a0 219 // in the SPI controller's Control Register 2 (C2).
mjr 30:6e9902f06f48 220 SPI0->C2 |= 0x20; // set bit 5 = 0x20 = TXDMAE in SPI0 control register 2
mjr 30:6e9902f06f48 221
mjr 30:6e9902f06f48 222 // Configure the GSCLK output's frequency
mjr 26:cb71c4af2912 223 gsclk.period(1.0/GSCLK_SPEED);
mjr 33:d832bcab089e 224
mjr 33:d832bcab089e 225 // mark that we need an initial update
mjr 33:d832bcab089e 226 newGSData = true;
mjr 33:d832bcab089e 227 needXlat = false;
mjr 30:6e9902f06f48 228 }
mjr 29:582472d0bc57 229
mjr 30:6e9902f06f48 230 // Start the clock running
mjr 29:582472d0bc57 231 void start()
mjr 29:582472d0bc57 232 {
mjr 26:cb71c4af2912 233 // Set up the first call to the reset function, which asserts BLANK to
mjr 26:cb71c4af2912 234 // end the PWM cycle and handles new grayscale data output and latching.
mjr 26:cb71c4af2912 235 // The original version of this library uses a timer to call reset
mjr 26:cb71c4af2912 236 // periodically, but that approach is somewhat problematic because the
mjr 26:cb71c4af2912 237 // reset function itself takes a small amount of time to run, so the
mjr 26:cb71c4af2912 238 // *actual* cycle is slightly longer than what we get from counting
mjr 26:cb71c4af2912 239 // GS clocks. Running reset on a timer therefore causes the calls to
mjr 26:cb71c4af2912 240 // slip out of phase with the actual full cycles, which causes
mjr 26:cb71c4af2912 241 // premature blanking that shows up as visible flicker. To get the
mjr 26:cb71c4af2912 242 // reset cycle to line up exactly with a full PWM cycle, it works
mjr 26:cb71c4af2912 243 // better to set up a new timer on each cycle, *after* we've finished
mjr 26:cb71c4af2912 244 // with the somewhat unpredictable overhead of the interrupt handler.
mjr 26:cb71c4af2912 245 // This ensures that we'll get much closer to exact alignment of the
mjr 26:cb71c4af2912 246 // cycle phase, and in any case the worst that happens is that some
mjr 26:cb71c4af2912 247 // cycles are very slightly too long or short (due to imperfections
mjr 26:cb71c4af2912 248 // in the timer clock vs the PWM clock that determines the GSCLCK
mjr 26:cb71c4af2912 249 // output to the TLC5940), which is far less noticeable than a
mjr 26:cb71c4af2912 250 // constantly rotating phase misalignment.
mjr 38:091e511ce8a0 251 resetTimer.attach(this, &TLC5940::reset, (1.0/GSCLK_SPEED)*4096.0);
mjr 26:cb71c4af2912 252 }
mjr 26:cb71c4af2912 253
mjr 26:cb71c4af2912 254 ~TLC5940()
mjr 26:cb71c4af2912 255 {
mjr 30:6e9902f06f48 256 delete [] dmabuf;
mjr 26:cb71c4af2912 257 }
mjr 26:cb71c4af2912 258
mjr 39:b3815a1c3802 259 /*
mjr 39:b3815a1c3802 260 * Set an output
mjr 26:cb71c4af2912 261 */
mjr 26:cb71c4af2912 262 void set(int idx, unsigned short data)
mjr 26:cb71c4af2912 263 {
mjr 39:b3815a1c3802 264 // validate the index
mjr 39:b3815a1c3802 265 if (idx >= 0 && idx < nchips*16)
mjr 39:b3815a1c3802 266 {
mjr 39:b3815a1c3802 267 // Figure the DMA buffer location of the data. The DMA buffer has the
mjr 39:b3815a1c3802 268 // packed bit format that we send across the wire, with 12 bits per output,
mjr 39:b3815a1c3802 269 // arranged from last output to first output (N = number of outputs = nchips*16):
mjr 39:b3815a1c3802 270 //
mjr 39:b3815a1c3802 271 // byte 0 = high 8 bits of output N-1
mjr 39:b3815a1c3802 272 // 1 = low 4 bits of output N-1 | high 4 bits of output N-2
mjr 39:b3815a1c3802 273 // 2 = low 8 bits of N-2
mjr 39:b3815a1c3802 274 // 3 = high 8 bits of N-3
mjr 39:b3815a1c3802 275 // 4 = low 4 bits of N-3 | high 4 bits of N-2
mjr 39:b3815a1c3802 276 // 5 = low 8bits of N-4
mjr 39:b3815a1c3802 277 // ...
mjr 39:b3815a1c3802 278 // 24*nchips-3 = high 8 bits of output 1
mjr 39:b3815a1c3802 279 // 24*nchips-2 = low 4 bits of output 1 | high 4 bits of output 0
mjr 39:b3815a1c3802 280 // 24*nchips-1 = low 8 bits of output 0
mjr 39:b3815a1c3802 281 //
mjr 39:b3815a1c3802 282 // So this update will affect two bytes. If the output number if even, we're
mjr 39:b3815a1c3802 283 // in the high 4 + low 8 pair; if odd, we're in the high 8 + low 4 pair.
mjr 39:b3815a1c3802 284 int di = nchips*24 - 3 - (3*(idx/2));
mjr 39:b3815a1c3802 285 if (idx & 1)
mjr 39:b3815a1c3802 286 {
mjr 39:b3815a1c3802 287 //printf("out %d = %d -> updating dma[%d] odd (xx x. ..)\r\n", idx, data, di);
mjr 39:b3815a1c3802 288 // ODD = high 8 | low 4
mjr 39:b3815a1c3802 289 dmabuf[di] = uint8_t((data >> 4) & 0xff);
mjr 39:b3815a1c3802 290 dmabuf[di+1] &= 0x0F;
mjr 39:b3815a1c3802 291 dmabuf[di+1] |= uint8_t((data << 4) & 0xf0);
mjr 39:b3815a1c3802 292 }
mjr 39:b3815a1c3802 293 else
mjr 39:b3815a1c3802 294 {
mjr 39:b3815a1c3802 295 // EVEN = high 4 | low 8
mjr 39:b3815a1c3802 296 //printf("out %d = %d -> updating dma[%d] even (.. .x xx)\r\n", idx, data, di);
mjr 39:b3815a1c3802 297 dmabuf[di+1] &= 0xF0;
mjr 39:b3815a1c3802 298 dmabuf[di+1] |= uint8_t((data >> 8) & 0x0f);
mjr 39:b3815a1c3802 299 dmabuf[di+2] = uint8_t(data & 0xff);
mjr 39:b3815a1c3802 300 }
mjr 39:b3815a1c3802 301
mjr 39:b3815a1c3802 302 // note the update
mjr 39:b3815a1c3802 303 newGSData = true;
mjr 39:b3815a1c3802 304 }
mjr 26:cb71c4af2912 305 }
mjr 26:cb71c4af2912 306
mjr 26:cb71c4af2912 307 private:
mjr 26:cb71c4af2912 308 // current level for each output
mjr 26:cb71c4af2912 309 unsigned short *gs;
mjr 26:cb71c4af2912 310
mjr 30:6e9902f06f48 311 // Simple DMA interface object
mjr 30:6e9902f06f48 312 SimpleDMA sdma;
mjr 30:6e9902f06f48 313
mjr 30:6e9902f06f48 314 // DMA transfer buffer. Each time we have data to transmit to the TLC5940 chips,
mjr 30:6e9902f06f48 315 // we format the data into this buffer exactly as it will go across the wire, then
mjr 30:6e9902f06f48 316 // hand the buffer to the DMA controller to move through the SPI port.
mjr 30:6e9902f06f48 317 char *dmabuf;
mjr 30:6e9902f06f48 318
mjr 26:cb71c4af2912 319 // SPI port - only MOSI and SCK are used
mjr 26:cb71c4af2912 320 SPI spi;
mjr 26:cb71c4af2912 321
mjr 26:cb71c4af2912 322 // use a PWM out for the grayscale clock - this provides a stable
mjr 26:cb71c4af2912 323 // square wave signal without consuming CPU
mjr 26:cb71c4af2912 324 FastPWM gsclk;
mjr 26:cb71c4af2912 325
mjr 26:cb71c4af2912 326 // Digital out pins used for the TLC5940
mjr 26:cb71c4af2912 327 DigitalOut blank;
mjr 26:cb71c4af2912 328 DigitalOut xlat;
mjr 26:cb71c4af2912 329
mjr 26:cb71c4af2912 330 // number of daisy-chained TLC5940s we're controlling
mjr 26:cb71c4af2912 331 int nchips;
mjr 26:cb71c4af2912 332
mjr 26:cb71c4af2912 333 // Timeout to end each PWM cycle. This is a one-shot timer that we reset
mjr 26:cb71c4af2912 334 // on each cycle.
mjr 38:091e511ce8a0 335 Timeout resetTimer;
mjr 26:cb71c4af2912 336
mjr 26:cb71c4af2912 337 // Has new GS/DC data been loaded?
mjr 26:cb71c4af2912 338 volatile bool newGSData;
mjr 33:d832bcab089e 339
mjr 33:d832bcab089e 340 // Do we need an XLAT signal on the next blanking interval?
mjr 33:d832bcab089e 341 volatile bool needXlat;
mjr 26:cb71c4af2912 342
mjr 26:cb71c4af2912 343 // Function to reset the display and send the next chunks of data
mjr 26:cb71c4af2912 344 void reset()
mjr 26:cb71c4af2912 345 {
mjr 30:6e9902f06f48 346 // start the blanking cycle
mjr 30:6e9902f06f48 347 startBlank();
mjr 33:d832bcab089e 348
mjr 33:d832bcab089e 349 #if DATA_UPDATE_INSIDE_BLANKING
mjr 33:d832bcab089e 350 // We're configured to send the new GS data entirely within
mjr 33:d832bcab089e 351 // the blanking interval. Start the DMA transfer now, and
mjr 33:d832bcab089e 352 // return without ending the blanking interval. The DMA
mjr 33:d832bcab089e 353 // completion interrupt handler will do that when the data
mjr 33:d832bcab089e 354 // update has completed.
mjr 33:d832bcab089e 355 //
mjr 33:d832bcab089e 356 // Note that we do the data update/ unconditionally in the
mjr 33:d832bcab089e 357 // send-during-blanking case, whether or not we have new GS
mjr 33:d832bcab089e 358 // data. This is because the update causes a 0.3% reduction
mjr 33:d832bcab089e 359 // in brightness because of the elongated BLANK interval.
mjr 33:d832bcab089e 360 // That would be visible as a flicker on each update if we
mjr 33:d832bcab089e 361 // did updates on some cycles and not others. By doing an
mjr 33:d832bcab089e 362 // update on every cycle, we make the brightness reduction
mjr 33:d832bcab089e 363 // uniform across time, which makes it less perceptible.
mjr 38:091e511ce8a0 364 sdma.start(nchips*24);
mjr 33:d832bcab089e 365
mjr 33:d832bcab089e 366 #else // DATA_UPDATE_INSIDE_BLANKING
mjr 33:d832bcab089e 367
mjr 33:d832bcab089e 368 // end the blanking interval
mjr 33:d832bcab089e 369 endBlank();
mjr 33:d832bcab089e 370
mjr 38:091e511ce8a0 371 // if we have pending grayscale data, update the DMA data
mjr 39:b3815a1c3802 372 // if (newGSData)
mjr 39:b3815a1c3802 373 {
mjr 39:b3815a1c3802 374 // send out the DMA contents
mjr 39:b3815a1c3802 375 sdma.start(nchips*24);
mjr 39:b3815a1c3802 376
mjr 39:b3815a1c3802 377 // we don't have to send again until the next gs data cahnge
mjr 39:b3815a1c3802 378 newGSData = false;
mjr 39:b3815a1c3802 379 }
mjr 26:cb71c4af2912 380
mjr 33:d832bcab089e 381 #endif // DATA_UPDATE_INSIDE_BLANKING
mjr 30:6e9902f06f48 382 }
mjr 30:6e9902f06f48 383
mjr 30:6e9902f06f48 384 void startBlank()
mjr 30:6e9902f06f48 385 {
mjr 30:6e9902f06f48 386 // turn off the grayscale clock, and assert BLANK to end the grayscale cycle
mjr 30:6e9902f06f48 387 gsclk.write(0);
mjr 30:6e9902f06f48 388 blank = 1;
mjr 30:6e9902f06f48 389 }
mjr 26:cb71c4af2912 390
mjr 33:d832bcab089e 391 void endBlank()
mjr 30:6e9902f06f48 392 {
mjr 33:d832bcab089e 393 // if we've sent new grayscale data since the last blanking
mjr 33:d832bcab089e 394 // interval, latch it by asserting XLAT
mjr 33:d832bcab089e 395 if (needXlat)
mjr 30:6e9902f06f48 396 {
mjr 26:cb71c4af2912 397 // latch the new data while we're still blanked
mjr 26:cb71c4af2912 398 xlat = 1;
mjr 26:cb71c4af2912 399 xlat = 0;
mjr 33:d832bcab089e 400 needXlat = false;
mjr 26:cb71c4af2912 401 }
mjr 26:cb71c4af2912 402
mjr 26:cb71c4af2912 403 // end the blanking interval and restart the grayscale clock
mjr 26:cb71c4af2912 404 blank = 0;
mjr 26:cb71c4af2912 405 gsclk.write(.5);
mjr 26:cb71c4af2912 406
mjr 26:cb71c4af2912 407 // set up the next blanking interrupt
mjr 38:091e511ce8a0 408 resetTimer.attach(this, &TLC5940::reset, (1.0/GSCLK_SPEED)*4096.0);
mjr 26:cb71c4af2912 409 }
mjr 26:cb71c4af2912 410
mjr 30:6e9902f06f48 411 // Interrupt handler for DMA completion. The DMA controller calls this
mjr 30:6e9902f06f48 412 // when it finishes with the transfer request we set up above. When the
mjr 30:6e9902f06f48 413 // transfer is done, we simply end the blanking cycle and start a new
mjr 30:6e9902f06f48 414 // grayscale cycle.
mjr 30:6e9902f06f48 415 void dmaDone()
mjr 30:6e9902f06f48 416 {
mjr 33:d832bcab089e 417 // mark that we need to assert XLAT to latch the new
mjr 33:d832bcab089e 418 // grayscale data during the next blanking interval
mjr 33:d832bcab089e 419 needXlat = true;
mjr 33:d832bcab089e 420
mjr 33:d832bcab089e 421 #if DATA_UPDATE_INSIDE_BLANKING
mjr 33:d832bcab089e 422 // we're doing the gs update within the blanking cycle, so end
mjr 33:d832bcab089e 423 // the blanking cycle now that the transfer has completed
mjr 33:d832bcab089e 424 endBlank();
mjr 33:d832bcab089e 425 #endif
mjr 30:6e9902f06f48 426 }
mjr 30:6e9902f06f48 427
mjr 26:cb71c4af2912 428 };
mjr 26:cb71c4af2912 429
mjr 26:cb71c4af2912 430 #endif