Arnaud VALLEY
Mirror with some correction
Dependencies: mbed FastIO FastPWM USBDevice
Diff: main.cpp
- Revision:
- 76:7f5912b6340e
- Parent:
- 75:677892300e7a
- Child:
- 77:0b96f6867312
--- a/main.cpp Sun Jan 29 19:04:47 2017 +0000
+++ b/main.cpp Fri Feb 03 20:50:02 2017 +0000
@@ -217,6 +217,8 @@
#define DECL_EXTERNS
#include "config.h"
+// forward declarations
+static void waitPlungerIdle(void);
// --------------------------------------------------------------------------
//
@@ -284,8 +286,12 @@
// --------------------------------------------------------------------------
// Main loop iteration timing statistics. Collected only if
// ENABLE_DIAGNOSTICS is set in diags.h.
-float mainLoopIterTime, mainLoopIterCount;
-float mainLoopMsgTime, mainLoopMsgCount;
+#if ENABLE_DIAGNOSTICS
+ uint64_t mainLoopIterTime, mainLoopIterCheckpt[15], mainLoopIterCount;
+ uint64_t mainLoopMsgTime, mainLoopMsgCount;
+ Timer mainLoopTimer;
+#endif
+
// --------------------------------------------------------------------------
//
@@ -640,26 +646,83 @@
// ---------------------------------------------------------------------------
//
-// LedWiz emulation, and enhanced TLC5940 output controller
+// LedWiz emulation
+//
+
+// 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.
+//
+// Even though the original LedWiz protocol can only access 32 ports, we
+// maintain LedWiz state for every port, even if we have more than 32. Our
+// extended protocol allows the client to send LedWiz-style messages that
+// control any set of ports. A replacement LEDWIZ.DLL can make a single
+// Pinscape unit look like multiple virtual LedWiz units to legacy clients,
+// allowing them to control all of our ports. The clients will still be
+// using LedWiz-style states to control the ports, so we need to support
+// the LedWiz scheme with separate on/off and brightness control per port.
+
+// On/off state for each LedWiz output
+static uint8_t *wizOn;
+
+// LedWiz "Profile State" (the LedWiz brightness level or blink mode)
+// 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%
+// 49 = fixed brightness 100% (equivalent to 48)
+// 129 = ramp up / ramp down
+// 130 = flash on / off
+// 131 = on / ramp down
+// 132 = ramp up / on
//
-// 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
-// connected to a physical GPIO pin on the KL25Z. The KL25Z only has 10
-// PWM channels, so in this mode only 10 LedWiz ports will be dimmable; the
-// rest are strictly on/off. The KL25Z also has a limited number of GPIO
-// ports overall - not enough for the full complement of 32 LedWiz ports
-// and 24 VP joystick inputs, so it's necessary to trade one against the
-// other if both features are to be used.
+// (Note that value 49 isn't documented in the LedWiz spec, but real
+// LedWiz units treat it as equivalent to 48, and some PC software uses
+// it, so we need to accept it for compatibility.)
+static uint8_t *wizVal;
+
+// Current actual brightness for each output. This is a simple linear
+// value on a 0..255 scale. This is EITHER the linear brightness computed
+// from the LedWiz setting for the port, OR the 0..255 value set explicitly
+// by the extended protocol:
+//
+// - If the last command that updated the port was an extended protocol
+// SET BRIGHTNESS command, this is the value set by that command. In
+// addition, wizOn[port] is set to 0 if the brightness is 0, 1 otherwise;
+// and wizVal[port] is set to the brightness rescaled to the 0..48 range
+// if the brightness is non-zero.
+//
+// - If the last command that updated the port was an LedWiz command
+// (SBA/PBA/SBX/PBX), this contains the brightness value computed from
+// the combination of wizOn[port] and wizVal[port]. If wizOn[port] is
+// zero, this is simply 0, otherwise it's wizVal[port] rescaled to the
+// 0..255 range.
//
-// The alternative, enhanced mode uses external TLC5940 PWM controller
-// chips to control device outputs. In this mode, each LedWiz software
-// port is mapped to an output on one of the external TLC5940 chips.
-// Two 5940s is enough for the full set of 32 LedWiz ports, and we can
-// support even more chips for even more outputs (although doing so requires
-// breaking LedWiz compatibility, since the LedWiz USB protocol is hardwired
-// for 32 outputs). Every port in this mode has full PWM support.
+// - For a port set to wizOn[port]=1 and wizVal[port] in 129..132, this is
+// also updated continuously to reflect the current flashing brightness
+// level.
//
-
+static uint8_t *outLevel;
+
+
+// LedWiz flash speed. This is a value from 1 to 7 giving the pulse
+// rate for lights in blinking states. The LedWiz API doesn't document
+// what the numbers mean in real time units, but by observation, the
+// "speed" setting represents the period of the flash cycle in 0.25s
+// units, so speed 1 = 0.25 period = 4Hz, speed 7 = 1.75s period = 0.57Hz.
+// The period is the full cycle time of the flash waveform.
+//
+// Each bank of 32 lights has its independent own pulse rate, so we need
+// one entry per bank. Each bank has 32 outputs, so we need a total of
+// ceil(number_of_physical_outputs/32) entries. Note that we could allocate
+// this dynamically once we know the number of actual outputs, but the
+// upper limit is low enough that it's more efficient to use a fixed array
+// at the maximum size.
+static const int MAX_LW_BANKS = (MAX_OUT_PORTS+31)/32;
+static uint8_t wizSpeed[MAX_LW_BANKS];
// Current starting output index for "PBA" messages from the PC (using
// the LedWiz USB protocol). Each PBA message implicitly uses the
@@ -667,6 +730,50 @@
// the message, and increases it (by 8) for the next call.
static int pbaIdx = 0;
+
+// ---------------------------------------------------------------------------
+//
+// Output Ports
+//
+// There are two way to connect outputs. First, you can use the on-board
+// GPIO ports to implement device outputs: each LedWiz software port is
+// connected to a physical GPIO pin on the KL25Z. This has some pretty
+// strict limits, though. The KL25Z only has 10 PWM channels, so only 10
+// GPIO LedWiz ports can be made dimmable; the rest are strictly on/off.
+// The KL25Z also simply doesn't have enough exposed GPIO ports overall to
+// support all of the features the software supports. The software allows
+// for up to 128 outputs, 48 button inputs, plunger input (requiring 1-5
+// GPIO pins), and various other external devices. The KL25Z only exposes
+// about 50 GPIO pins. So if you want to do everything with GPIO ports,
+// you have to ration pins among features.
+//
+// To overcome some of these limitations, we also provide two types of
+// peripheral controllers that allow adding many more outputs, using only
+// a small number of GPIO pins to interface with the peripherals. First,
+// we support TLC5940 PWM controller chips. Each TLC5940 provides 16 ports
+// with full PWM, and multiple TLC5940 chips can be daisy-chained. The
+// chip only requires 5 GPIO pins for the interface, no matter how many
+// chips are in the chain, so it effectively converts 5 GPIO pins into
+// almost any number of PWM outputs. Second, we support 74HC595 chips.
+// These provide only digital outputs, but like the TLC5940 they can be
+// daisy-chained to provide almost unlimited outputs with a few GPIO pins
+// to control the whole chain.
+//
+// Direct GPIO output ports and peripheral controllers can be mixed and
+// matched in one system. The assignment of pins to ports and the
+// configuration of peripheral controllers is all handled in the software
+// setup, so a physical system can be expanded and updated at any time.
+//
+// To handle the diversity of output port types, we start with an abstract
+// base class for outputs. Each type of physical output interface has a
+// concrete subclass. During initialization, we create the appropriate
+// subclass for each software port, mapping it to the assigned GPIO pin
+// or peripheral port. Most of the rest of the software only cares about
+// the abstract interface, so once the subclassed port objects are set up,
+// the rest of the system can control the ports without knowing which types
+// of physical devices they're connected to.
+
+
// Generic LedWiz output port interface. We create a cover class to
// virtualize digital vs PWM outputs, and on-board KL25Z GPIO vs external
// TLC5940 outputs, and give them all a common interface.
@@ -1189,7 +1296,7 @@
// poll the PWM outputs
Timer polledPwmTimer;
-float polledPwmTotalTime, polledPwmRunCount;
+uint64_t polledPwmTotalTime, polledPwmRunCount;
void pollPwmUpdates()
{
// if it's been at least 25ms since the last update, do another update
@@ -1210,7 +1317,7 @@
// collect statistics
IF_DIAG(
- polledPwmTotalTime += t.read();
+ polledPwmTotalTime += t.read_us();
polledPwmRunCount += 1;
)
}
@@ -1242,68 +1349,6 @@
static int numOutputs;
static LwOut **lwPin;
-// 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.
-//
-// Even though the original LedWiz protocol can only access 32 ports, we
-// maintain LedWiz state for every port, even if we have more than 32. Our
-// extended protocol allows the client to send LedWiz-style messages that
-// control any set of ports. A replacement LEDWIZ.DLL can make a single
-// Pinscape unit look like multiple virtual LedWiz units to legacy clients,
-// allowing them to control all of our ports. The clients will still be
-// using LedWiz-style states to control the ports, so we need to support
-// the LedWiz scheme with separate on/off and brightness control per port.
-
-// on/off state for each LedWiz output
-static uint8_t *wizOn;
-
-// LedWiz "Profile State" (the LedWiz brightness level or blink mode)
-// 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%
-// 49 = fixed brightness 100% (equivalent to 48)
-// 129 = ramp up / ramp down
-// 130 = flash on / off
-// 131 = on / ramp down
-// 132 = ramp up / on
-//
-// (Note that value 49 isn't documented in the LedWiz spec, but real
-// LedWiz units treat it as equivalent to 48, and some PC software uses
-// it, so we need to accept it for compatibility.)
-static uint8_t *wizVal;
-
-// LedWiz flash speed. This is a value from 1 to 7 giving the pulse
-// rate for lights in blinking states. The LedWiz API doesn't document
-// what the numbers mean in real time units, but by observation, the
-// "speed" setting represents the period of the flash cycle in 0.25s
-// units, so speed 1 = 0.25 period = 4Hz, speed 7 = 1.75s period = 0.57Hz.
-// The period is the full cycle time of the flash waveform.
-//
-// Each bank of 32 lights has its independent own pulse rate, so we need
-// one entry per bank. Each bank has 32 outputs, so we need a total of
-// ceil(number_of_physical_outputs/32) entries. Note that we could allocate
-// this dynamically once we know the number of actual outputs, but the
-// upper limit is low enough that it's more efficient to use a fixed array
-// at the maximum size.
-static const int MAX_LW_BANKS = (MAX_OUT_PORTS+31)/32;
-static uint8_t wizSpeed[MAX_LW_BANKS];
-
-// LedWiz cycle counters. These must be updated before calling wizState().
-static uint8_t wizFlashCounter[MAX_LW_BANKS];
-
-
-// Current absolute brightness levels for all outputs. These are
-// DOF brightness level value, from 0 for fully off to 255 for fully
-// on. These are always used for extended ports (33 and above), and
-// are used for LedWiz ports (1-32) when we're in extended protocol
-// mode (i.e., ledWizMode == false).
-static uint8_t *outLevel;
-
// create a single output pin
LwOut *createLwPin(int portno, LedWizPortCfg &pc, Config &cfg)
{
@@ -1478,50 +1523,11 @@
lwPin[i] = createLwPin(i, cfg.outPort[i], cfg);
}
-// LedWiz/Extended protocol mode.
-//
-// We implement output port control using both the legacy LedWiz
-// protocol and a private extended protocol (which is 100% backwards
-// compatible with the LedWiz protocol: we recognize all valid legacy
-// protocol commands and handle them the same way a real LedWiz does).
-//
-// The legacy LedWiz protocol has only two message types, which
-// set output port states for a fixed set of 32 outputs. One message
-// sets the "switch" state (on/off) of the ports, and the other sets
-// the "profile" state (brightness or flash pattern). The two states
-// are stored independently, so turning a port off via the switch state
-// doesn't forget or change its brightness: turning it back on will
-// restore the same brightness or flash pattern as before. The "profile"
-// state can be a brightness level from 1 to 49, or one of four flash
-// patterns, identified by a value from 129 to 132. The flash pattern
-// and brightness levels are mutually exclusive, since the single
-// "profile" setting per port selects which is used.
-//
-// The extended protocol discards the flash pattern options and instead
-// uses the full byte range 0..255 for brightness levels. Modern clients
-// based on DOF don't use the flash patterns, since DOF simply sends
-// the individual brightness updates when it wants to create fades or
-// flashes. What we gain by dropping the flash options is finer
-// gradations of brightness - 256 levels rather than the LedWiz's 48.
-// This makes for noticeably smoother fades and a wider gamut for RGB
-// color mixing. The extended protocol also drops the LedWiz notion of
-// separate "switch" and "profile" settings, and instead combines the
-// two into the single brightness setting, with brightness 0 meaning off.
-// This also is the way DOF thinks about the problem, so it's a better
-// match to modern clients.
-//
-// To reconcile the different approaches in the two protocols to setting
-// output port states, we use a global mode: LedWiz mode or Pinscape mode.
-// Whenever an output port message is received, we switch this flag to the
-// mode of the message. The assumption is that only one client at a time
-// will be manipulating output ports, and that any given client uses one
-// protocol exclusively. There's no reason a client should mix the
-// protocols; if a client is aware of the Pinscape protocol at all, it
-// should use it exclusively.
-static uint8_t ledWizMode = true;
-
-// translate an LedWiz brightness level (0-49) to a DOF brightness
-// level (0-255)
+// Translate an LedWiz brightness level (0..49) to a DOF brightness
+// level (0..255). Note that brightness level 49 isn't actually valid,
+// according to the LedWiz API documentation, but many clients use it
+// anyway, and the real LedWiz accepts it and seems to treat it as
+// equivalent to 48.
static const uint8_t lw_to_dof[] = {
0, 5, 11, 16, 21, 27, 32, 37,
43, 48, 53, 58, 64, 69, 74, 80,
@@ -1532,6 +1538,27 @@
255, 255
};
+// Translate a DOF brightness level (0..255) to an LedWiz brightness
+// level (1..48)
+static const uint8_t dof_to_lw[] = {
+ 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 3, 3,
+ 3, 3, 3, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 6, 6,
+ 6, 6, 6, 7, 7, 7, 7, 7, 8, 8, 8, 8, 8, 8, 9, 9,
+ 9, 9, 9, 10, 10, 10, 10, 10, 11, 11, 11, 11, 11, 11, 12, 12,
+ 12, 12, 12, 13, 13, 13, 13, 13, 14, 14, 14, 14, 14, 14, 15, 15,
+ 15, 15, 15, 16, 16, 16, 16, 16, 17, 17, 17, 17, 17, 18, 18, 18,
+ 18, 18, 18, 19, 19, 19, 19, 19, 20, 20, 20, 20, 20, 21, 21, 21,
+ 21, 21, 21, 22, 22, 22, 22, 22, 23, 23, 23, 23, 23, 24, 24, 24,
+ 24, 24, 24, 25, 25, 25, 25, 25, 26, 26, 26, 26, 26, 27, 27, 27,
+ 27, 27, 27, 28, 28, 28, 28, 28, 29, 29, 29, 29, 29, 30, 30, 30,
+ 30, 30, 30, 31, 31, 31, 31, 31, 32, 32, 32, 32, 32, 33, 33, 33,
+ 33, 33, 34, 34, 34, 34, 34, 34, 35, 35, 35, 35, 35, 36, 36, 36,
+ 36, 36, 37, 37, 37, 37, 37, 37, 38, 38, 38, 38, 38, 39, 39, 39,
+ 39, 39, 40, 40, 40, 40, 40, 40, 41, 41, 41, 41, 41, 42, 42, 42,
+ 42, 42, 43, 43, 43, 43, 43, 43, 44, 44, 44, 44, 44, 45, 45, 45,
+ 45, 45, 46, 46, 46, 46, 46, 46, 47, 47, 47, 47, 47, 48, 48, 48
+};
+
// LedWiz flash cycle tables. For efficiency, we use a lookup table
// rather than calculating these on the fly. The flash cycles are
// generated by the following formulas, where 'c' is the current
@@ -1618,255 +1645,168 @@
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
};
-// Translate an LedWiz output (ports 1-32) to a DOF brightness level.
-// Note: update all wizFlashCounter[] entries before calling this to
-// ensure that we're at the right place in each flash cycle.
-//
-// Important: the caller must update the wizFlashCounter[] array before
-// calling this. We leave it to the caller to update the array rather
-// than doing it here, because each set of 32 outputs shares the same
-// counter entry.
-static uint8_t wizState(int idx)
-{
- // If we're in extended protocol mode, ignore the LedWiz setting
- // for the port and use the new protocol setting instead.
- if (!ledWizMode)
- 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 <= 49)
- {
- // 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
- // compatible 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.
- //
- // Note that value 49 is undefined in the LedWiz documentation,
- // but real LedWiz units treat it as 100%, equivalent to 48.
- // Some software on the PC side uses this, so we need to treat
- // it the same way for compatibility.
- return lw_to_dof[val];
- }
- else if (val >= 129 && val <= 132)
- {
- // flash mode - get the current counter for the bank, and look
- // up the current position in the cycle for the mode
- const int c = wizFlashCounter[idx/32];
- return wizFlashLookup[((val-129)*256) + c];
- }
- 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).
- return 255;
- }
-}
-
// LedWiz flash cycle timer. This runs continuously. On each update,
// we use this to figure out where we are on the cycle for each bank.
Timer wizCycleTimer;
-// Update the LedWiz flash cycle counters
-static void updateWizCycleCounts()
-{
- // Update the LedWiz flash cycle positions. Each cycle is 2/N
- // seconds long, where N is the speed setting for the bank. N
- // ranges from 1 to 7.
- //
- // Note that we treat the microsecond clock as a 32-bit unsigned
- // int. This rolls over (i.e., exceeds 0xffffffff) every 71 minutes.
- // We only care about the phase of the current LedWiz cycle, so we
- // don't actually care about the absolute time - we only care about
- // the time relative to some arbitrary starting point. Whenever the
- // clock rolls over, it effectively sets a new starting point; since
- // we only need an arbitrary starting point, that's largely okay.
- // The one drawback is that these epoch resets can obviously occur
- // in the middle of a cycle. When this occurs, the update just before
- // the rollover and the update just after the rollover will use
- // different epochs, so their phases might be misaligned. That could
- // cause a sudden jump in brightness between the two updates and a
- // shorter-than-usual or longer-than-usual time for that cycle. To
- // avoid that, we'd have to use a higher-precision clock (say, a 64-bit
- // microsecond counter) and do all of the calculations at the higher
- // precision. Given that the rollover only happens once every 71
- // minutes, and that the only problem it causes is a momentary glitch
- // in the flash pattern, I think it's an equitable trade for the slightly
- // faster processing in the 32-bit domain. This routine is called
- // frequently from the main loop, so it's critial to minimize execution
- // time.
- uint32_t tcur = wizCycleTimer.read_us();
- for (int i = 0 ; i < MAX_LW_BANKS ; ++i)
- {
- // Figure the point in the cycle. The LedWiz "speed" setting is
- // waveform period in 0.25s units. (There's no official LedWiz
- // documentation of what the speed means in real units, so this is
- // based on observations.)
- //
- // We do this calculation frequently from the main loop, since we
- // have to do it every time we update the output flash cycles,
- // which in turn has to be done frequently to make the cycles
- // appear smooth to users. So we're going to get a bit tricky
- // with integer arithmetic to streamline it. The goal is to find
- // the current phase position in the output waveform; in abstract
- // terms, we're trying to find the angle, 0 to 2*pi, in the current
- // cycle. Floating point arithmetic is expensive on the KL25Z
- // since it's all done in software, so we'll do everything in
- // integers. To do that, rather than trying to find the phase
- // angle as a continuous quantity, we'll quantize it, into 256
- // quanta per cycle. Each quantum is 1/256 of the cycle length,
- // so for a 1-second cycle (LedWiz speed 4), each quantum is
- // 1/256 of second or about 3.9ms. To find the phase, then, we
- // simply take the current time (as an elapsed time from an
- // arbitrary zero point aka epoch), quantize it into 3.9ms chunks,
- // and calculate the remainder mod 256. Remainder mod 256 is a
- // fast operation since it's equivalent to bit masking with 0xFF.
- // (That's why we chose a power of two for the number of quanta
- // per cycle.) Our timer gives us microseconds since it started,
- // so to convert to quanta, we divide by microseconds per quantum;
- // in the case of speed 1 with its 3.906ms quanta, we divide by
- // 3906. But we can take this one step further, getting really
- // tricky now. Dividing by N is the same as muliplying by X/N
- // for some X, and then dividing the result by X. Why, you ask,
- // would we want to do two operations where we could do one?
- // Because if we're clever, the two operations will be much
- // faster the the one. The M0+ has no DIVIDE instruction, so
- // integer division has to be done in software, at a cost of about
- // 100 clocks per operation. The KL25Z M0+ has a one-cycle
- // hardware multiplier, though. But doesn't that leave that
- // second division still to do? Yes, but if we choose a power
- // of 2 for X, we can do that division with a bit shift, another
- // single-cycle operation. So we can do the division in two
- // cycles by breaking it up into a multiply + shift.
- //
- // Each entry in this array represents X/N for the corresponding
- // LedWiz speed, where N is the number of time quanta per cycle
- // and X is 2^24. The time quanta are chosen such that 256
- // quanta add up to approximately (LedWiz speed setting * 0.25s).
- //
- // Note that the calculation has an implicit bit mask (result & 0xFF)
- // to get the final result mod 256. But we don't have to actually
- // do that work because we're using 32-bit ints and a 2^24 fixed
- // point base (X in the narrative above). The final shift right by
- // 24 bits to divide out the base will leave us with only 8 bits in
- // the result, since we started with 32.
- static const uint32_t inv_us_per_quantum[] = { // indexed by LedWiz speed
- 0, 17172, 8590, 5726, 4295, 3436, 2863, 2454
- };
- wizFlashCounter[i] = ((tcur * inv_us_per_quantum[wizSpeed[i]]) >> 24);
- }
-}
-
-// LedWiz flash timer pulse. The main loop calls this periodically
-// to update outputs set to LedWiz flash modes.
-Timer wizPulseTimer;
-float wizPulseTotalTime, wizPulseRunCount;
-const uint32_t WIZ_INTERVAL_US = 8000;
+// timing statistics for wizPulse()
+uint64_t wizPulseTotalTime, wizPulseRunCount;
+
+// LedWiz flash timer pulse. The main loop calls this on each cycle
+// to update outputs using LedWiz flash modes. We do one bank of 32
+// outputs on each cycle.
static void wizPulse()
{
- // if it's been long enough, update the LedWiz outputs
- if (wizPulseTimer.read_us() >= WIZ_INTERVAL_US)
+ // current bank
+ static int wizPulseBank = 0;
+
+ // start a timer for statistics collection
+ IF_DIAG(
+ Timer t;
+ t.start();
+ )
+
+ // Update the current bank's cycle counter: figure the current
+ // phase of the LedWiz pulse cycle for this bank.
+ //
+ // The LedWiz speed setting gives the flash period in 0.25s units
+ // (speed 1 is a flash period of .25s, speed 7 is a period of 1.75s).
+ //
+ // What we're after here is the "phase", which is to say the point
+ // in the current cycle. If we assume that the cycle has been running
+ // continuously since some arbitrary time zero in the past, we can
+ // figure where we are in the current cycle by dividing the time since
+ // that zero by the cycle period and taking the remainder. E.g., if
+ // the cycle time is 5 seconds, and the time since t-zero is 17 seconds,
+ // we divide 17 by 5 to get a remainder of 2. That says we're 2 seconds
+ // into the current 5-second cycle, or 2/5 of the way through the
+ // current cycle.
+ //
+ // We do this calculation on every iteration of the main loop, so we
+ // want it to be very fast. To streamline it, we'll use some tricky
+ // integer arithmetic. The result will be the same as the straightforward
+ // remainder and fraction calculation we just explained, but we'll get
+ // there by less-than-obvious means.
+ //
+ // Rather than finding the phase as a continuous quantity or floating
+ // point number, we'll quantize it. We'll divide each cycle into 256
+ // time units, or quanta. Each quantum is 1/256 of the cycle length,
+ // so for a 1-second cycle (LedWiz speed 4), each quantum is 1/256 of
+ // a second, or about 3.9ms. If we express the time since t-zero in
+ // these units, the time period of one cycle is exactly 256 units, so
+ // we can calculate our point in the cycle by taking the remainder of
+ // the time (in our funny units) divided by 256. The special thing
+ // about making the cycle time equal to 256 units is that "x % 256"
+ // is exactly the same as "x & 255", which is a much faster operation
+ // than division on ARM M0+: this CPU has no hardware DIVIDE operation,
+ // so an integer division takes about 5us. The bit mask operation, in
+ // contrast, takes only about 60ns - about 100x faster. 5us doesn't
+ // sound like much, but we do this on every main loop, so every little
+ // bit counts.
+ //
+ // The snag is that our system timer gives us the elapsed time in
+ // microseconds. We still need to convert this to our special quanta
+ // of 256 units per cycle. The straightforward way to do that is by
+ // dividing by (microseconds per quantum). E.g., for LedWiz speed 4,
+ // we decided that our quantum was 1/256 of a second, or 3906us, so
+ // dividing the current system time in microseconds by 3906 will give
+ // us the time in our quantum units. But now we've just substituted
+ // one division for another!
+ //
+ // This is where our really tricky integer math comes in. Dividing
+ // by X is the same as multiplying by 1/X. In integer math, 1/3906
+ // is zero, so that won't work. But we can get around that by doing
+ // the integer math as "fixed point" arithmetic instead. It's still
+ // actually carried out as integer operations, but we'll scale our
+ // integers by a scaling factor, then take out the scaling factor
+ // later to get the final result. The scaling factor we'll use is
+ // 2^24. So we're going to calculate (time * 2^24/3906), then divide
+ // the result by 2^24 to get the final answer. I know it seems like
+ // we're substituting one division for another yet again, but this
+ // time's the charm, because dividing by 2^24 is a bit shift operation,
+ // which is another single-cycle operation on M0+. You might also
+ // wonder how all these tricks don't cause overflows or underflows
+ // or what not. Well, the multiply by 2^24/3906 will cause an
+ // overflow, but we don't care, because the overflow will all be in
+ // the high-order bits that we're going to discard in the final
+ // remainder calculation anyway.
+ //
+ // Each entry in the array below represents 2^24/N for the corresponding
+ // LedWiz speed, where N is the number of time quanta per cycle at that
+ // speed. The time quanta are chosen such that 256 quanta add up to
+ // approximately (LedWiz speed setting * 0.25s).
+ //
+ // Note that the calculation has an implicit bit mask (result & 0xFF)
+ // to get the final result mod 256. But we don't have to actually
+ // do that work because we're using 32-bit ints and a 2^24 fixed
+ // point base (X in the narrative above). The final shift right by
+ // 24 bits to divide out the base will leave us with only 8 bits in
+ // the result, since we started with 32.
+ static const uint32_t inv_us_per_quantum[] = { // indexed by LedWiz speed
+ 0, 17172, 8590, 5726, 4295, 3436, 2863, 2454
+ };
+ int counter = ((wizCycleTimer.read_us() * inv_us_per_quantum[wizSpeed[wizPulseBank]]) >> 24);
+
+ // get the range of 32 output sin this bank
+ int fromPort = wizPulseBank*32;
+ int toPort = fromPort+32;
+ if (toPort > numOutputs)
+ toPort = numOutputs;
+
+ // update all outputs set to flashing values
+ for (int i = fromPort ; i < toPort ; ++i)
{
- // reset the timer for the next round
- wizPulseTimer.reset();
-
- // if we're in LedWiz mode, update flashing outputs
- if (ledWizMode)
+ // Update the port only if the LedWiz SBA switch for the port is on
+ // (wizOn[i]) AND the port is a PBA flash mode in the range 129..132.
+ // These modes and only these modes have the high bit (0x80) set, so
+ // we can test for them simply by testing the high bit.
+ if (wizOn[i])
{
- // start a timer for statistics collection
- IF_DIAG(
- Timer t;
- t.start();
- )
-
- // update the cycle counters
- updateWizCycleCounts();
-
- // update all outputs set to flashing values
- for (int i = numOutputs ; i > 0 ; )
+ uint8_t val = wizVal[i];
+ if ((val & 0x80) != 0)
{
- if (wizOn[--i])
- {
- // If the "brightness" is in the range 129..132, it's a
- // flash mode. Note that we only have to check the high
- // bit here, because the protocol message handler validates
- // the wizVal[] entries when storing them: the only valid
- // values with the high bit set are 129..132. Skipping
- // validation here saves us a tiny bit of work, which we
- // care about because we have to loop over all outputs
- // here, and we invoke this frequently from the main loop.
- const uint8_t val = wizVal[i];
- if ((val & 0x80) != 0)
- {
- // get the current cycle time, then look up the
- // value for the mode at the cycle time
- const int c = wizFlashCounter[i >> 5];
- lwPin[i]->set(wizFlashLookup[((val-129) << 8) + c]);
- }
- }
+ // ook up the value for the mode at the cycle time
+ lwPin[i]->set(outLevel[i] = wizFlashLookup[((val-129) << 8) + counter]);
}
-
- // flush changes to 74HC595 chips, if attached
- if (hc595 != 0)
- hc595->update();
-
- // collect timing statistics
- IF_DIAG(
- wizPulseTotalTime += t.read();
- wizPulseRunCount += 1;
- )
}
- }
-}
-
-// Update the physical outputs connected to the LedWiz ports. This is
-// called after any update from an LedWiz protocol message.
-static void updateWizOuts()
-{
- // update the cycle counters
- updateWizCycleCounts();
-
- // update each output
- for (int i = 0 ; i < numOutputs ; ++i)
- lwPin[i]->set(wizState(i));
-
+ }
+
// flush changes to 74HC595 chips, if attached
if (hc595 != 0)
hc595->update();
+
+ // switch to the next bank
+ if (++wizPulseBank >= MAX_LW_BANKS)
+ wizPulseBank = 0;
+
+ // collect timing statistics
+ IF_DIAG(
+ wizPulseTotalTime += t.read_us();
+ wizPulseRunCount += 1;
+ )
}
-// Update all physical outputs. This is called after a change to a global
-// setting that affects all outputs, such as engaging or canceling Night Mode.
-static void updateAllOuts()
+// Update a port to reflect its new LedWiz SBA+PBA setting.
+static void updateLwPort(int port)
{
- // update LedWiz states
- updateWizOuts();
+ // check if the SBA switch is on or off
+ if (wizOn[port])
+ {
+ // It's on. If the port is a valid static brightness level,
+ // set the output port to match. Otherwise leave it as is:
+ // if it's a flashing mode, the flash mode pulse will update
+ // it on the next cycle.
+ int val = wizVal[port];
+ if (val <= 49)
+ lwPin[port]->set(outLevel[port] = lw_to_dof[val]);
+ }
+ else
+ {
+ // the port is off - set absolute brightness zero
+ lwPin[port]->set(outLevel[port] = 0);
+ }
}
-//
// Turn off all outputs and restore everything to the default LedWiz
// state. This sets outputs #1-32 to LedWiz profile value 48 (full
// brightness) and switch state Off, sets all extended outputs (#33
@@ -1888,9 +1828,6 @@
for (int i = 0 ; i < countof(wizSpeed) ; ++i)
wizSpeed[i] = 2;
- // revert to LedWiz mode for output controls
- ledWizMode = true;
-
// flush changes to hc595, if applicable
if (hc595 != 0)
hc595->update();
@@ -1902,10 +1839,7 @@
// address any port group.
void sba_sbx(int portGroup, const uint8_t *data)
{
- // switch to LedWiz protocol mode
- ledWizMode = true;
-
- // update all on/off states
+ // update all on/off states in the group
for (int i = 0, bit = 1, imsg = 1, port = portGroup*32 ;
i < 32 && port < numOutputs ;
++i, bit <<= 1, ++port)
@@ -1917,25 +1851,26 @@
}
// set the on/off state
- wizOn[port] = ((data[imsg] & bit) != 0);
+ bool on = wizOn[port] = ((data[imsg] & bit) != 0);
+
+ // set the output port brightness to match the new setting
+ updateLwPort(port);
}
// set the flash speed for the port group
if (portGroup < countof(wizSpeed))
wizSpeed[portGroup] = (data[5] < 1 ? 1 : data[5] > 7 ? 7 : data[5]);
- // update the physical outputs with the new LedWiz states
- updateWizOuts();
+ // update 74HC959 outputs
+ if (hc595 != 0)
+ hc595->update();
}
// Carry out a PBA or PBX message.
void pba_pbx(int basePort, const uint8_t *data)
{
- // switch LedWiz protocol mode
- ledWizMode = true;
-
// update each wizVal entry from the brightness data
- for (int i = 0, iwiz = basePort ; i < 8 && iwiz < numOutputs ; ++i, ++iwiz)
+ for (int i = 0, port = basePort ; i < 8 && port < numOutputs ; ++i, ++port)
{
// get the value
uint8_t v = data[i];
@@ -1950,11 +1885,15 @@
v = 48;
// store it
- wizVal[iwiz] = v;
+ wizVal[port] = v;
+
+ // update the port
+ updateLwPort(port);
}
- // update the physical outputs
- updateWizOuts();
+ // update 74HC595 outputs
+ if (hc595 != 0)
+ hc595->update();
}
@@ -2980,6 +2919,11 @@
tInt_.start();
}
+ void disableInterrupts()
+ {
+ mma_.clearInterruptMode();
+ }
+
void get(int &x, int &y)
{
// disable interrupts while manipulating the shared data
@@ -3054,13 +2998,13 @@
// will clear up this overrun condition and allow normal interrupt
// generation to continue.
//
- // Note that this stuck condition *shouldn't* ever occur - if it does,
- // it means that we're spending a long period with interrupts disabled
- // (either in a critical section or in another interrupt handler), which
- // will likely cause other worse problems beyond the sticky accelerometer.
- // Even so, it's easy to detect and correct, so we'll do so for the sake
- // of making the system more fault-tolerant.
- if (tInt_.read() > 1.0f)
+ // Note that this stuck condition *shouldn't* ever occur, because if only
+ // happens if we're spending a long period with interrupts disabled (in
+ // a critical section or in another interrupt handler), which will likely
+ // cause other, worse problems beyond the sticky accelerometer. Even so,
+ // it's easy to detect and correct, so we'll do so for the sake of making
+ // the system a little more fault-tolerant.
+ if (tInt_.read_us() > 1000000)
{
float x, y, z;
mma_.getAccXYZ(x, y, z);
@@ -3165,7 +3109,6 @@
InterruptIn intIn_;
};
-
// ---------------------------------------------------------------------------
//
// Clear the I2C bus for the MMA8451Q. This seems necessary some of the time
@@ -3197,7 +3140,8 @@
wait_us(20);
}
}
-
+
+
// ---------------------------------------------------------------------------
//
// Simple binary (on/off) input debouncer. Requires an input to be stable
@@ -3544,6 +3488,17 @@
// flash memory controller interface
FreescaleIAP iap;
+// NVM structure in memory. This has to be aliend on a sector boundary,
+// since we have to be able to erase its page(s) in order to write it.
+// Further, we have to ensure that nothing else occupies any space within
+// the same pages, since we'll erase that entire space whenever we write.
+static const union
+{
+ NVM nvm; // the NVM structure
+ char guard[((sizeof(NVM) + SECTOR_SIZE - 1)/SECTOR_SIZE)*SECTOR_SIZE];
+}
+flash_nvm_memory __attribute__ ((aligned(SECTOR_SIZE))) = { };
+
// figure the flash address as a pointer along with the number of sectors
// required to store the structure
NVM *configFlashAddr(int &addr, int &numSectors)
@@ -3553,7 +3508,7 @@
// figure the address - this is the highest flash address where the
// structure will fit with the start aligned on a sector boundary
- addr = iap.flash_size() - (numSectors * SECTOR_SIZE);
+ addr = (int)&flash_nvm_memory;
// return the address as a pointer
return (NVM *)addr;
@@ -3566,8 +3521,11 @@
return configFlashAddr(addr, numSectors);
}
-// Load the config from flash
-void loadConfigFromFlash()
+// Load the config from flash. Returns true if a valid non-default
+// configuration was loaded, false if we not. If we return false,
+// we load the factory defaults, so the configuration object is valid
+// in either case.
+bool loadConfigFromFlash()
{
// We want to use the KL25Z's on-board flash to store our configuration
// data persistently, so that we can restore it across power cycles.
@@ -3590,23 +3548,141 @@
NVM *flash = configFlashAddr();
// if the flash is valid, load it; otherwise initialize to defaults
- if (flash->valid())
+ bool nvm_valid = flash->valid();
+ if (nvm_valid)
{
// flash is valid - load it into the RAM copy of the structure
memcpy(&nvm, flash, sizeof(NVM));
}
else
{
- // flash is invalid - load factory settings nito RAM structure
+ // flash is invalid - load factory settings into RAM structure
cfg.setFactoryDefaults();
}
+
+ // tell the caller what happened
+ return nvm_valid;
}
void saveConfigToFlash()
{
+ // make sure the plunger sensor isn't busy
+ waitPlungerIdle();
+
+ // get the config block location in the flash memory
int addr, sectors;
configFlashAddr(addr, sectors);
- nvm.save(iap, addr);
+
+ // loop until we save it successfully
+ for (int i = 0 ; i < 5 ; ++i)
+ {
+ // show cyan while writing
+ diagLED(0, 1, 1);
+
+ // save the data
+ nvm.save(iap, addr);
+
+ // diagnostic lights off
+ diagLED(0, 0, 0);
+
+ // verify the data
+ if (nvm.verify(addr))
+ {
+ // show a diagnostic success flash
+ for (int j = 0 ; j < 3 ; ++j)
+ {
+ diagLED(0, 1, 1);
+ wait_us(50000);
+ diagLED(0, 0, 0);
+ wait_us(50000);
+ }
+
+ // success - no need to write again
+ break;
+ }
+ else
+ {
+ // Write failed. For diagnostic purposes, flash red a few times.
+ // Then go back through the loop to make another attempt at the
+ // write.
+ for (int j = 0 ; j < 5 ; ++j)
+ {
+ diagLED(1, 0, 0);
+ wait_us(50000);
+ diagLED(0, 0, 0);
+ wait_us(50000);
+ }
+ }
+ }
+}
+
+// ---------------------------------------------------------------------------
+//
+// Host-loaded configuration. The Flash NVM block above is designed to be
+// stored from within the firmware; in contrast, the host-loaded config is
+// stored by the host, by patching the firwmare binary (.bin) file before
+// downloading it to the device.
+//
+// Ideally, we'd use the host-loaded memory for all configuration updates,
+// because the KL25Z doesn't seem to be 100% reliable writing flash itself.
+// There seems to be a chance of memory bus contention while a write is in
+// progress, which can either corrupt the write or cause the CPU to lock up
+// before the write is completed. It seems more reliable to program the
+// flash externally, via the OpenSDA connection. Unfortunately, none of
+// the available OpenSDA versions are capable of programming specific flash
+// sectors; they always erase the entire flash memory space. We *could*
+// make the Windows config program simply re-download the entire firmware
+// for every configuration update, but I'd rather not because of the extra
+// wear this would put on the flash. So, as a compromise, we'll use the
+// host-loaded config whenever the user explicitly updates the firmware,
+// but we'll use the on-board writer when only making a config change.
+//
+// The memory here is stored using the same format as the USB "Set Config
+// Variable" command. These messages are 8 bytes long and start with a
+// byte value 66, followed by the variable ID, followed by the variable
+// value data in a format defined separately for each variable. To load
+// the data, we'll start at the first byte after the signature, and
+// interpret each 8-byte block as a type 66 message. If the first byte
+// of a block is not 66, we'll take it as the end of the data.
+//
+// We provide a block of storage here big enough for 1,024 variables.
+// The header consists of a 30-byte signature followed by two bytes giving
+// the available space in the area, in this case 8192 == 0x0200. The
+// length is little-endian. Note that the linker will implicitly zero
+// the rest of the block, so if the host doesn't populate it, we'll see
+// that it's empty by virtue of not containing the required '66' byte
+// prefix for the first 8-byte variable block.
+static const uint8_t hostLoadedConfig[8192+32]
+ __attribute__ ((aligned(SECTOR_SIZE))) =
+ "///Pinscape.HostLoadedConfig//\0\040"; // 30 byte signature + 2 byte length
+
+// Get a pointer to the first byte of the configuration data
+const uint8_t *getHostLoadedConfigData()
+{
+ // the first configuration variable byte immediately follows the
+ // 32-byte signature header
+ return hostLoadedConfig + 32;
+};
+
+// forward reference to config var store function
+void configVarSet(const uint8_t *);
+
+// Load the host-loaded configuration data into the active (RAM)
+// configuration object.
+void loadHostLoadedConfig()
+{
+ // Start at the first configuration variable. Each variable
+ // block is in the format of a Set Config Variable command in
+ // the USB protocol, so each block starts with a byte value of
+ // 66 and is 8 bytes long. Continue as long as we find valid
+ // variable blocks, or reach end end of the block.
+ const uint8_t *start = getHostLoadedConfigData();
+ const uint8_t *end = hostLoadedConfig + sizeof(hostLoadedConfig);
+ for (const uint8_t *p = getHostLoadedConfigData() ; start < end && *p == 66 ; p += 8)
+ {
+ // load this variable
+ configVarSet(p);
+ }
}
// ---------------------------------------------------------------------------
@@ -3635,9 +3711,16 @@
int port = int(cfg.nightMode.port) - 1;
if (port >= 0 && port < numOutputs)
lwPin[port]->set(nightMode ? 255 : 0);
-
- // update all outputs for the mode change
- updateAllOuts();
+
+ // Reset all outputs at their current value, so that the underlying
+ // physical outputs get turned on or off as appropriate for the night
+ // mode change.
+ for (int i = 0 ; i < numOutputs ; ++i)
+ lwPin[i]->set(outLevel[i]);
+
+ // update 74HC595 outputs
+ if (hc595 != 0)
+ hc595->update();
}
// Toggle night mode
@@ -3655,6 +3738,12 @@
// the plunger sensor interface object
PlungerSensor *plungerSensor = 0;
+// wait for the plunger sensor to complete any outstanding read
+static void waitPlungerIdle(void)
+{
+ while (!plungerSensor->ready()) { }
+}
+
// Create the plunger sensor based on the current configuration. If
// there's already a sensor object, we'll delete it.
void createPlunger()
@@ -3782,13 +3871,17 @@
// initialize the filter
initFilter();
}
-
+
// Collect a reading from the plunger sensor. The main loop calls
// this frequently to read the current raw position data from the
// sensor. We analyze the raw data to produce the calibrated
// position that we report to the PC via the joystick interface.
void read()
{
+ // if the sensor is busy, skip the reading on this round
+ if (!plungerSensor->ready())
+ return;
+
// Read a sample from the sensor
PlungerReading r;
if (plungerSensor->read(r))
@@ -3825,6 +3918,9 @@
cfg.plunger.cal.max = r.pos;
if (r.pos < cfg.plunger.cal.min)
cfg.plunger.cal.min = r.pos;
+
+ // update our cached calibration data
+ onUpdateCal();
// If we're in calibration state 0, we're waiting for the
// plunger to come to rest at the park position so that we
@@ -3843,6 +3939,7 @@
// update the zero position from the new average
cfg.plunger.cal.zero = uint16_t(calZeroPosSum / calZeroPosN);
+ onUpdateCal();
// switch to calibration state 1 - at rest
calState = 1;
@@ -3866,9 +3963,7 @@
{
// Not in calibration mode. Apply the existing calibration and
// rescale to the joystick range.
- r.pos = int(
- (long(r.pos - cfg.plunger.cal.zero) * JOYMAX)
- / (cfg.plunger.cal.max - cfg.plunger.cal.zero));
+ r.pos = applyCal(r.pos);
// limit the result to the valid joystick range
if (r.pos > JOYMAX)
@@ -3902,12 +3997,23 @@
// since we only use the velocity for comparison purposes,
// to detect acceleration trends. We therefore save ourselves
// a little CPU time by using the natural units of our inputs.
+ //
+ // We don't care about the absolute velocity; this is a purely
+ // relative calculation. So to speed things up, calculate it
+ // in the integer domain, using a fixed-point representation
+ // with a 64K scale. In other words, with the stored values
+ // shifted left 16 bits from the actual values: the value 1
+ // is stored as 1<<16. The position readings are in the range
+ // -JOYMAX..JOYMAX, which fits in 16 bits, and the time
+ // differences will generally be on the scale of a few
+ // milliseconds = thousands of microseconds. So the velocity
+ // figures will fit nicely into a 32-bit fixed point value with
+ // a 64K scale factor.
const PlungerReading &prv2 = nthHist(1);
- float v = float(r.pos - prv2.pos)/float(r.t - prv2.t);
+ int v = ((r.pos - prv2.pos) << 16)/(r.t - prv2.t);
// presume we'll report the latest instantaneous reading
z = r.pos;
- vz = v;
// Check firing events
switch (firing)
@@ -4104,8 +4210,9 @@
vprv = v;
// add the new reading to the history
- hist[histIdx++] = r;
- histIdx %= countof(hist);
+ hist[histIdx] = r;
+ if (++histIdx > countof(hist))
+ histIdx = 0;
// apply the post-processing filter
zf = applyPostFilter();
@@ -4119,9 +4226,6 @@
return zf;
}
- // Get the current velocity (joystick distance units per microsecond)
- float getVelocity() const { return vz; }
-
// get the timestamp of the current joystick report (microseconds)
uint32_t getTimestamp() const { return nthHist(0).t; }
@@ -4148,6 +4252,7 @@
// got a reading - use it as the initial zero point
applyPreFilter(r);
cfg.plunger.cal.zero = r.pos;
+ onUpdateCal();
// use it as the starting point for the settling watch
calZeroStart = r;
@@ -4156,6 +4261,7 @@
{
// no reading available - use the default 1/6 position
cfg.plunger.cal.zero = 0xffff/6;
+ onUpdateCal();
// we don't have a starting point for the setting watch
calZeroStart.pos = -65535;
@@ -4173,6 +4279,7 @@
// bad settings - reset to defaults
cfg.plunger.cal.max = 0xffff;
cfg.plunger.cal.zero = 0xffff/6;
+ onUpdateCal();
}
}
@@ -4180,9 +4287,33 @@
plungerCalMode = f;
}
+ // Cached inverse of the calibration range. This is for calculating
+ // the calibrated plunger position given a raw sensor reading. The
+ // cached inverse is calculated as
+ //
+ // 64K * JOYMAX / (cfg.plunger.cal.max - cfg.plunger.cal.zero)
+ //
+ // To convert a raw sensor reading to a calibrated position, calculate
+ //
+ // ((reading - cfg.plunger.cal.zero)*invCalRange) >> 16
+ //
+ // That yields the calibration result without performing a division.
+ int invCalRange;
+
+ // apply the calibration range to a reading
+ inline int applyCal(int reading)
+ {
+ return ((reading - cfg.plunger.cal.zero)*invCalRange) >> 16;
+ }
+
+ void onUpdateCal()
+ {
+ invCalRange = (JOYMAX << 16)/(cfg.plunger.cal.max - cfg.plunger.cal.zero);
+ }
+
// is a firing event in progress?
bool isFiring() { return firing == 3; }
-
+
private:
// Plunger data filtering mode: optionally apply filtering to the raw
@@ -4443,7 +4574,7 @@
}
// velocity at previous reading, and the one before that
- float vprv, vprv2;
+ int vprv, vprv2;
// Circular buffer of recent readings. We keep a short history
// of readings to analyze during firing events. We can only identify
@@ -4515,9 +4646,6 @@
// (in joystick distance units)
int z;
- // velocity of this reading (joystick distance units per microsecond)
- float vz;
-
// next filtered Z value to report to the joystick interface
int zf;
};
@@ -4766,7 +4894,7 @@
#define v_byte_ro(val, ofs) // ignore read-only variables on SET
#define v_ui32_ro(val, ofs) // ignore read-only variables on SET
#define VAR_MODE_SET 1 // we're in SET mode
-#define v_func configVarSet
+#define v_func configVarSet(const uint8_t *data)
#include "cfgVarMsgMap.h"
// redefine everything for the SET messages
@@ -4787,7 +4915,7 @@
#define v_byte_ro(val, ofs) data[ofs] = (val)
#define v_ui32_ro(val, ofs) ui32Wire(data+(ofs), val);
#define VAR_MODE_SET 0 // we're in GET mode
-#define v_func configVarGet
+#define v_func configVarGet(uint8_t *data)
#include "cfgVarMsgMap.h"
@@ -5036,9 +5164,6 @@
// outputs above the LedWiz range, PBA/SBA messages can't
// address those ports anyway.
- // flag that we're in extended protocol mode
- ledWizMode = true;
-
// figure the block of 7 ports covered in the message
int i0 = (data[0] - 200)*7;
int i1 = i0 + 7 < numOutputs ? i0 + 7 : numOutputs;
@@ -5053,8 +5178,22 @@
// set the port's LedWiz state to the nearest equivalent, so
// that it maintains its current setting if we switch back to
// LedWiz mode on a future update
- wizOn[i] = (b != 0);
- wizVal[i] = (b*48)/255;
+ if (b != 0)
+ {
+ // Non-zero brightness - set the SBA switch on, and set the
+ // PBA brightness to the DOF brightness rescaled to the 1..48
+ // LedWiz range. If the port is subsequently addressed by an
+ // LedWiz command, this will carry the current DOF setting
+ // forward unchanged.
+ wizOn[i] = 1;
+ wizVal[i] = dof_to_lw[b];
+ }
+ else
+ {
+ // Zero brightness. Set the SBA switch off, and leave the
+ // PBA brightness the same as it was.
+ wizOn[i] = 0;
+ }
// set the output
lwPin[i]->set(b);
@@ -5111,12 +5250,40 @@
// -> no longer very useful, since we use our own custom malloc/new allocator (see xmalloc() above)
// {int *a = new int; printf("Stack=%lx, heap=%lx, free=%ld\r\n", (long)&a, (long)a, (long)&a - (long)a);}
- // clear the I2C bus (for the accelerometer)
+ // clear the I2C connection
clear_i2c();
- // load the saved configuration (or set factory defaults if no flash
- // configuration has ever been saved)
- loadConfigFromFlash();
+ // Load the saved configuration. There are two sources of the
+ // configuration data:
+ //
+ // - Look for an NVM (flash non-volatile memory) configuration.
+ // If this is valid, we'll load it. The NVM is config data that can
+ // be updated dynamically by the host via USB commands and then stored
+ // in the flash by the firmware itself. If this exists, it supersedes
+ // any of the other settings stores. The Windows config tool uses this
+ // to store user settings updates.
+ //
+ // - If there's no NVM, we'll load the factory defaults, then we'll
+ // load any settings stored in the host-loaded configuration. The
+ // host can patch a set of configuration variable settings into the
+ // .bin file when loading new firmware, in the host-loaded config
+ // area that we reserve for this purpose. This allows the host to
+ // restore a configuration at the same time it installs firmware,
+ // without a separate download of the config data.
+ //
+ // The NVM supersedes the host-loaded config, since it can be updated
+ // between firmware updated and is thus presumably more recent if it's
+ // present. (Note that the NVM and host-loaded config are both in
+ // flash, so in principle we could just have a single NVM store that
+ // the host patches. The only reason we don't is that the NVM store
+ // is an image of our in-memory config structure, which is a native C
+ // struct, and we don't want the host to have to know the details of
+ // its byte layout, for obvious reasons. The host-loaded config, in
+ // contrast, uses the wire protocol format, which has a well-defined
+ // byte layout that's independent of the firmware version or the
+ // details of how the C compiler arranges the struct memory.)
+ if (!loadConfigFromFlash())
+ loadHostLoadedConfig();
// initialize the diagnostic LEDs
initDiagLEDs(cfg);
@@ -5127,6 +5294,9 @@
// create the plunger sensor interface
createPlunger();
+
+ // update the plunger reader's cached calibration data
+ plungerReader.onUpdateCal();
// set up the TLC5940 interface, if these chips are present
init_tlc5940(cfg);
@@ -5249,7 +5419,7 @@
// create the accelerometer object
Accel accel(MMA8451_SCL_PIN, MMA8451_SDA_PIN, MMA8451_I2C_ADDRESS, MMA8451_INT_PIN);
-
+
// last accelerometer report, in joystick units (we report the nudge
// acceleration via the joystick x & y axes, per the VP convention)
int x = 0, y = 0;
@@ -5266,8 +5436,7 @@
if (hc595 != 0)
hc595->enable(true);
- // start the LedWiz flash cycle timers
- wizPulseTimer.start();
+ // start the LedWiz flash cycle timer
wizCycleTimer.start();
// start the PWM update polling timer
@@ -5278,10 +5447,7 @@
for (;;)
{
// start the main loop timer for diagnostic data collection
- IF_DIAG(
- Timer mainLoopTimer;
- mainLoopTimer.start();
- )
+ IF_DIAG(mainLoopTimer.reset(); mainLoopTimer.start();)
// Process incoming reports on the joystick interface. The joystick
// "out" (receive) endpoint is used for LedWiz commands and our
@@ -5301,7 +5467,7 @@
IF_DIAG(
if (msgCount != 0)
{
- mainLoopMsgTime += lwt.read();
+ mainLoopMsgTime += lwt.read_us();
mainLoopMsgCount++;
}
)
@@ -5312,10 +5478,16 @@
// update PWM outputs
pollPwmUpdates();
+ // collect diagnostic statistics, checkpoint 0
+ IF_DIAG(mainLoopIterCheckpt[0] += mainLoopTimer.read_us();)
+
// send TLC5940 data updates if applicable
if (tlc5940 != 0)
tlc5940->send();
+ // collect diagnostic statistics, checkpoint 1
+ IF_DIAG(mainLoopIterCheckpt[1] += mainLoopTimer.read_us();)
+
// check for plunger calibration
if (calBtn != 0 && !calBtn->read())
{
@@ -5419,15 +5591,27 @@
}
}
+ // collect diagnostic statistics, checkpoint 2
+ IF_DIAG(mainLoopIterCheckpt[2] += mainLoopTimer.read_us();)
+
// read the plunger sensor
plungerReader.read();
+ // collect diagnostic statistics, checkpoint 3
+ IF_DIAG(mainLoopIterCheckpt[3] += mainLoopTimer.read_us();)
+
// update the ZB Launch Ball status
zbLaunchBall.update();
+ // collect diagnostic statistics, checkpoint 4
+ IF_DIAG(mainLoopIterCheckpt[4] += mainLoopTimer.read_us();)
+
// process button updates
processButtons(cfg);
+ // collect diagnostic statistics, checkpoint 5
+ IF_DIAG(mainLoopIterCheckpt[5] += mainLoopTimer.read_us();)
+
// send a keyboard report if we have new data
if (kbState.changed)
{
@@ -5444,6 +5628,9 @@
mediaState.changed = false;
}
+ // collect diagnostic statistics, checkpoint 6
+ IF_DIAG(mainLoopIterCheckpt[6] += mainLoopTimer.read_us();)
+
// flag: did we successfully send a joystick report on this round?
bool jsOK = false;
@@ -5518,6 +5705,9 @@
jsOKTimer.start();
}
+ // collect diagnostic statistics, checkpoint 7
+ IF_DIAG(mainLoopIterCheckpt[7] += mainLoopTimer.read_us();)
+
#ifdef DEBUG_PRINTF
if (x != 0 || y != 0)
printf("%d,%d\r\n", x, y);
@@ -5706,7 +5896,7 @@
// collect statistics on the main loop time, if desired
IF_DIAG(
- mainLoopIterTime += mainLoopTimer.read();
+ mainLoopIterTime += mainLoopTimer.read_us();
mainLoopIterCount++;
)
}