Arnaud VALLEY
Mirror with some correction
Dependencies: mbed FastIO FastPWM USBDevice
Diff: main.cpp
- Revision:
- 87:8d35c74403af
- Parent:
- 86:e30a1f60f783
- Child:
- 88:98bce687e6c0
--- a/main.cpp Fri Apr 21 18:50:37 2017 +0000
+++ b/main.cpp Tue May 09 05:48:37 2017 +0000
@@ -47,34 +47,48 @@
// have native support for this type of input; as with the nudge setup, you just
// have to set some options in VP to activate the plunger.
//
-// The Pinscape software supports optical sensors (the TAOS TSL1410R and TSL1412R
-// linear sensor arrays) as well as slide potentiometers. The specific equipment
-// that's supported, along with physical mounting and wiring details, can be found
-// in the Build Guide.
+// We support several sensor types:
//
-// Note that VP has built-in support for plunger devices like this one, but
-// some VP tables can't use it without some additional scripting work. The
-// Build Guide has advice on adjusting tables to add plunger support when
-// necessary.
+// - AEDR-8300-1K2 optical encoders. These are quadrature encoders with
+// reflective optical sensing and built-in lighting and optics. The sensor
+// is attached to the plunger so that it moves with the plunger, and slides
+// along a guide rail with a reflective pattern of regularly spaces bars
+// for the encoder to read. We read the plunger position by counting the
+// bars the sensor passes as it moves across the rail. This is the newest
+// option, and it's my current favorite because it's highly accurate,
+// precise, and fast, plus it's relatively inexpensive.
+//
+// - Slide potentiometers. There are slide potentioneters available with a
+// long enough travel distance (at least 85mm) to cover the plunger travel.
+// Attach the plunger to the potentiometer knob so that the moving the
+// plunger moves the pot knob. We sense the position by simply reading
+// the analog voltage on the pot brush. A pot with a "linear taper" (that
+// is, the resistance varies linearly with the position) is required.
+// This option is cheap, easy to set up, and works well.
//
-// For best results, the plunger sensor should be calibrated. The calibration
-// is stored in non-volatile memory on board the KL25Z, so it's only necessary
-// to do the calibration once, when you first install everything. (You might
-// also want to re-calibrate if you physically remove and reinstall the CCD
-// sensor or the mechanical plunger, since their alignment shift change slightly
-// when you put everything back together.) You can optionally install a
-// dedicated momentary switch or pushbutton to activate the calibration mode;
-// this is describe in the project documentation. If you don't want to bother
-// with the extra button, you can also trigger calibration using the Windows
-// setup software, which you can find on the Pinscape project page.
+// - VL6108X time-of-flight distance sensor. This is an optical distance
+// sensor that measures the distance to a nearby object (within about 10cm)
+// by measuring the travel time for reflected pulses of light. It's fairly
+// cheap and easy to set up, but I don't recommend it because it has very
+// low precision.
//
-// The calibration procedure is described in the project documentation. Briefly,
-// when you trigger calibration mode, the software will scan the CCD for about
-// 15 seconds, during which you should simply pull the physical plunger back
-// all the way, hold it for a moment, and then slowly return it to the rest
-// position. (DON'T just release it from the retracted position, since that
-// let it shoot forward too far. We want to measure the range from the park
-// position to the fully retracted position only.)
+// - TSL1410R/TSL1412R linear array optical sensors. These are large optical
+// sensors with the pixels arranged in a single row. The pixel arrays are
+// large enough on these to cover the travel distance of the plunger, so we
+// can set up the sensor near the plunger in such a way that the plunger
+// casts a shadow on the sensor. We detect the plunger position by finding
+// the edge of the sahdow in the image. The optics for this setup are very
+// simple since we don't need any lenses. This was the first sensor we
+// supported, and works very well, but unfortunately the sensor is difficult
+// to find now since it's been discontinued by the manufacturer.
+//
+// The v2 Build Guide has details on how to build and configure all of the
+// sensor options.
+//
+// Visual Pinball has built-in support for plunger devices like this one, but
+// some older VP tables (particularly for VP 9) can't use it without some
+// modifications to their scripting. The Build Guide has advice on how to
+// fix up VP tables to add plunger support when necessary.
//
// - Button input wiring. You can assign GPIO ports as inputs for physical
// pinball-style buttons, such as flipper buttons, a Start button, coin
@@ -107,28 +121,34 @@
// current handing. The Build Guide has a reference circuit design for this
// purpose that's simple and inexpensive to build.
//
-// - Enhanced LedWiz emulation with TLC5940 PWM controller chips. You can attach
-// external PWM controller chips for controlling device outputs, instead of using
-// the on-board GPIO ports as described above. The software can control a set of
-// daisy-chained TLC5940 chips. Each chip provides 16 PWM outputs, so you just
-// need two of them to get the full complement of 32 output ports of a real LedWiz.
-// You can hook up even more, though. Four chips gives you 64 ports, which should
-// be plenty for nearly any virtual pinball project. To accommodate the larger
-// supply of ports possible with the PWM chips, the controller software provides
-// a custom, extended version of the LedWiz protocol that can handle up to 128
-// ports. PC software designed only for the real LedWiz obviously won't know
-// about the extended protocol and won't be able to take advantage of its extra
-// capabilities, but the latest version of DOF (DirectOutput Framework) *does*
-// know the new language and can take full advantage. Older software will still
-// work, though - the new extensions are all backward compatible, so old software
-// that only knows about the original LedWiz protocol will still work, with the
-// obvious limitation that it can only access the first 32 ports.
+// - Enhanced LedWiz emulation with TLC5940 and/or TLC59116 PWM controller chips.
+// You can attach external PWM chips for controlling device outputs, instead of
+// using (or in addition to) the on-board GPIO ports as described above. The
+// software can control a set of daisy-chained TLC5940 or TLC59116 chips. Each
+// chip provides 16 PWM outputs, so you just need two of them to get the full
+// complement of 32 output ports of a real LedWiz. You can hook up even more,
+// though. Four chips gives you 64 ports, which should be plenty for nearly any
+// virtual pinball project.
//
// The Pinscape Expansion Board project (which appeared in early 2016) provides
// a reference hardware design, with EAGLE circuit board layouts, that takes full
// advantage of the TLC5940 capability. It lets you create a customized set of
// outputs with full PWM control and power handling for high-current devices
-// built in to the boards.
+// built in to the boards.
+//
+// To accommodate the larger supply of ports possible with the external chips,
+// the controller software provides a custom, extended version of the LedWiz
+// protocol that can handle up to 128 ports. Legacy PC software designed only
+// for the original LedWiz obviously can't use the extended protocol, and thus
+// can't take advantage of its extra capabilities, but the latest version of
+// DOF (DirectOutput Framework) *does* know the new language and can take full
+// advantage. Older software will still work, though - the new extensions are
+// all backwards compatible, so old software that only knows about the original
+// LedWiz protocol will still work, with the limitation that it can only access
+// the first 32 ports. In addition, we provide a replacement LEDWIZ.DLL that
+// creates virtual LedWiz units representing additional ports beyond the first
+// 32. This allows legacy LedWiz client software to address all ports by
+// making them think that you have several physical LedWiz units installed.
//
// - Night Mode control for output devices. You can connect a switch or button
// to the controller to activate "Night Mode", which disables feedback devices
@@ -222,6 +242,7 @@
#include "FreescaleIAP.h"
#include "crc32.h"
#include "TLC5940.h"
+#include "TLC59116.h"
#include "74HC595.h"
#include "nvm.h"
#include "TinyDigitalIn.h"
@@ -237,6 +258,7 @@
#include "nullSensor.h"
#include "barCodeSensor.h"
#include "distanceSensor.h"
+#include "tsl14xxSensor.h"
#define DECL_EXTERNS
@@ -646,17 +668,26 @@
// 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
+// To overcome some of these limitations, we also support several external
// 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.
+// a small number of GPIO pins to interface with the peripherals:
+//
+// - TLC5940 PWM controller chips. Each TLC5940 provides 16 ports with
+// 12-bit PWM, and multiple TLC5940 chips can be daisy-chained. The
+// chips connect via 5 GPIO pins, and since they're daisy-chainable,
+// one set of 5 pins can control any number of the chips. So this chip
+// effectively converts 5 GPIO pins into almost any number of PWM outputs.
+//
+// - TLC59116 PWM controller chips. These are similar to the TLC5940 but
+// a newer generation with an improved design. These use an I2C bus,
+// allowing up to 14 chips to be connected via 3 GPIO pins.
+//
+// - 74HC595 shift register chips. These provide 8 digital (on/off only)
+// outputs per chip. These need 4 GPIO pins, and like the other can be
+// daisy chained to add more outputs without using more GPIO pins. These
+// are advantageous for outputs that don't require PWM, since the data
+// transfer sizes are so much smaller. The expansion boards use these
+// for the chime board outputs.
//
// Direct GPIO output ports and peripheral controllers can be mixed and
// matched in one system. The assignment of pins to ports and the
@@ -735,7 +766,7 @@
// Gamma correction table for 8-bit input values
-static const uint8_t gamma[] = {
+static const uint8_t dof_to_gamma_8bit[] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2,
@@ -761,7 +792,7 @@
{
public:
LwGammaOut(LwOut *o) : out(o) { }
- virtual void set(uint8_t val) { out->set(gamma[val]); }
+ virtual void set(uint8_t val) { out->set(dof_to_gamma_8bit[val]); }
private:
LwOut *out;
@@ -903,10 +934,55 @@
uint8_t prv;
};
-
-
+//
+// TLC59116 interface object
+//
+TLC59116 *tlc59116 = 0;
+void init_tlc59116(Config &cfg)
+{
+ // Create the interface if any chips are enabled
+ if (cfg.tlc59116.chipMask != 0)
+ {
+ // set up the interface
+ tlc59116 = new TLC59116(
+ wirePinName(cfg.tlc59116.sda),
+ wirePinName(cfg.tlc59116.scl),
+ wirePinName(cfg.tlc59116.reset));
+
+ // initialize the chips
+ tlc59116->init();
+ }
+}
+
+// LwOut class for TLC59116 outputs. The 'addr' value in the constructor
+// is low 4 bits of the chip's I2C address; this is the part of the address
+// that's configurable per chip. 'port' is the output number on the chip
+// (0-15).
+//
+// Note that we don't need a separate gamma-corrected subclass for this
+// output type, since there's no loss of precision with the standard layered
+// gamma (it emits 8-bit values, and we take 8-bit inputs).
+class Lw59116Out: public LwOut
+{
+public:
+ Lw59116Out(uint8_t addr, uint8_t port) : addr(addr), port(port) { prv = 0; }
+ virtual void set(uint8_t val)
+ {
+ if (val != prv)
+ tlc59116->set(addr, port, prv = val);
+ }
+
+protected:
+ uint8_t addr;
+ uint8_t port;
+ uint8_t prv;
+};
+
+
+//
// 74HC595 interface object. Set this up with the port assignments in
// config.h.
+//
HC595 *hc595 = 0;
// initialize the 74HC595 interface
@@ -1276,13 +1352,22 @@
break;
case PortType74HC595:
- // 74HC595 port (if we don't have an HC595 controller object, or it's not a valid
- // output number, create a virtual port)
+ // 74HC595 port (if we don't have an HC595 controller object, or it's not
+ // a valid output number, create a virtual port)
if (hc595 != 0 && pin < cfg.hc595.nchips*8)
lwp = new Lw595Out(pin);
else
lwp = new LwVirtualOut();
break;
+
+ case PortTypeTLC59116:
+ // TLC59116 port. The pin number in the config encodes the chip address
+ // in the high 4 bits and the output number on the chip in the low 4 bits.
+ // There's no gamma-corrected version of this output handler, so we don't
+ // need to worry about that here; just use the layered gamma as needed.
+ if (tlc59116 != 0)
+ lwp = new Lw59116Out((pin >> 4) & 0x0F, pin & 0x0F);
+ break;
case PortTypeVirtual:
case PortTypeDisabled:
@@ -3907,10 +3992,8 @@
else
{
// The latch didn't stick, so PSU2 was still off at
- // our last check. Try pulsing it again in case PSU2
- // was turned on since the last check.
- psu2_status_set->write(1);
- psu2_state = 2;
+ // our last check. Return to idle state.
+ psu2_state = 1;
}
break;
@@ -4197,6 +4280,8 @@
saveConfigSucceededFlag = 0x40;
// start the followup timer
+ saveConfigFollowupTime = tFollowup;
+ saveConfigFollowupTimer.reset();
saveConfigFollowupTimer.start();
// if a reboot is pending, flag it
@@ -4336,10 +4421,10 @@
// the plunger sensor interface object
PlungerSensor *plungerSensor = 0;
-// wait for the plunger sensor to complete any outstanding read
+// wait for the plunger sensor to complete any outstanding DMA transfer
static void waitPlungerIdle(void)
{
- while (!plungerSensor->ready()) { }
+ while (plungerSensor->dmaBusy()) { }
}
// Create the plunger sensor based on the current configuration. If
@@ -4409,8 +4494,9 @@
break;
}
- // set the jitter filter
- plungerSensor->setJitterWindow(cfg.plunger.jitterWindow);
+ // initialize the config variables affecting the plunger
+ plungerSensor->onConfigChange(19, cfg);
+ plungerSensor->onConfigChange(20, cfg);
}
// Global plunger calibration mode flag
@@ -4473,9 +4559,6 @@
{
// not in a firing event yet
firing = 0;
-
- // no history yet
- histIdx = 0;
}
// Collect a reading from the plunger sensor. The main loop calls
@@ -4492,25 +4575,6 @@
PlungerReading r;
if (plungerSensor->read(r))
{
- // Pull the previous reading from the history
- const PlungerReading &prv = nthHist(0);
-
- // If the new reading is within 1ms of the previous reading,
- // ignore it. We require a minimum time between samples to
- // ensure that we have a usable amount of precision in the
- // denominator (the time interval) for calculating the plunger
- // velocity. The CCD sensor hardware takes about 2.5ms to
- // read, so it will never be affected by this, but other sensor
- // types don't all have the same hardware cycle time, so we need
- // to throttle them artificially. E.g., the potentiometer only
- // needs one ADC sample per reading, which only takes about 15us;
- // the quadrature sensor needs no time at all since it keeps
- // track of the position continuously via interrupts. We don't
- // need to check which sensor type we have here; we just ignore
- // readings until the minimum interval has passed.
- if (uint32_t(r.t - prv.t) < 1000UL)
- return;
-
// check for calibration mode
if (plungerCalMode)
{
@@ -4575,98 +4639,130 @@
r.pos = -JOYMAX;
}
- // Calculate the velocity from the second-to-last reading
- // to here, in joystick distance units per microsecond.
- // Note that we use the second-to-last reading rather than
- // the very last reading to give ourselves a little longer
- // time base. The time base is so short between consecutive
- // readings that the error bars in the position would be too
- // large.
+ // Look for a firing event - the user releasing the plunger and
+ // allowing it to shoot forward at full speed. Wait at least 5ms
+ // between samples for this, to help distinguish random motion
+ // from the rapid motion of a firing event.
//
- // For reference, the physical plunger velocity ranges up
- // to about 100,000 joystick distance units/sec. This is
- // based on empirical measurements. The typical time for
- // a real plunger to travel the full distance when released
- // from full retraction is about 85ms, so the average velocity
- // covering this distance is about 56,000 units/sec. The
- // peak is probably about twice that. In real-world units,
- // this translates to an average speed of about .75 m/s and
- // a peak of about 1.5 m/s.
+ // There's a trade-off in the choice of minimum sampling interval.
+ // The longer we wait, the more certain we can be of the trend.
+ // But if we wait too long, the user will perceive a delay. We
+ // also want to sample frequently enough to see the release motion
+ // at intermediate steps along the way, so the sampling has to be
+ // considerably faster than the whole travel time, which is about
+ // 25-50ms.
+ if (uint32_t(r.t - prv.t) < 5000UL)
+ return;
+
+ // assume that we'll report this reading as-is
+ z = r.pos;
+
+ // Firing event detection.
+ //
+ // A "firing event" is when the player releases the plunger from
+ // a retracted position, allowing it to shoot forward under the
+ // spring tension.
//
- // Note that we actually calculate the value here in units
- // per *microsecond* - the discussion above is in terms of
- // units/sec because that's more on a human scale. Our
- // choice of internal units here really isn't important,
- // 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 monitor the plunger motion for these events, and when they
+ // occur, we report an "idealized" version of the motion to the
+ // PC. The idealized version consists of a series of readings
+ // frozen at the fully retracted position for the whole duration
+ // of the forward travel, followed by a series of readings at the
+ // fully forward position for long enough for the plunger to come
+ // mostly to rest. The series of frozen readings aren't meant to
+ // be perceptible to the player - we try to keep them short enough
+ // that they're not apparent as delay. Instead, they're for the
+ // PC client software's benefit. PC joystick clients use polling,
+ // so they only see an unpredictable subset of the readings we
+ // send. The only way to be sure that the client sees a particular
+ // reading is to hold it for long enough that the client is sure to
+ // poll within the hold interval. In the case of the plunger
+ // firing motion, it's important that the client sees the *ends*
+ // of the travel - the fully retracted starting position in
+ // particular. If the PC client only polls for a sample while the
+ // plunger is somewhere in the middle of the travel, the PC will
+ // think that the firing motion *started* in that middle position,
+ // so it won't be able to model the right amount of momentum when
+ // the plunger hits the ball. We try to ensure that the PC sees
+ // the right starting point by reporting the starting point for
+ // extra time during the forward motion. By the same token, we
+ // want the PC to know that the plunger has moved all the way
+ // forward, rather than mistakenly thinking that it stopped
+ // somewhere in the middle of the travel, so we freeze at the
+ // forward position for a short time.
//
- // 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);
- int v = ((r.pos - prv2.pos) * 65536L)/int(r.t - prv2.t);
-
- // presume we'll report the latest instantaneous reading
- z = r.pos;
-
- // Check firing events
+ // To detect a firing event, we look for forward motion that's
+ // fast enough to be a firing event. To determine how fast is
+ // fast enough, we use a simple model of the plunger motion where
+ // the acceleration is constant. This is only an approximation,
+ // as the spring force actually varies with spring's compression,
+ // but it's close enough for our purposes here.
+ //
+ // Do calculations in fixed-point 2^48 scale with 64-bit ints.
+ // acc2 = acceleration/2 for 50ms release time, units of unit
+ // distances per microsecond squared, where the unit distance
+ // is the overall travel from the starting retracted position
+ // to the park position.
+ const int32_t acc2 = 112590; // 2^48 scale
switch (firing)
{
case 0:
- // Default state - not in a firing event.
-
- // If we have forward motion from a position that's retracted
- // beyond a threshold, enter phase 1. If we're not pulled back
- // far enough, don't bother with this, as a release wouldn't
- // be strong enough to require the synthetic firing treatment.
- if (v < 0 && r.pos > JOYMAX/6)
+ // Not in firing mode. If we're retracted a bit, and the
+ // motion is forward at a fast enough rate to look like a
+ // release, enter firing mode.
+ if (r.pos > JOYMAX/6)
{
- // enter firing phase 1
- firingMode(1);
-
- // if in calibration state 1 (at rest), switch to state 2 (not
- // at rest)
- if (calState == 1)
- calState = 2;
-
- // we don't have a freeze position yet, but note the start time
- f1.pos = 0;
- f1.t = r.t;
-
- // Figure the barrel spring "bounce" position in case we complete
- // the firing event. This is the amount that the forward momentum
- // of the plunger will compress the barrel spring at the peak of
- // the forward travel during the release. Assume that this is
- // linearly proportional to the starting retraction distance.
- // The barrel spring is about 1/6 the length of the main spring,
- // so figure it compresses by 1/6 the distance. (This is overly
- // simplistic and not very accurate, but it seems to give good
- // visual results, and that's all it's for.)
- f2.pos = -r.pos/6;
+ const uint32_t dt = uint32_t(r.t - prv.t);
+ const uint32_t dt2 = dt*dt; // dt^2
+ if (r.pos < prv.pos - int((prv.pos*acc2*uint64_t(dt2)) >> 48))
+ {
+ // Tentatively enter firing mode. Use the prior reading
+ // as the starting point, and freeze reports for now.
+ firingMode(1);
+ f0 = prv;
+ z = f0.pos;
+
+ // if in calibration state 1 (at rest), switch to
+ // state 2 (not at rest)
+ if (calState == 1)
+ calState = 2;
+ }
}
break;
case 1:
- // Phase 1 - acceleration. If we cross the zero point, trigger
- // the firing event. Otherwise, continue monitoring as long as we
- // see acceleration in the forward direction.
+ // Tentative firing mode: the plunger was moving forward
+ // at last check. To stay in firing mode, the plunger has
+ // to keep moving forward fast enough to look like it's
+ // moving under spring force. To figure out how fast is
+ // fast enough, we use a simple model where the acceleration
+ // is constant over the whole travel distance and the total
+ // travel time is 50ms. The acceleration actually varies
+ // slightly since it comes from the spring force, which
+ // is linear in the displacement; but the plunger spring is
+ // fairly compressed even when the plunger is all the way
+ // forward, so the difference in tension from one end of
+ // the travel to the other is fairly small, so it's not too
+ // far off to model it as constant. And the real travel
+ // time obviously isn't a constant, but all we need for
+ // that is an upper bound. So: we'll figure the time since
+ // we entered firing mode, and figure the distance we should
+ // have traveled to complete the trip within the maximum
+ // time allowed. If we've moved far enough, we'll stay
+ // in firing mode; if not, we'll exit firing mode. And if
+ // we cross the finish line while still in firing mode,
+ // we'll switch to the next phase of the firing event.
if (r.pos <= 0)
{
- // switch to the synthetic firing mode
+ // We crossed the park position. Switch to the second
+ // phase of the firing event, where we hold the reported
+ // position at the "bounce" position (where the plunger
+ // is all the way forward, compressing the barrel spring).
+ // We'll stick here long enough to ensure that the PC
+ // client (Visual Pinball or whatever) sees the reading
+ // and processes the release motion via the simulated
+ // physics.
firingMode(2);
- z = f2.pos;
-
- // note the start time for the firing phase
- f2.t = r.t;
// if in calibration mode, and we're in state 2 (moving),
// collect firing statistics for calibration purposes
@@ -4676,142 +4772,96 @@
// come to rest
calState = 0;
- // collect average firing time statistics in millseconds, if
- // it's in range (20 to 255 ms)
- int dt = uint32_t(r.t - f1.t)/1000UL;
- if (dt >= 20 && dt <= 255)
+ // collect average firing time statistics in millseconds,
+ // if it's in range (20 to 255 ms)
+ const int dt = uint32_t(r.t - f0.t)/1000UL;
+ if (dt >= 15 && dt <= 255)
{
calRlsTimeSum += dt;
calRlsTimeN += 1;
cfg.plunger.cal.tRelease = uint8_t(calRlsTimeSum / calRlsTimeN);
}
}
- }
- else if (v < vprv2)
- {
- // We're still accelerating, and we haven't crossed the zero
- // point yet - stay in phase 1. (Note that forward motion is
- // negative velocity, so accelerating means that the new
- // velocity is more negative than the previous one, which
- // is to say numerically less than - that's why the test
- // for acceleration is the seemingly backwards 'v < vprv'.)
-
- // If we've been accelerating for at least 20ms, we're probably
- // really doing a release. Jump back to the recent local
- // maximum where the release *really* started. This is always
- // a bit before we started seeing sustained accleration, because
- // the plunger motion for the first few milliseconds is too slow
- // for our sensor precision to reliably detect acceleration.
- if (f1.pos != 0)
- {
- // we have a reset point - freeze there
- z = f1.pos;
- }
- else if (uint32_t(r.t - f1.t) >= 20000UL)
- {
- // it's been long enough - set a reset point.
- f1.pos = z = histLocalMax(r.t, 50000UL);
- }
+
+ // Figure the "bounce" position as forward of the park
+ // position by 1/6 of the starting retraction distance.
+ // This simulates the momentum of the plunger compressing
+ // the barrel spring on the rebound. The barrel spring
+ // can compress by about 1/6 of the maximum retraction
+ // distance, so we'll simply treat its compression as
+ // proportional to the retraction. (It might be more
+ // realistic to use a slightly higher value here, maybe
+ // 1/4 or 1/3 or the retraction distance, capping it at
+ // a maximum of 1/6, because the real plunger probably
+ // compresses the barrel spring by 100% with less than
+ // 100% retraction. But that won't affect the physics
+ // meaningfully, just the animation, and the effect is
+ // small in any case.)
+ z = f0.pos = -f0.pos / 6;
+
+ // reset the starting time for this phase
+ f0.t = r.t;
}
else
{
- // We're not accelerating. Cancel the firing event.
- firingMode(0);
- calState = 1;
+ // check for motion since the start of the firing event
+ const uint32_t dt = uint32_t(r.t - f0.t);
+ const uint32_t dt2 = dt*dt; // dt^2
+ if (dt < 50000
+ && r.pos < f0.pos - int((f0.pos*acc2*uint64_t(dt2)) >> 48))
+ {
+ // It's moving fast enough to still be in a release
+ // motion. Continue reporting the start position, and
+ // stay in the first release phase.
+ z = f0.pos;
+ }
+ else
+ {
+ // It's not moving fast enough to be a release
+ // motion. Return to the default state.
+ firingMode(0);
+ calState = 1;
+ }
}
break;
case 2:
- // Phase 2 - start of synthetic firing event. Report the fake
- // bounce for 25ms. VP polls the joystick about every 10ms, so
- // this should be enough time to guarantee that VP sees this
- // report at least once.
- if (uint32_t(r.t - f2.t) < 25000UL)
+ // Firing mode, holding at forward compression position.
+ // Hold here for 25ms.
+ if (uint32_t(r.t - f0.t) < 25000)
{
- // report the bounce position
- z = f2.pos;
+ // stay here for now
+ z = f0.pos;
}
else
{
- // it's been long enough - switch to phase 3, where we
- // report the park position until the real plunger comes
- // to rest
+ // advance to the next phase, where we report the park
+ // position until the plunger comes to rest
firingMode(3);
z = 0;
-
- // set the start of the "stability window" to the rest position
- f3s.t = r.t;
- f3s.pos = 0;
-
- // set the start of the "retraction window" to the actual position
- f3r = r;
+
+ // remember when we started
+ f0.t = r.t;
}
break;
case 3:
- // Phase 3 - in synthetic firing event. Report the park position
- // until the plunger position stabilizes. Left to its own devices,
- // the plunger will usualy bounce off the barrel spring several
- // times before coming to rest, so we'll see oscillating motion
- // for a second or two. In the simplest case, we can aimply wait
- // for the plunger to stop moving for a short time. However, the
- // player might intervene by pulling the plunger back again, so
- // watch for that motion as well. If we're just bouncing freely,
- // we'll see the direction change frequently. If the player is
- // moving the plunger manually, the direction will be constant
- // for longer.
- if (v >= 0)
+ // Firing event, holding at park position. Stay here for
+ // a few moments so that the PC client can simulate the
+ // full release motion, then return to real readings.
+ if (uint32_t(r.t - f0.t) < 250000)
{
- // We're moving back (or standing still). If this has been
- // going on for a while, the user must have taken control.
- if (uint32_t(r.t - f3r.t) > 65000UL)
- {
- // user has taken control - cancel firing mode
- firingMode(0);
- break;
- }
+ // stay here a while longer
+ z = 0;
}
else
{
- // forward motion - reset retraction window
- f3r.t = r.t;
- }
-
- // Check if we're close to the last starting point. The joystick
- // positive axis range (0..4096) covers the retraction distance of
- // about 2.5", so 1" is about 1638 joystick units, hence 1/16" is
- // about 100 units.
- if (abs(r.pos - f3s.pos) < 100)
- {
- // It's at roughly the same position as the starting point.
- // Consider it stable if this has been true for 300ms.
- if (uint32_t(r.t - f3s.t) > 300000UL)
- {
- // we're done with the firing event
- firingMode(0);
- }
- else
- {
- // it's close to the last position but hasn't been
- // here long enough; stay in firing mode and continue
- // to report the park position
- z = 0;
- }
- }
- else
- {
- // It's not close enough to the last starting point, so use
- // this as a new starting point, and stay in firing mode.
- f3s = r;
- z = 0;
+ // it's been long enough - return to normal mode
+ firingMode(0);
}
break;
}
- // save the velocity reading for next time
- vprv2 = vprv;
- vprv = v;
-
// Check for auto-zeroing, if enabled
if ((cfg.plunger.autoZero.flags & PlungerAutoZeroEnabled) != 0)
{
@@ -4837,10 +4887,8 @@
}
}
- // add the new reading to the history
- hist[histIdx] = r;
- if (++histIdx >= countof(hist))
- histIdx = 0;
+ // this new reading becomes the previous reading for next time
+ prv = r;
}
}
@@ -4851,9 +4899,6 @@
return z;
}
- // get the timestamp of the current joystick report (microseconds)
- uint32_t getTimestamp() const { return nthHist(0).t; }
-
// Set calibration mode on or off
void setCalMode(bool f)
{
@@ -4942,6 +4987,12 @@
bool isFiring() { return firing == 3; }
private:
+ // current reported joystick reading
+ int z;
+
+ // previous reading
+ PlungerReading prv;
+
// Calibration state. During calibration mode, we watch for release
// events, to measure the time it takes to complete the release
// motion; and we watch for the plunger to come to reset after a
@@ -4978,105 +5029,21 @@
firing = m;
}
- // Find the most recent local maximum in the history data, up to
- // the given time limit.
- int histLocalMax(uint32_t tcur, uint32_t dt)
- {
- // start with the prior entry
- int idx = (histIdx == 0 ? countof(hist) : histIdx) - 1;
- int hi = hist[idx].pos;
-
- // scan backwards for a local maximum
- for (int n = countof(hist) - 1 ; n > 0 ; idx = (idx == 0 ? countof(hist) : idx) - 1)
- {
- // if this isn't within the time window, stop
- if (uint32_t(tcur - hist[idx].t) > dt)
- break;
-
- // if this isn't above the current hith, stop
- if (hist[idx].pos < hi)
- break;
-
- // this is the new high
- hi = hist[idx].pos;
- }
-
- // return the local maximum
- return hi;
- }
-
- // velocity at previous reading, and the one before that
- int vprv, vprv2;
-
- // Circular buffer of recent readings. We keep a short history
- // of readings to analyze during firing events. We can only identify
- // a firing event once it's somewhat under way, so we need a little
- // retrospective information to accurately determine after the fact
- // exactly when it started. We throttle our readings to no more
- // than one every 1ms, so we have at least N*1ms of history in this
- // array.
- PlungerReading hist[32];
- int histIdx;
-
- // get the nth history item (0=last, 1=2nd to last, etc)
- inline const PlungerReading &nthHist(int n) const
- {
- // histIdx-1 is the last written; go from there
- n = histIdx - 1 - n;
-
- // adjust for wrapping
- if (n < 0)
- n += countof(hist);
-
- // return the item
- return hist[n];
- }
-
// Firing event state.
//
- // 0 - Default state. We report the real instantaneous plunger
- // position to the joystick interface.
- //
- // 1 - Moving forward
+ // 0 - Default state: not in firing event. We report the true
+ // instantaneous plunger position to the joystick interface.
//
- // 2 - Accelerating
+ // 1 - Moving forward at release speed
//
- // 3 - Firing. We report the rest position for a minimum interval,
- // or until the real plunger comes to rest somewhere.
+ // 2 - Firing - reporting the bounce position
+ //
+ // 3 - Firing - reporting the park position
//
int firing;
- // Position/timestamp at start of firing phase 1. When we see a
- // sustained forward acceleration, we freeze joystick reports at
- // the recent local maximum, on the assumption that this was the
- // start of the release. If this is zero, it means that we're
- // monitoring accelerating motion but haven't seen it for long
- // enough yet to be confident that a release is in progress.
- PlungerReading f1;
-
- // Position/timestamp at start of firing phase 2. The position is
- // the fake "bounce" position we report during this phase, and the
- // timestamp tells us when the phase began so that we can end it
- // after enough time elapses.
- PlungerReading f2;
-
- // Position/timestamp of start of stability window during phase 3.
- // We use this to determine when the plunger comes to rest. We set
- // this at the beginning of phase 3, and then reset it when the
- // plunger moves too far from the last position.
- PlungerReading f3s;
-
- // Position/timestamp of start of retraction window during phase 3.
- // We use this to determine if the user is drawing the plunger back.
- // If we see retraction motion for more than about 65ms, we assume
- // that the user has taken over, because we should see forward
- // motion within this timeframe if the plunger is just bouncing
- // freely.
- PlungerReading f3r;
-
- // next Z value to report to the joystick interface (in joystick
- // distance units)
- int z;
+ // Starting position for current firing mode phase
+ PlungerReading f0;
};
// plunger reader singleton
@@ -5574,10 +5541,9 @@
// in a variable-dependent format.
configVarSet(data);
- // If updating the jitter window (variable 19), apply it immediately
- // to the plunger sensor object
- if (data[1] == 19)
- plungerSensor->setJitterWindow(cfg.plunger.jitterWindow);
+ // notify the plunger, so that it can update relevant variables
+ // dynamically
+ plungerSensor->onConfigChange(data[1], cfg);
}
else if (data[0] == 67)
{
@@ -5775,6 +5741,9 @@
// set up the TLC5940 interface, if these chips are present
init_tlc5940(cfg);
+ // initialize the TLC5916 interface, if these chips are present
+ init_tlc59116(cfg);
+
// set up 74HC595 interface, if these chips are present
init_hc595(cfg);
@@ -5787,7 +5756,7 @@
// start the TLC5940 refresh cycle clock
if (tlc5940 != 0)
tlc5940->start();
-
+
// Assume that nothing uses keyboard keys. We'll check for keyboard
// usage when initializing the various subsystems that can send keys
// (buttons, IR). If we find anything that does, we'll create the
@@ -5927,6 +5896,8 @@
tlc5940->enable(true);
if (hc595 != 0)
hc595->enable(true);
+ if (tlc59116 != 0)
+ tlc59116->enable(true);
// start the LedWiz flash cycle timer
wizCycleTimer.start();
@@ -5985,6 +5956,10 @@
// send TLC5940 data updates if applicable
if (tlc5940 != 0)
tlc5940->send();
+
+ // send TLC59116 data updates
+ if (tlc59116 != 0)
+ tlc59116->send();
// collect diagnostic statistics, checkpoint 1
IF_DIAG(mainLoopIterCheckpt[1] += mainLoopTimer.read_us();)
@@ -6255,6 +6230,8 @@
// the power first comes on.
if (tlc5940 != 0)
tlc5940->enable(false);
+ if (tlc59116 != 0)
+ tlc59116->enable(false);
if (hc595 != 0)
hc595->enable(false);
}
@@ -6263,7 +6240,7 @@
// if we have a reboot timer pending, check for completion
if (saveConfigFollowupTimer.isRunning()
- && saveConfigFollowupTimer.read() > saveConfigFollowupTime)
+ && saveConfigFollowupTimer.read_us() > saveConfigFollowupTime*1000000UL)
{
// if a reboot is pending, execute it now
if (saveConfigRebootPending)
@@ -6323,6 +6300,10 @@
// send TLC5940 data if necessary
if (tlc5940 != 0)
tlc5940->send();
+
+ // update TLC59116 outputs
+ if (tlc59116 != 0)
+ tlc59116->send();
// show a diagnostic flash every couple of seconds
if (diagTimer.read_us() > 2000000)
@@ -6364,10 +6345,9 @@
// Enable peripheral chips and update them with current output data
if (tlc5940 != 0)
- {
tlc5940->enable(true);
- tlc5940->update(true);
- }
+ if (tlc59116 != 0)
+ tlc59116->enable(true);
if (hc595 != 0)
{
hc595->enable(true);