Mike R
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
Revision 29:582472d0bc57, committed 2015-09-25
- Comitter:
- mjr
- Date:
- Fri Sep 25 18:49:53 2015 +0000
- Parent:
- 28:2097c6f8f2db
- Child:
- 30:6e9902f06f48
- Commit message:
- Test of direct bit writes instead of SPI.
Changed in this revision
--- a/FastIO.lib Wed Sep 23 05:38:27 2015 +0000 +++ b/FastIO.lib Fri Sep 25 18:49:53 2015 +0000 @@ -1,1 +1,1 @@ -http://developer.mbed.org/users/Sissors/code/FastIO/#327ae1d5fecb +http://developer.mbed.org/users/Sissors/code/FastIO/#199aca52ac42
--- a/TLC5940/TLC5940.h Wed Sep 23 05:38:27 2015 +0000
+++ b/TLC5940/TLC5940.h Fri Sep 25 18:49:53 2015 +0000
@@ -48,6 +48,7 @@
* isn't a factor. E.g., at SPI=30MHz and GSCLK=500kHz,
* t(blank) is 8192us and t(refresh) is 25us.
*/
+#define USE_SPI 1
#define SPI_SPEED 3000000
/**
@@ -111,7 +112,11 @@
* @param nchips - The number of TLC5940s (if you are daisy chaining)
*/
TLC5940(PinName SCLK, PinName MOSI, PinName GSCLK, PinName BLANK, PinName XLAT, int nchips)
+#if USE_SPI
: spi(MOSI, NC, SCLK),
+#else
+ : sin(MOSI), sclk(SCLK),
+#endif
gsclk(GSCLK),
blank(BLANK),
xlat(XLAT),
@@ -122,6 +127,7 @@
gs = new unsigned short[nchips*16];
memset(gs, 0, nchips*16*sizeof(gs[0]));
+#if USE_SPI
// Configure SPI format and speed. Note that KL25Z ONLY supports 8-bit
// mode. The TLC5940 nominally requires 12-bit data blocks for the
// grayscale levels, but SPI is ultimately just a bit-level serial format,
@@ -131,7 +137,10 @@
// format 0.
spi.format(8, 0);
spi.frequency(SPI_SPEED);
-
+#else
+ sclk = 1;
+#endif
+
// Set output pin states
xlat = 0;
blank = 1;
@@ -140,7 +149,11 @@
gsclk.period(1.0/GSCLK_SPEED);
gsclk.write(.5);
blank = 0;
-
+ }
+
+ // start the clock running
+ void start()
+ {
// Set up the first call to the reset function, which asserts BLANK to
// end the PWM cycle and handles new grayscale data output and latching.
// The original version of this library uses a timer to call reset
@@ -176,15 +189,20 @@
{
// store the data, and flag the pending update for the interrupt handler to carry out
gs[idx] = data;
- newGSData = true;
+// newGSData = true;
}
private:
// current level for each output
unsigned short *gs;
+#if USE_SPI
// SPI port - only MOSI and SCK are used
SPI spi;
+#else
+ DigitalOut sin;
+ DigitalOut sclk;
+#endif
// use a PWM out for the grayscale clock - this provides a stable
// square wave signal without consuming CPU
@@ -212,7 +230,7 @@
blank = 1;
// If we have new GS data, send it now
- if (newGSData)
+ if (true) // (newGSData)
{
// Send the new grayscale data.
//
@@ -267,6 +285,7 @@
void update()
{
+#if USE_SPI
// Send GS data. The serial format orders the outputs from last to first
// (output #15 on the last chip in the daisy-chain to output #0 on the
// first chip). For each output, we send 12 bits containing the grayscale
@@ -281,7 +300,7 @@
// [ element i+1 bits ] [ element i bits ]
// 11 10 9 8 7 6 5 4 3 2 1 0 11 10 9 8 7 6 5 4 3 2 1 0
// [ first byte ] [ second byte ] [ third byte ]
- for (int i = (16 * nchips) - 2 ; i >= 0 ; i -= 2)
+ for (int i = 61 /* (16 * nchips) - 2 */ ; i >= 0 ; i -= 2)
{
// first byte - element i+1 bits 4-11
spi.write(((gs[i+1] & 0xFF0) >> 4) & 0xff);
@@ -292,6 +311,20 @@
// third byte - element i bits 0-7
spi.write(gs[i] & 0x0FF);
}
+#else
+ // Send GS data, from last output to first output, 12 bits per output,
+ // most significant bit first.
+ for (int i = 16*3 - 1 ; i >= 0 ; --i)
+ {
+ unsigned data = gs[i];
+ for (unsigned int mask = 1 << 11, bit = 0 ; bit < 12 ; ++bit, mask >>= 1)
+ {
+ sclk = 0;
+ sin = (data & mask) ? 1 : 0;
+ sclk = 1;
+ }
+ }
+#endif
}
};
--- a/USBJoystick/USBJoystick.cpp Wed Sep 23 05:38:27 2015 +0000
+++ b/USBJoystick/USBJoystick.cpp Fri Sep 25 18:49:53 2015 +0000
@@ -150,30 +150,8 @@
{
USAGE_PAGE(1), 0x01, // Generic desktop
USAGE(1), 0x04, // Joystick
-
COLLECTION(1), 0x01, // Application
- // NB - the canonical joystick has a nested collection at this
- // point. We remove the inner collection to enable the LedWiz
- // emulation. The LedWiz API implementation on the PC side
- // appears to use the collection structure as part of the
- // device signature, and the real LedWiz descriptor has just
- // one top-level collection. The built-in Windows HID drivers
- // don't appear to care whether this collection is present or
- // not for the purposes of recognizing a joystick, so it seems
- // to make everyone happy to leave it out.
- //
- // All of the reference material for USB joystick device builders
- // does use the inner collection, so it's possible that omitting
- // it will create an incompatibility with some non-Windows hosts.
- // But that seems largely moot in that VP only runs on Windows.
- // If you're you're trying to adapt this code for a different
- // device and run into problems connecting to a non-Windows host,
- // try restoring the inner collection. You probably won't
- // care about LedWiz compatibility in such a situation so there
- // should be no reason not to return to the standard structure.
- // COLLECTION(1), 0x00, // Physical
-
// input report (device to host)
USAGE_PAGE(1), 0x06, // generic device controls - for config status
@@ -207,12 +185,12 @@
// output report (host to device)
REPORT_SIZE(1), 0x08, // 8 bits per report
- REPORT_COUNT(1), 0x08, // output report count (LEDWiz messages)
+ REPORT_COUNT(1), 0x08, // output report count - 8-byte LedWiz format
0x09, 0x01, // usage
0x91, 0x01, // Output (array)
- // END_COLLECTION(0),
END_COLLECTION(0)
+
};
#else /* defined(ENABLE_JOYSTICK) */
--- a/USBJoystick/USBJoystick.h Wed Sep 23 05:38:27 2015 +0000
+++ b/USBJoystick/USBJoystick.h Fri Sep 25 18:49:53 2015 +0000
@@ -91,7 +91,7 @@
* @param product_release Your product_release (default: 0x0001)
*/
USBJoystick(uint16_t vendor_id = 0x1234, uint16_t product_id = 0x0100, uint16_t product_release = 0x0001, int waitForConnect = true):
- USBHID(16, 8, vendor_id, product_id, product_release, false)
+ USBHID(16, 64, vendor_id, product_id, product_release, false)
{
_init();
connect(waitForConnect);
--- a/config.h Wed Sep 23 05:38:27 2015 +0000
+++ b/config.h Fri Sep 25 18:49:53 2015 +0000
@@ -74,13 +74,15 @@
//
// The reason we start at unit #8 is that we want to avoid conflicting with
// any real LedWiz devices you have in your system. If you have a real
-// LedWiz, it's probably unit #1, since that's the standard factor setting.
-// If you have two real LedWiz's, they're probably units #1 and #2. If you
-// have three... well, I don't think anyone actually has three, but if you
-// did it would probably be unit #3. And so on. That's why we start at #8 -
-// it seems really unlikely that this will conflict with anybody's existing
-// setup. On the off chance it does, simply change the setting here to a
-// different unit number that's not already used in your system.
+// LedWiz, it's probably unit #1, since that's the default factory setting
+// that they'll give you if you didn't specifically ask for something else
+// when you ordered it. If you have two real LedWiz's, they're probably
+// units #1 and #2. If you have three... well, I don't think anyone
+// actually has three, but if you did it would probably be unit #3. And so
+// on. That's why we start at #8: it seems really unlikely that anyone
+// with a pin cab has a real LedWiz unit #8. On the off chance that you
+// do, simply change the setting here to a different unit number that's not
+// already used in your system.
//
// Note 1: the unit number here is the *user visible* unit number that
// you use on the PC side. It's the number you specify in your DOF
@@ -90,67 +92,22 @@
// are all off by one from the unit number you select here, that's why.
//
// Note 2: the DOF Configtool (google it) knows about the Pinscape
-// controller (it's known there as just a "KL25Z" rather than Pinscape).
-// And the DOF tool knows that it uses #8 as its default unit number, so
-// it names the .ini file for this controller xxx8.ini. If you change the
-// unit number here, remember to rename the DOF-generated .ini file to
-// match, by changing the "8" at the end of the filename to the new number
-// you set here.
+// controller. There it's referred to as simply "KL25Z" rather than
+// Pinscape Controller, but that's what they're talking about. The DOF
+// tool knows that it uses #8 as its default unit number, so it names the
+// .ini file for this controller xxx8.ini. If you change the unit number
+// here, remember to rename the DOF-generated .ini file to match, by
+// changing the "8" at the end of the filename to the new number you set
+// here.
const uint8_t DEFAULT_LEDWIZ_UNIT_NUMBER =
#ifdef ENABLE_JOYSTICK
- 0x08; // joystick enabled - assume we're the primary KL25Z, so use unit #8
+ 0x01; // joystick enabled - assume we're the primary KL25Z, so use unit #8
#else
0x09; // joystick disabled - assume we're a secondary, output-only KL25Z, so use #9
#endif
// --------------------------------------------------------------------------
//
-// TLC5940 PWM controller chip setup - Enhanced LedWiz emulation
-//
-// By default, the Pinscape Controller software can provide limited LedWiz
-// emulation through the KL25Z's on-board GPIO ports. This lets you hook
-// up external devices, such as LED flashers or solenoids, to the KL25Z
-// outputs (using external circuitry to boost power - KL25Z GPIO ports
-// are limited to a meager 4mA per port). This capability is limited by
-// the number of available GPIO ports on the KL25Z, and even smaller limit
-// of 10 PWM-capable GPIO ports.
-//
-// As an alternative, the controller software lets you use external PWM
-// controller chips to control essentially unlimited channels with full
-// PWM control on all channels. This requires building external circuitry
-// using TLC5940 chips. Each TLC5940 chip provides 16 full PWM channels,
-// and you can daisy-chain multiple TLC5940 chips together to set up 32,
-// 48, 64, or more channels.
-//
-// If you do add TLC5940 circuits to your controller hardware, use this
-// section to configure the connection to the KL25Z.
-//
-// Note that if you're using TLC5940 outputs, ALL of the outputs must go
-// through the TLC5940s - you can't mix TLC5940s and the default GPIO
-// device outputs. This lets us take GPIO ports that we'd normally use
-// for device outputs and reassign them to control the TLC5940 hardware.
-
-// Uncomment this line if using TLC5940 chips
-//#define ENABLE_TLC5940
-
-// Number of TLC5940 chips you're using. For a full LedWiz-compatible
-// setup, you need two of these chips, for 32 outputs.
-#define TLC5940_NCHIPS 2
-
-// If you're using TLC5940s, change any of these as needed to match the
-// GPIO pins that you connected to the TLC5940 control pins. Note that
-// SIN and SCLK *must* be connected to the KL25Z SPI0 MOSI and SCLK
-// outputs, respectively, which effectively limits them to the default
-// selections, and that the GSCLK pin must be PWM-capable.
-#define TLC5940_SIN PTC6 // Must connect to SPI0 MOSI -> PTC6 or PTD2
-#define TLC5940_SCLK PTC5 // Must connect to SPI0 SCLK -> PTC5 or PTD1; however, PTD1 isn't
- // recommended because it's hard-wired to the on-board blue LED
-#define TLC5940_XLAT PTC10 // Any GPIO pin can be used
-#define TLC5940_BLANK PTC0 // Any GPIO pin can be used
-#define TLC5940_GSCLK PTD4 // Must be a PWM-capable pin
-
-// --------------------------------------------------------------------------
-//
// Plunger CCD sensor.
//
// If you're NOT using the CCD sensor, comment out the next line (by adding
@@ -344,10 +301,59 @@
// push mode.
const float LaunchBallPushDistance = .08;
-#endif // CONFIG_H
+
+// --------------------------------------------------------------------------
+//
+// TLC5940 PWM controller chip setup - Enhanced LedWiz emulation
+//
+// By default, the Pinscape Controller software can provide limited LedWiz
+// emulation through the KL25Z's on-board GPIO ports. This lets you hook
+// up external devices, such as LED flashers or solenoids, to the KL25Z
+// outputs (using external circuitry to boost power - KL25Z GPIO ports
+// are limited to a meager 4mA per port). This capability is limited by
+// the number of available GPIO ports on the KL25Z, and even smaller limit
+// of 10 PWM-capable GPIO ports.
+//
+// As an alternative, the controller software lets you use external PWM
+// controller chips to control essentially unlimited channels with full
+// PWM control on all channels. This requires building external circuitry
+// using TLC5940 chips. Each TLC5940 chip provides 16 full PWM channels,
+// and you can daisy-chain multiple TLC5940 chips together to set up 32,
+// 48, 64, or more channels.
+//
+// If you do add TLC5940 circuits to your controller hardware, use this
+// section to configure the connection to the KL25Z.
+//
+// Note that if you're using TLC5940 outputs, ALL of the outputs must go
+// through the TLC5940s - you can't mix TLC5940s and the default GPIO
+// device outputs. This lets us take GPIO ports that we'd normally use
+// for device outputs and reassign them to control the TLC5940 hardware.
+
+// Uncomment this line if using TLC5940 chips
+#define ENABLE_TLC5940
+
+// Number of TLC5940 chips you're using. For a full LedWiz-compatible
+// setup, you need two of these chips, for 32 outputs.
+#define TLC5940_NCHIPS 4
+
+// If you're using TLC5940s, change any of these as needed to match the
+// GPIO pins that you connected to the TLC5940 control pins. Note that
+// SIN and SCLK *must* be connected to the KL25Z SPI0 MOSI and SCLK
+// outputs, respectively, which effectively limits them to the default
+// selections, and that the GSCLK pin must be PWM-capable.
+#define TLC5940_SIN PTC6 // Must connect to SPI0 MOSI -> PTC6 or PTD2
+#define TLC5940_SCLK PTC5 // Must connect to SPI0 SCLK -> PTC5 or PTD1; however, PTD1 isn't
+ // recommended because it's hard-wired to the on-board blue LED
+#define TLC5940_XLAT PTC10 // Any GPIO pin can be used
+#define TLC5940_BLANK PTC0 // Any GPIO pin can be used
+#define TLC5940_GSCLK PTD4 // Must be a PWM-capable pin
-#ifdef DECL_EXTERNS
+#endif // CONFIG_H - end of include-once section (code below this point can be multiply included)
+
+
+#ifdef DECL_EXTERNS // this section defines global variables, only if this macro is set
+
// --------------------------------------------------------------------------
//
@@ -421,7 +427,7 @@
// --------------------------------------------------------------------------
//
-// LED-Wiz emulation output pin assignments.
+// LED-Wiz emulation output pin assignments - GPIO mode
//
// NOTE! This section isn't used if you have TLC5940 outputs - ALL
// device outputs will be through the 5940s if you're using them.
--- a/main.cpp Wed Sep 23 05:38:27 2015 +0000
+++ b/main.cpp Fri Sep 25 18:49:53 2015 +0000
@@ -337,7 +337,7 @@
// ---------------------------------------------------------------------------
//
-// LedWiz emulation
+// LedWiz emulation, and enhanced TLC5940 output controller
//
// There are two modes for this feature. The default mode uses the on-board
// GPIO ports to implement device outputs - each LedWiz software port is
@@ -357,6 +357,17 @@
// for 32 outputs). Every port in this mode has full PWM support.
//
+// Figure the number of outputs. If we're in the default LedWiz mode,
+// we have a fixed set of 32 outputs. If we're in TLC5940 enhanced mode,
+// we have 16 outputs per chip. To simplify the LedWiz compatibility code,
+// always use a minimum of 32 outputs even if we have fewer than two of the
+// TLC5940 chips.
+#if !defined(ENABLE_TLC5940) || (TLC_NCHIPS) < 2
+# define NUM_OUTPUTS 32
+#else
+# define NUM_OUTPUTS ((TLC5940_NCHIPS)*16)
+#endif
+
// Current starting output index for "PBA" messages from the PC (using
// the LedWiz USB protocol). Each PBA message implicitly uses the
// current index as the starting point for the ports referenced in
@@ -393,7 +404,7 @@
virtual void set(float val)
{
if (val != prv)
- tlc5940.set(idx, (int)(val * 4095));
+ tlc5940.set(idx, (int)(val * 4095));
}
int idx;
float prv;
@@ -454,12 +465,14 @@
virtual void set(float val) { }
};
-// Array of output assignments. This array is indexed by the LedWiz
-// output port number; that protocol is hardwired for 32 ports, so we
-// need 32 elements in the array. Each element is an LwOut object
-// that provides the mapping to the physical output corresponding to
-// the software port.
-static LwOut *lwPin[32];
+// Array of output physical pin assignments. This array is indexed
+// by LedWiz logical port number - lwPin[n] is the maping for LedWiz
+// port n (0-based). If we're using GPIO ports to implement outputs,
+// we initialize the array at start-up to map each logical port to the
+// physical GPIO pin for the port specified in the ledWizPortMap[]
+// array in config.h. If we're using TLC5940 chips for the outputs,
+// we map each logical port to the corresponding TLC5940 output.
+static LwOut *lwPin[NUM_OUTPUTS];
// initialize the output pin array
void initLwOut()
@@ -470,14 +483,16 @@
// Set up a TLC5940 output. If the output is within range of
// the connected number of chips (16 outputs per chip), assign it
// to the current index, otherwise leave it unattached.
- if (i < TLC5940_NCHIPS*16)
+ if (i < (TLC5940_NCHIPS)*16)
lwPin[i] = new Lw5940Out(i);
else
lwPin[i] = new LwUnusedOut();
#else // ENABLE_TLC5940
- // Set up the GPIO pin, according to whether it's PWM-capable or
- // digital-only, and whether or not it's assigned at all.
+ // Set up the GPIO pin. If the pin is not connected ("NC" in the
+ // pin map), set up a dummy "unused" output for it. If it's a
+ // real pin, set up a PWM-capable or Digital-Only output handler
+ // object, according to the pin type in the map.
PinName p = (i < countof(ledWizPortMap) ? ledWizPortMap[i].pin : NC);
if (p == NC)
lwPin[i] = new LwUnusedOut();
@@ -491,10 +506,44 @@
}
}
+// Current absolute brightness level for an output. This is a float
+// value from 0.0 for fully off to 1.0 for fully on. This is the final
+// derived value for the port. For outputs set by LedWiz messages,
+// this is derived from te LedWiz state, and is updated on each pulse
+// timer interrupt for lights in flashing states. For outputs set by
+// extended protocol messages, this is simply the brightness last set.
+static float outLevel[NUM_OUTPUTS];
+
+// LedWiz output states.
+//
+// The LedWiz protocol has two separate control axes for each output.
+// One axis is its on/off state; the other is its "profile" state, which
+// is either a fixed brightness or a blinking pattern for the light.
+// The two axes are independent.
+//
+// Note that the LedWiz protocol can only address 32 outputs, so the
+// wizOn and wizVal arrays have fixed sizes of 32 elements no matter
+// how many physical outputs we're using.
+
// on/off state for each LedWiz output
static uint8_t wizOn[32];
-// profile (brightness/blink) state for each LedWiz output
+// Profile (brightness/blink) state for each LedWiz output. If the
+// output was last updated through an LedWiz protocol message, it
+// will have one of these values:
+//
+// 0-48 = fixed brightness 0% to 100%
+// 129 = ramp up / ramp down
+// 130 = flash on / off
+// 131 = on / ramp down
+// 132 = ramp up / on
+//
+// Special value 255: If the output was updated through the
+// extended protocol, we'll set the wizVal entry to 255, which has
+// no meaning in the LedWiz protocol. This tells us that the value
+// in outLevel[] was set directly from the extended protocol, so it
+// shouldn't be derived from wizVal[].
+//
static uint8_t wizVal[32] = {
48, 48, 48, 48, 48, 48, 48, 48,
48, 48, 48, 48, 48, 48, 48, 48,
@@ -502,87 +551,156 @@
48, 48, 48, 48, 48, 48, 48, 48
};
+// LedWiz flash speed. This is a value from 1 to 7 giving the pulse
+// rate for lights in blinking states.
+static uint8_t wizSpeed = 2;
+
+// Current LedWiz flash cycle counter.
+static uint8_t wizFlashCounter = 0;
+
+// Get the current brightness level for an LedWiz output.
static float wizState(int idx)
{
- if (wizOn[idx])
+ // if the output was last set with an extended protocol message,
+ // use the value set there, ignoring the output's LedWiz state
+ if (wizVal[idx] == 255)
+ return outLevel[idx];
+
+ // if it's off, show at zero intensity
+ if (!wizOn[idx])
+ return 0;
+
+ // check the state
+ uint8_t val = wizVal[idx];
+ if (val <= 48)
+ {
+ // PWM brightness/intensity level. Rescale from the LedWiz
+ // 0..48 integer range to our internal PwmOut 0..1 float range.
+ // Note that on the actual LedWiz, level 48 is actually about
+ // 98% on - contrary to the LedWiz documentation, level 49 is
+ // the true 100% level. (In the documentation, level 49 is
+ // simply not a valid setting.) Even so, we treat level 48 as
+ // 100% on to match the documentation. This won't be perfectly
+ // ocmpatible with the actual LedWiz, but it makes for such a
+ // small difference in brightness (if the output device is an
+ // LED, say) that no one should notice. It seems better to
+ // err in this direction, because while the difference in
+ // brightness when attached to an LED won't be noticeable, the
+ // difference in duty cycle when attached to something like a
+ // contactor *can* be noticeable - anything less than 100%
+ // can cause a contactor or relay to chatter. There's almost
+ // never a situation where you'd want values other than 0% and
+ // 100% for a contactor or relay, so treating level 48 as 100%
+ // makes us work properly with software that's expecting the
+ // documented LedWiz behavior and therefore uses level 48 to
+ // turn a contactor or relay fully on.
+ return val/48.0;
+ }
+ else if (val == 49)
{
- // on - map profile brightness state to PWM level
- uint8_t val = wizVal[idx];
- if (val <= 48)
- {
- // PWM brightness/intensity level. Rescale from the LedWiz
- // 0..48 integer range to our internal PwmOut 0..1 float range.
- // Note that on the actual LedWiz, level 48 is actually about
- // 98% on - contrary to the LedWiz documentation, level 49 is
- // the true 100% level. (In the documentation, level 49 is
- // simply not a valid setting.) Even so, we treat level 48 as
- // 100% on to match the documentation. This won't be perfectly
- // ocmpatible with the actual LedWiz, but it makes for such a
- // small difference in brightness (if the output device is an
- // LED, say) that no one should notice. It seems better to
- // err in this direction, because while the difference in
- // brightness when attached to an LED won't be noticeable, the
- // difference in duty cycle when attached to something like a
- // contactor *can* be noticeable - anything less than 100%
- // can cause a contactor or relay to chatter. There's almost
- // never a situation where you'd want values other than 0% and
- // 100% for a contactor or relay, so treating level 48 as 100%
- // makes us work properly with software that's expecting the
- // documented LedWiz behavior and therefore uses level 48 to
- // turn a contactor or relay fully on.
- return val/48.0;
- }
- else if (val == 49)
- {
- // 49 is undefined in the LedWiz documentation, but actually
- // means 100% on. The documentation says that levels 1-48 are
- // the full PWM range, but empirically it appears that the real
- // range implemented in the firmware is 1-49. Some software on
- // the PC side (notably DOF) is aware of this and uses level 49
- // to mean "100% on". To ensure compatibility with existing
- // PC-side software, we need to recognize level 49.
- return 1.0;
- }
- else if (val >= 129 && val <= 132)
- {
- // Values of 129-132 select different flashing modes. We don't
- // support any of these. Instead, simply treat them as fully on.
- // Note that DOF doesn't ever use modes 129-132, as it implements
- // all flashing modes itself on the host side, so this limitation
- // won't have any effect on DOF users. You can observe it using
- // LedBlinky, though.
- return 1.0;
- }
+ // 49 is undefined in the LedWiz documentation, but actually
+ // means 100% on. The documentation says that levels 1-48 are
+ // the full PWM range, but empirically it appears that the real
+ // range implemented in the firmware is 1-49. Some software on
+ // the PC side (notably DOF) is aware of this and uses level 49
+ // to mean "100% on". To ensure compatibility with existing
+ // PC-side software, we need to recognize level 49.
+ return 1.0;
+ }
+ else if (val == 129)
+ {
+ // 129 = ramp up / ramp down
+ if (wizFlashCounter < 128)
+ return wizFlashCounter/127.0;
else
- {
- // Other values are undefined in the LedWiz documentation. Hosts
- // *should* never send undefined values, since whatever behavior an
- // LedWiz unit exhibits in response is accidental and could change
- // in a future version. We'll treat all undefined values as equivalent
- // to 48 (fully on).
- //
- // NB: the 49 and 129-132 cases are broken out above for the sake
- // of documentation. We end up using 1.0 as the return value for
- // everything outside of the defined 0-48 range, so we could collapse
- // this whole thing to a single 'else' branch, but I wanted to call
- // out the specific reasons for handling the settings above as we do.
- return 1.0;
- }
+ return (255 - wizFlashCounter)/127.0;
+ }
+ else if (val == 130)
+ {
+ // 130 = flash on / off
+ return (wizFlashCounter < 128 ? 1.0 : 0.0);
+ }
+ else if (val == 131)
+ {
+ // 131 = on / ramp down
+ return (255 - wizFlashCounter)/255.0;
}
- else
+ else if (val == 132)
+ {
+ // 132 = ramp up / on
+ return wizFlashCounter/255.0;
+ }
+ else
{
- // off - show at 0 intensity
- return 0.0;
+ // Other values are undefined in the LedWiz documentation. Hosts
+ // *should* never send undefined values, since whatever behavior an
+ // LedWiz unit exhibits in response is accidental and could change
+ // in a future version. We'll treat all undefined values as equivalent
+ // to 48 (fully on).
+ return 1.0;
}
}
+// LedWiz flash timer pulse. This fires periodically to update
+// LedWiz flashing outputs. At the slowest pulse speed set via
+// the SBA command, each waveform cycle has 256 steps, so we
+// choose the pulse time base so that the slowest cycle completes
+// in 2 seconds. This seems to roughly match the real LedWiz
+// behavior. We run the pulse timer at the same rate regardless
+// of the pulse speed; at higher pulse speeds, we simply use
+// larger steps through the cycle on each interrupt. Running
+// every 1/127 of a second = 8ms seems to be a pretty light load.
+Timeout wizPulseTimer;
+#define WIZ_PULSE_TIME_BASE (1.0/127.0)
+static void wizPulse()
+{
+ // increase the counter by the speed increment, and wrap at 256
+ wizFlashCounter += wizSpeed;
+ wizFlashCounter &= 0xff;
+
+ // if we have any flashing lights, update them
+ int ena = false;
+ for (int i = 0 ; i < 32 ; ++i)
+ {
+ if (wizOn[i])
+ {
+ uint8_t s = wizVal[i];
+ if (s >= 129 && s <= 132)
+ {
+ lwPin[i]->set(wizState(i));
+ ena = true;
+ }
+ }
+ }
+
+ // Set up the next timer pulse only if we found anything flashing.
+ // To minimize overhead from this feature, we only enable the interrupt
+ // when we need it. This eliminates any performance penalty to other
+ // features when the host software doesn't care about the flashing
+ // modes. For example, DOF never uses these modes, so there's no
+ // need for them when running Visual Pinball.
+ if (ena)
+ wizPulseTimer.attach(wizPulse, WIZ_PULSE_TIME_BASE);
+}
+
+// Update the physical outputs connected to the LedWiz ports. This is
+// called after any update from an LedWiz protocol message.
static void updateWizOuts()
{
+ // update each output
+ int pulse = false;
for (int i = 0 ; i < 32 ; ++i)
+ {
+ pulse |= (wizVal[i] >= 129 && wizVal[i] <= 132);
lwPin[i]->set(wizState(i));
+ }
+
+ // if any outputs are set to flashing mode, and the pulse timer
+ // isn't running, turn it on
+ if (pulse)
+ wizPulseTimer.attach(wizPulse, WIZ_PULSE_TIME_BASE);
}
-
// ---------------------------------------------------------------------------
//
// Button input
@@ -907,7 +1025,7 @@
printf("%f %f %d %d %f\r\n", vx, vy, x, y, dt);
#endif
}
-
+
private:
// adjust a raw acceleration figure to a usb report value
int rawToReport(float v)
@@ -1243,6 +1361,11 @@
bool reportPix = false;
#endif
+#ifdef ENABLE_TLC5940
+ // start the TLC5940 clock
+ tlc5940.start();
+#endif
+
// create our plunger sensor object
PlungerSensor plungerSensor;
@@ -1368,7 +1491,7 @@
if (data[0] == 64)
{
// LWZ-SBA - first four bytes are bit-packed on/off flags
- // for the outputs; 5th byte is the pulse speed (0-7)
+ // for the outputs; 5th byte is the pulse speed (1-7)
//printf("LWZ-SBA %02x %02x %02x %02x ; %02x\r\n",
// data[1], data[2], data[3], data[4], data[5]);
@@ -1381,6 +1504,13 @@
}
wizOn[i] = ((data[ri] & bit) != 0);
}
+
+ // set the flash speed - enforce the value range 1-7
+ wizSpeed = data[5];
+ if (wizSpeed < 1)
+ wizSpeed = 1;
+ else if (wizSpeed > 7)
+ wizSpeed = 7;
// update the physical outputs
updateWizOuts();
--- a/mbed.bld Wed Sep 23 05:38:27 2015 +0000 +++ b/mbed.bld Fri Sep 25 18:49:53 2015 +0000 @@ -1,1 +1,1 @@ -http://mbed.org/users/mbed_official/code/mbed/builds/6213f644d804 \ No newline at end of file +http://mbed.org/users/mbed_official/code/mbed/builds/4f6c30876dfa \ No newline at end of file