Arnaud VALLEY
Mirror with some correction
Dependencies: mbed FastIO FastPWM USBDevice
Diff: main.cpp
- Revision:
- 77:0b96f6867312
- Parent:
- 76:7f5912b6340e
- Child:
- 78:1e00b3fa11af
--- a/main.cpp Fri Feb 03 20:50:02 2017 +0000
+++ b/main.cpp Fri Mar 17 22:02:08 2017 +0000
@@ -52,9 +52,10 @@
// that's supported, along with physical mounting and wiring details, can be found
// in the Build Guide.
//
-// Note 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.
+// 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.
//
// 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
@@ -75,12 +76,11 @@
// let it shoot forward too far. We want to measure the range from the park
// position to the fully retracted position only.)
//
-// - Button input wiring. 24 of the KL25Z's GPIO ports are mapped as digital inputs
-// for buttons and switches. You can wire each input to a physical pinball-style
-// button or switch, such as flipper buttons, Start buttons, coin chute switches,
-// tilt bobs, and service buttons. Each button can be configured to be reported
-// to the PC as a joystick button or as a keyboard key (you can select which key
-// is used for each button).
+// - Button input wiring. You can assign GPIO ports as inputs for physical
+// pinball-style buttons, such as flipper buttons, a Start button, coin
+// chute switches, tilt bobs, and service panel buttons. You can configure
+// each button input to report a keyboard key or joystick button press to
+// the PC when the physical button is pushed.
//
// - LedWiz emulation. The KL25Z can pretend to be an LedWiz device. This lets
// you connect feedback devices (lights, solenoids, motors) to GPIO ports on the
@@ -140,9 +140,26 @@
// power to the cabinet comes on, with a configurable delay timer. This feature
// is for TVs that don't turn themselves on automatically when first plugged in.
// To use this feature, you have to build some external circuitry to allow the
-// software to sense the power supply status, and you have to run wires to your
-// TV's on/off button, which requires opening the case on your TV. The Build
-// Guide has details on the necessary circuitry and connections to the TV.
+// software to sense the power supply status. The Build Guide has details
+// on the necessary circuitry. You can use this to switch your TV on via a
+// hardwired connection to the TV's "on" button, which requires taking the
+// TV apart to gain access to its internal wiring, or optionally via the IR
+// remote control transmitter feature below.
+//
+// - Infrared (IR) remote control receiver and transmitter. You can attach an
+// IR LED and/or an IR sensor (we recommend the TSOP384xx series) to make the
+// KL25Z capable of sending and/or receiving IR remote control signals. This
+// can be used with the TV ON feature above to turn your TV(s) on when the
+// system power comes on by sending the "on" command to them via IR, as though
+// you pressed the "on" button on the remote control. The sensor lets the
+// Pinscape software learn the IR codes from your existing remotes, in the
+// same manner as a handheld universal remote control, and the IR LED lets
+// it transmit learned codes. The sensor can also be used to receive codes
+// during normal operation and turn them into PC keystrokes; this lets you
+// access extra commands on the PC without adding more buttons to your
+// cabinet. The IR LED can also be used to transmit other codes when you
+// press selected cabinet buttons, allowing you to assign cabinet buttons
+// to send IR commands to your cabinet TV or other devices.
//
//
//
@@ -212,6 +229,9 @@
#include "potSensor.h"
#include "nullSensor.h"
#include "TinyDigitalIn.h"
+#include "IRReceiver.h"
+#include "IRTransmitter.h"
+#include "NewPwm.h"
#define DECL_EXTERNS
@@ -313,83 +333,73 @@
// left over after counting the static writable data and reserving space
// for a reasonable stack. I haven't looked at the mbed malloc to see why
// they're so stingy, but it appears from empirical testing that we can
-// create a static array up to about 9K before things get crashy.
-
-// Dynamic memory pool. We'll reserve space for all dynamic
-// allocations by creating a simple C array of bytes. The size
-// of this array is the maximum number of bytes we can allocate
-// with malloc or operator 'new'.
+// create a static array up to about 8K before things get crashy.
+
+
+// halt with a diagnostic display if we run out of memory
+void HaltOutOfMem()
+{
+ printf("\r\nOut Of Memory\r\n");
+ // halt with the diagnostic display (by looping forever)
+ for (;;)
+ {
+ diagLED(1, 0, 0);
+ wait_us(200000);
+ diagLED(1, 0, 1);
+ wait_us(200000);
+ }
+}
+
+#if 0//$$$
+// Memory pool. We allocate two blocks at fixed addresses: one for
+// the malloc heap, and one for the native stack.
//
-// The maximum safe size for this array is, in essence, the
-// amount of physical KL25Z RAM left over after accounting for
-// static data throughout the rest of the program, the run-time
-// stack, and any other space reserved for compiler or MCU
-// overhead. Unfortunately, it's not straightforward to
-// determine this analytically. The big complication is that
-// the minimum stack size isn't easily predictable, as the stack
-// grows according to what the program does. In addition, the
-// mbed platform tools don't give us detailed data on the
-// compiler/linker memory map. All we get is a generic total
-// RAM requirement, which doesn't necessarily account for all
-// overhead (e.g., gaps inserted to get proper alignment for
-// particular memory blocks).
+// We allocate the stack block at the very top of memory. This is what
+// the mbed startup code does anyway, so we don't actually ever move the
+// stack pointer into this area ourselves. The point of this block is
+// to reserve space with the linker, so that it won't put any other static
+// data here in this region.
//
-// A very rough estimate: the total RAM size reported by the
-// linker is about 3.5K (currently - that can obviously change
-// as the project evolves) out of 16K total. Assuming about a
-// 3K stack, that leaves in the ballpark of 10K. Empirically,
-// that seems pretty close. In testing, we start to see some
-// instability at 10K, while 9K seems safe. To be conservative,
-// we'll reduce this to 8K.
+// The heap block goes just below the stack block. This is a contiguous
+// block of bytes from which we allocate blocks for malloc() and 'operator
+// new' requests.
//
-// Our measured total usage in the base configuration (22 GPIO
-// output ports, TSL1410R plunger sensor) is about 4000 bytes.
-// A pretty fully decked-out configuration (121 output ports,
-// with 8 TLC5940 chips and 3 74HC595 chips, plus the TSL1412R
-// sensor with the higher pixel count, and all expansion board
-// features enabled) comes to about 6700 bytes. That leaves
-// us with about 1.5K free out of our 8K, so we still have a
-// little more headroom for future expansion.
-//
-// For comparison, the standard mbed malloc() runs out of
-// memory at about 6K. That's what led to this custom malloc:
-// we can just fit the base configuration into that 4K, but
-// it's not enough space for more complex setups. There's
-// still a little room for squeezing out unnecessary space
-// from the mbed library code, but at this point I'd prefer
-// to treat that as a last resort, since it would mean having
-// to fork private copies of the libraries.
-static const size_t XMALLOC_POOL_SIZE = 8*1024;
-static char xmalloc_pool[XMALLOC_POOL_SIZE];
+// WARNING! When adding static data, be sure to check the build statistics
+// to ensure that static data fits in the available RAM. The linker doesn't
+// seem to make such a check on its own, so you might not see an error if
+// added data pushes us past the 16K limit.
+
+// KL25Z address of top of RAM (one byte past end of RAM)
+const uint32_t TOP_OF_RAM = 0x20003000UL;
+
+// malloc pool size
+const size_t XMALLOC_POOL_SIZE = 8*1024;
+
+// stack size
+const size_t XMALLOC_STACK_SIZE = 2*1024;
+
+// figure the fixed locations of the malloc pool and stack: the stack goes
+// at the very top of RAM, and the malloc pool goes just below the stack
+const uint32_t XMALLOC_STACK_BASE = TOP_OF_RAM - XMALLOC_STACK_SIZE;
+const uint32_t XMALLOC_POOL_BASE = XMALLOC_STACK_BASE - XMALLOC_POOL_SIZE;
+
+// allocate the pools - use __attribute__((at)) to give them fixed addresses
+static char xmalloc_stack[XMALLOC_STACK_SIZE] __attribute__((at(XMALLOC_STACK_BASE)));
+static char xmalloc_pool[XMALLOC_POOL_SIZE] __attribute__((at(XMALLOC_POOL_BASE)));
+
+// malloc pool free pointer and space remaining
static char *xmalloc_nxt = xmalloc_pool;
static size_t xmalloc_rem = XMALLOC_POOL_SIZE;
+// allocate from our pool
void *xmalloc(size_t siz)
{
// align to a 4-byte increment
siz = (siz + 3) & ~3;
- // If insufficient memory is available, halt and show a fast red/purple
- // diagnostic flash. We don't want to return, since we assume throughout
- // the program that all memory allocations must succeed. Note that this
- // is generally considered bad programming practice in applications on
- // "real" computers, but for the purposes of this microcontroller app,
- // there's no point in checking for failed allocations individually
- // because there's no way to recover from them. It's better in this
- // context to handle failed allocations as fatal errors centrally. We
- // can't recover from these automatically, so we have to resort to user
- // intervention, which we signal with the diagnostic LED flashes.
+ // if we're out of memory, halt with a diagnostic display
if (siz > xmalloc_rem)
- {
- // halt with the diagnostic display (by looping forever)
- for (;;)
- {
- diagLED(1, 0, 0);
- wait_us(200000);
- diagLED(1, 0, 1);
- wait_us(200000);
- }
- }
+ HaltOutOfMem();
// get the next free location from the pool to return
char *ret = xmalloc_nxt;
@@ -401,8 +411,89 @@
// return the allocated block
return ret;
};
-
-// our malloc() replacement
+#elif 1//$$$
+// For our custom malloc, we take advantage of the known layout of the
+// mbed library memory management. The mbed library puts all of the
+// static read/write data at the low end of RAM; this includes the
+// initialized statics and the "ZI" (zero-initialized) statics. The
+// malloc heap starts just after the last static, growing upwards as
+// memory is allocated. The stack starts at the top of RAM and grows
+// downwards.
+//
+// To figure out where the free memory starts, we simply call the system
+// malloc() to make a dummy allocation the first time we're called, and
+// use the address it returns as the start of our free memory pool. The
+// first malloc() call presumably returns the lowest byte of the pool in
+// the compiler RTL's way of thinking, and from what we know about the
+// mbed heap layout, we know everything above this point should be free,
+// at least until we reach the lowest address used by the stack.
+//
+// The ultimate size of the stack is of course dynamic and unpredictable.
+// In testing, it appears that we currently need a little over 1K. To be
+// conservative, we'll reserve 2K for the stack, by taking it out of the
+// space at top of memory we consider fair game for malloc.
+//
+// Note that we could do this a little more low-level-ly if we wanted.
+// The ARM linker provides a pre-defined extern char[] variable named
+// Image$$RW_IRAM1$$ZI$$Limit, which is always placed just after the
+// last static data variable. In principle, this tells us the start
+// of the available malloc pool. However, in testing, it doesn't seem
+// safe to use this as the start of our malloc pool. I'm not sure why,
+// but probably something in the startup code (either in the C RTL or
+// the mbed library) is allocating from the pool before we get control.
+// So we won't use that approach. Besides, that would tie us even more
+// closely to the ARM compiler. With our malloc() probe approach, we're
+// at least portable to any compiler that uses the same basic memory
+// layout, with the heap above the statics and the stack at top of
+// memory; this isn't universal, but it's very typical.
+
+static char *xmalloc_nxt = 0;
+size_t xmalloc_rem = 0;
+void *xmalloc(size_t siz)
+{
+ if (xmalloc_nxt == 0)
+ {
+ xmalloc_nxt = (char *)malloc(4);
+ xmalloc_rem = 0x20003000UL - 2*1024 - uint32_t(xmalloc_nxt);
+ }
+
+ siz = (siz + 3) & ~3;
+ if (siz > xmalloc_rem)
+ HaltOutOfMem();
+
+ char *ret = xmalloc_nxt;
+ xmalloc_nxt += siz;
+ xmalloc_rem -= siz;
+
+ return ret;
+}
+#else //$$$
+extern char Image$$RW_IRAM1$$ZI$$Limit[]; // linker marker for top of ZI region
+static char *xmalloc_nxt = Image$$RW_IRAM1$$ZI$$Limit;
+const uint32_t xmallocMinStack = 2*1024;
+char *const TopOfRAM = (char *)0x20003000UL;
+uint16_t xmalloc_rem = uint16_t(TopOfRAM - Image$$RW_IRAM1$$ZI$$Limit - xmallocMinStack);
+void *xmalloc(size_t siz)
+{
+ // align to a 4-byte increment
+ siz = (siz + 3) & ~3;
+
+ // check to ensure we're leaving enough stack free
+ if (xmalloc_nxt + siz > TopOfRAM - xmallocMinStack)
+ HaltOutOfMem();
+
+ // get the next free location from the pool to return
+ char *ret = xmalloc_nxt;
+
+ // advance past the allocated memory
+ xmalloc_nxt += siz;
+ xmalloc_rem -= siz;
+
+ // return the allocated block
+ printf("malloc(%d) -> %lx\r\n", siz, ret);
+ return ret;
+}
+#endif//$$$
// Overload operator new to call our custom malloc. This ensures that
// all 'new' allocations throughout the program (including library code)
@@ -427,7 +518,8 @@
// ---------------------------------------------------------------------------
// utilities
-// floating point square of a number
+// int/float point square of a number
+inline int square(int x) { return x*x; }
inline float square(float x) { return x*x; }
// floating point rounding
@@ -439,10 +531,10 @@
// Extended verison of Timer class. This adds the ability to interrogate
// the running state.
//
-class Timer2: public Timer
+class ExtTimer: public Timer
{
public:
- Timer2() : running(false) { }
+ ExtTimer() : running(false) { }
void start() { running = true; Timer::start(); }
void stop() { running = false; Timer::stop(); }
@@ -455,13 +547,6 @@
// --------------------------------------------------------------------------
-//
-// Reboot timer. When we have a deferred reboot operation pending, we
-// set the target time and start the timer.
-Timer2 rebootTimer;
-long rebootTime_us;
-
-// --------------------------------------------------------------------------
//
// USB product version number
//
@@ -564,7 +649,8 @@
DigitalOut *ledR, *ledG, *ledB;
// Power on timer state for diagnostics. We flash the blue LED when
-// nothing else is going on. State 0-1 = off, 2-3 = on
+// nothing else is going on. State 0-1 = off, 2-3 = on blue. Also
+// show red when transmitting an LED signal, indicated by state 4.
uint8_t powerTimerDiagState = 0;
// Show the indicated pattern on the diagnostic LEDs. 0 is off, 1 is
@@ -578,7 +664,10 @@
// if turning everything off, use the power timer state instead,
// applying it to the blue LED
if (diagLEDState == 0)
- b = (powerTimerDiagState >= 2);
+ {
+ b = (powerTimerDiagState == 2 || powerTimerDiagState == 3);
+ r = (powerTimerDiagState == 4);
+ }
// set the new state
if (ledR != 0 && r != -1) ledR->write(!r);
@@ -592,7 +681,7 @@
diagLED(
diagLEDState & 0x01,
(diagLEDState >> 1) & 0x01,
- (diagLEDState >> 1) & 0x02);
+ (diagLEDState >> 2) & 0x01);
}
// check an output port assignment to see if it conflicts with
@@ -868,8 +957,10 @@
LwOut *out;
};
-// global night mode flag
-static bool nightMode = false;
+// Global night mode flag. To minimize overhead when reporting
+// the status, we set this to the status report flag bit for
+// night mode, 0x02, when engaged.
+static uint8_t nightMode = 0x00;
// Noisy output. This is a filter object that we layer on top of
// a physical pin output. This filter disables the port when night
@@ -1122,110 +1213,55 @@
0.925022f, 0.935504f, 0.946062f, 0.956696f, 0.967407f, 0.978194f, 0.989058f, 1.000000f
};
-// MyPwmOut - a slight customization of the base mbed PwmOut class. The
-// mbed version of PwmOut.write() resets the PWM cycle counter on every
-// update. That's problematic, because the counter reset interrupts the
-// cycle in progress, causing a momentary drop in brightness that's visible
-// to the eye if the output is connected to an LED or other light source.
-// This is especially noticeable when making gradual changes consisting of
-// many updates in a short time, such as a slow fade, because the light
-// visibly flickers on every step of the transition. This customized
-// version removes the cycle reset, which makes for glitch-free updates
-// and nice smooth fades.
+// Polled-update PWM output list
//
-// Initially, I thought the counter reset in the mbed code was simply a
-// bug. According to the KL25Z hardware reference, you update the duty
-// cycle by writing to the "compare values" (CvN) register. There's no
-// hint that you should reset the cycle counter, and indeed, the hardware
-// goes out of its way to allow updates mid-cycle (as we'll see shortly).
-// They went to lengths specifically so that you *don't* have to reset
-// that counter. And there's no comment in the mbed code explaining the
-// cycle reset, so it looked to me like something that must have been
-// added by someone who didn't read the manual carefully enough and didn't
-// test the result thoroughly enough to find the glitch it causes.
+// This is a workaround for a KL25Z hardware bug/limitation. The bug (more
+// about this below) is that we can't write to a PWM output "value" register
+// more than once per PWM cycle; if we do, outputs after the first are lost.
+// The value register controls the duty cycle, so it's what you have to write
+// if you want to update the brightness of an output.
//
-// After some experimentation, though, I've come to think the code was
-// added intentionally, as a workaround for a rather nasty KL25Z hardware
-// bug. Whoever wrote the code didn't add any comments explaning why it's
-// there, so we can't know for sure, but it does happen to work around the
-// bug, so it's a good bet the original programmer found the same hardware
-// problem and came up with the counter reset as an imperfect solution.
+// Our solution is to simply repeat all PWM updates periodically. If a write
+// is lost on one cycle, it'll eventually be applied on a subseuqent periodic
+// update. For low overhead, we do these repeat updates periodically during
+// the main loop.
//
-// We'll get to the KL25Z hardware bug shortly, but first we need to look at
-// how the hardware is *supposed* to work. The KL25Z is *supposed* to make
-// it super easy for software to do glitch-free updates of the duty cycle of
-// a PWM channel. With PWM hardware in general, you have to be careful to
-// update the duty cycle counter between grayscale cycles, beacuse otherwise
-// you might interrupt the cycle in progress and cause a brightness glitch.
-// The KL25Z TPM simplifies this with a "staging" register for the duty
-// cycle counter. At the end of each cycle, the TPM moves the value from
-// the staging register into its internal register that actually controls
-// the duty cycle. The idea is that the software can write a new value to
-// the staging register at any time, and the hardware will take care of
-// synchronizing the actual internal update with the grayscale cycle. In
-// principle, this frees the software of any special timing considerations
-// for PWM updates.
+// The mbed library has its own solution to this bug, but it creates a
+// separate problem of its own. The mbed solution is to write the value
+// register immediately, and then also reset the "count" register in the
+// TPM unit containing the output. The count reset truncates the current
+// PWM cycle, which avoids the hardware problem with more than one write per
+// cycle. The problem is that the truncated cycle causes visible flicker if
+// the output is connected to an LED. This is particularly noticeable during
+// fades, when we're updating the value register repeatedly and rapidly: an
+// attempt to fade from fully on to fully off causes rapid fluttering and
+// flashing rather than a smooth brightness fade.
//
-// Now for the bug. The staging register works as advertised, except for
-// one little detail: it seems to be implemented as a one-element queue
-// that won't accept a new write until the existing value has been read.
-// The read only happens at the start of the new cycle. So the effect is
-// that we can only write one update per cycle. Any writes after the first
-// are simply dropped, lost forever. That causes even worse problems than
-// the original glitch. For example, if we're doing a fade-out, the last
-// couple of updates in the fade might get lost, leaving the output slightly
-// on at the end, when it's supposed to be completely off.
-//
-// The mbed workaround of resetting the cycle counter fixes the lost-update
-// problem, but it causes the constant glitching during fades. So we need
-// a third way that works around the hardware problem without causing
-// update glitches.
+// The hardware bug is a case of good intentions gone bad. The hardware is
+// *supposed* to make it easy for software to avoid glitching during PWM
+// updates, by providing a staging register in front of the real value
+// register. The software actually writes to the staging register, which
+// holds updates until the end of the cycle, at which point the hardware
+// automatically moves the value from the staging register into the real
+// register. This ensures that the real register is always updated exactly
+// at a cycle boundary, which in turn ensures that there's no flicker when
+// values are updated. A great design - except that it doesn't quite work.
+// The problem is that the staging register actually seems to be implemented
+// as a one-element FIFO in "stop when full" mode. That is, when you write
+// the FIFO, it becomes full. When the cycle ends and the hardware reads it
+// to move the staged value into the real register, the FIFO becomes empty.
+// But if you try to write the FIFO twice before the hardware reads it and
+// empties it, the second write fails, leaving the first value in the queue.
+// There doesn't seem to be any way to clear the FIFO from software, so you
+// just have to wait for the cycle to end before writing another update.
+// That more or less defeats the purpose of the staging register, whose whole
+// point is to free software from worrying about timing considerations with
+// updates. It frees us of the need to align our timing on cycle boundaries,
+// but it leaves us with the need to limit writes to once per cycle.
//
-// Here's my solution: we basically implement our own staging register,
-// using the same principle as the hardware staging register, but hopefully
-// with an implementation that actually works! First, when we update a PWM
-// output, we won't actually write the value to the hardware register.
-// Instead, we'll just stash it internally, effectively in our own staging
-// register (but actually just a member variable of this object). Then
-// we'll periodically transfer these staged updates to the actual hardware
-// registers, being careful to do this no more than once per PWM cycle.
-// One way to do this would be to use an interrupt handler that fires at
-// the end of the PWM cycle, but that would be fairly complex because we
-// have many (up to 10) PWM channels. Instead, we'll just use polling:
-// we'll call a routine periodically in our main loop, and we'll transfer
-// updates for all of the channels that have been updated since the last
-// pass. We can get away with this simple polling approach because the
-// hardware design *partially* works: it does manage to free us from the
-// need to synchronize updates with the exact end of a PWM cycle. As long
-// as we do no more than one write per cycle, we're golden. That's easy
-// to accomplish, too: all we need to do is make sure that our polling
-// interval is slightly longer than the PWM period. That ensures that
-// we can never have two updates during one PWM cycle. It does mean that
-// we might have zero updates on some cycles, causing a one-cycle delay
-// before an update is actually put into effect, but that shouldn't ever
-// be noticeable since the cycles are so short. Specifically, we'll use
-// the mbed default 20ms PWM period, and we'll do our update polling
-// every 25ms.
-class LessGlitchyPwmOut: public PwmOut
-{
-public:
- LessGlitchyPwmOut(PinName pin) : PwmOut(pin) { }
-
- void write(float value)
- {
- // Update the counter without resetting the counter.
- //
- // NB: this causes problems if there are multiple writes in one
- // PWM cycle: the first write will be applied and later writes
- // during the same cycle will be lost. Callers must take care
- // to limit writes to one per cycle.
- *_pwm.CnV = uint32_t((*_pwm.MOD + 1) * value);
- }
-};
-
-
-// Collection of PwmOut objects to update on each polling cycle. The
-// KL25Z has 10 physical PWM channels, so we need at most 10 polled outputs.
+// So here we have our list of PWM outputs that need to be polled for updates.
+// The KL25Z hardware only has 10 PWM channels, so we only need a fixed set
+// of polled items.
static int numPolledPwm;
static class LwPwmOut *polledPwm[10];
@@ -1235,44 +1271,38 @@
public:
LwPwmOut(PinName pin, uint8_t initVal) : p(pin)
{
- // set the cycle time to 20ms
- p.period_ms(20);
-
- // add myself to the list of polled outputs for periodic updates
- if (numPolledPwm < countof(polledPwm))
+ // add myself to the list of polled outputs for periodic updates
+ if (numPolledPwm < countof(polledPwm))
polledPwm[numPolledPwm++] = this;
-
- // set the initial value, and an explicitly different previous value
- prv = ~initVal;
- set(initVal);
+
+ // set the initial value
+ set(initVal);
}
virtual void set(uint8_t val)
{
- // on set, just save the value for a later 'commit'
+ // save the new value
this->val = val;
+
+ // commit it to the hardware
+ commit();
}
// handle periodic update polling
void poll()
{
- // if the value has changed, commit it
- if (val != prv)
- {
- prv = val;
- commit(val);
- }
+ commit();
}
protected:
- virtual void commit(uint8_t v)
+ virtual void commit()
{
// write the current value to the PWM controller if it's changed
- p.write(dof_to_pwm[v]);
+ p.glitchFreeWrite(dof_to_pwm[val]);
}
- LessGlitchyPwmOut p;
- uint8_t val, prv;
+ NewPwmOut p;
+ uint8_t val;
};
// Gamma corrected PWM GPIO output. This works exactly like the regular
@@ -1287,10 +1317,10 @@
}
protected:
- virtual void commit(uint8_t v)
+ virtual void commit()
{
// write the current value to the PWM controller if it's changed
- p.write(dof_to_gamma_pwm[v]);
+ p.glitchFreeWrite(dof_to_gamma_pwm[val]);
}
};
@@ -1896,6 +1926,454 @@
hc595->update();
}
+// ---------------------------------------------------------------------------
+//
+// IR Remote Control transmitter & receiver
+//
+
+// receiver
+IRReceiver *ir_rx;
+
+// transmitter
+IRTransmitter *ir_tx;
+
+// Mapping from IR commands slots in the configuration to "virtual button"
+// numbers on the IRTransmitter's "virtual remote". To minimize RAM usage,
+// we only create virtual buttons on the transmitter object for code slots
+// that are configured for transmission, which includes slots used for TV
+// ON commands and slots that can be triggered by button presses. This
+// means that virtual button numbers won't necessarily match the config
+// slot numbers. This table provides the mapping:
+// IRConfigSlotToVirtualButton[n] = ir_tx virtual button number for
+// configuration slot n
+uint8_t IRConfigSlotToVirtualButton[MAX_IR_CODES];
+uint8_t IRAdHocSlot;
+
+// IR mode timer. In normal mode, this is the time since the last
+// command received; we use this to handle commands with timed effects,
+// such as sending a key to the PC. In learning mode, this is the time
+// since we activated learning mode, which we use to automatically end
+// learning mode if a decodable command isn't received within a reasonable
+// amount of time.
+Timer IRTimer;
+
+// IR Learning Mode. The PC enters learning mode via special function 65 12.
+// The states are:
+//
+// 0 -> normal operation (not in learning mode)
+// 1 -> learning mode; reading raw codes, no command read yet
+// 2 -> learning mode; command received, awaiting auto-repeat
+// 3 -> learning mode; done, command and repeat mode decoded
+//
+// When we enter learning mode, we reset IRTimer to keep track of how long
+// we've been in the mode. This allows the mode to time out if no code is
+// received within a reasonable time.
+uint8_t IRLearningMode = 0;
+
+// Learning mode command received. This stores the first decoded command
+// when in learning mode. For some protocols, we can't just report the
+// first command we receive, because we need to wait for an auto-repeat to
+// determine what format the remote uses for repeats. This stores the first
+// command while we await a repeat. This is necessary for protocols that
+// have "dittos", since some remotes for such protocols use the dittos and
+// some don't; the only way to find out is to read a repeat code and see if
+// it's a ditto or just a repeat of the full code.
+IRCommand learnedIRCode;
+
+// IR comkmand received, as a config slot index, 1..MAX_IR_CODES.
+// When we receive a command that matches one of our programmed commands,
+// we note the slot here. We also reset the IR timer so that we know how
+// long it's been since the command came in. This lets us handle commands
+// with timed effects, such as PC key input. Note that this is a 1-based
+// index; 0 represents no command.
+uint8_t IRCommandIn = 0;
+
+// "Toggle bit" of last command. Some IR protocols have a toggle bit
+// that distinguishes an auto-repeating key from a key being pressed
+// several times in a row. This records the toggle bit of the last
+// command we received.
+uint8_t lastIRToggle = 0;
+
+// Are we in a gap between successive key presses? When we detect that a
+// key is being pressed multiple times rather than auto-repeated (which we
+// can detect via a toggle bit in some protocols), we'll briefly stop sending
+// the associated key to the PC, so that the PC likewise recognizes the
+// distinct key press.
+uint8_t IRKeyGap = false;
+
+// initialize
+void init_IR(Config &cfg, bool &kbKeys)
+{
+ PinName pin;
+
+ // start the IR timer
+ IRTimer.start();
+
+ // if there's a transmitter, set it up
+ if ((pin = wirePinName(cfg.IR.emitter)) != NC)
+ {
+ // no virtual buttons yet
+ int nVirtualButtons = 0;
+ memset(IRConfigSlotToVirtualButton, 0xFF, sizeof(IRConfigSlotToVirtualButton));
+
+ // assign virtual buttons slots for TV ON codes
+ for (int i = 0 ; i < MAX_IR_CODES ; ++i)
+ {
+ if ((cfg.IRCommand[i].flags & IRFlagTVON) != 0)
+ IRConfigSlotToVirtualButton[i] = nVirtualButtons++;
+ }
+
+ // assign virtual buttons for codes that can be triggered by
+ // real button inputs
+ for (int i = 0 ; i < MAX_BUTTONS ; ++i)
+ {
+ // get the button
+ ButtonCfg &b = cfg.button[i];
+
+ // check the unshifted button
+ int c = b.IRCommand - 1;
+ if (c >= 0 && c < MAX_IR_CODES
+ && IRConfigSlotToVirtualButton[c] == 0xFF)
+ IRConfigSlotToVirtualButton[c] = nVirtualButtons++;
+
+ // check the shifted button
+ c = b.IRCommand2 - 1;
+ if (c >= 0 && c < MAX_IR_CODES
+ && IRConfigSlotToVirtualButton[c] == 0xFF)
+ IRConfigSlotToVirtualButton[c] = nVirtualButtons++;
+ }
+
+ // allocate an additional virtual button for transmitting ad hoc
+ // codes, such as for the "send code" USB API function
+ IRAdHocSlot = nVirtualButtons++;
+
+ // create the transmitter
+ ir_tx = new IRTransmitter(pin, nVirtualButtons);
+
+ // program the commands into the virtual button slots
+ for (int i = 0 ; i < MAX_IR_CODES ; ++i)
+ {
+ // if this slot is assigned to a virtual button, program it
+ int vb = IRConfigSlotToVirtualButton[i];
+ if (vb != 0xFF)
+ {
+ IRCommandCfg &cb = cfg.IRCommand[i];
+ uint64_t code = cb.code.lo | (uint64_t(cb.code.hi) << 32);
+ bool dittos = (cb.flags & IRFlagDittos) != 0;
+ ir_tx->programButton(vb, cb.protocol, dittos, code);
+ }
+ }
+ }
+
+ // if there's a receiver, set it up
+ if ((pin = wirePinName(cfg.IR.sensor)) != NC)
+ {
+ // create the receiver
+ ir_rx = new IRReceiver(pin, 32);
+
+ // connect the transmitter (if any) to the receiver, so that
+ // the receiver can suppress reception of our own transmissions
+ ir_rx->setTransmitter(ir_tx);
+
+ // enable it
+ ir_rx->enable();
+
+ // Check the IR command slots to see if any slots are configured
+ // to send a keyboard key on receiving an IR command. If any are,
+ // tell the caller that we need a USB keyboard interface.
+ for (int i = 0 ; i < MAX_IR_CODES ; ++i)
+ {
+ IRCommandCfg &cb = cfg.IRCommand[i];
+ if (cb.protocol != 0
+ && (cb.keytype == BtnTypeKey || cb.keytype == BtnTypeMedia))
+ {
+ kbKeys = true;
+ break;
+ }
+ }
+ }
+}
+
+// Press or release a button with an assigned IR function. 'cmd'
+// is the command slot number (1..MAX_IR_CODES) assigned to the button.
+void IR_buttonChange(uint8_t cmd, bool pressed)
+{
+ // only proceed if there's an IR transmitter attached
+ if (ir_tx != 0)
+ {
+ // adjust the command slot to a zero-based index
+ int slot = cmd - 1;
+
+ // press or release the virtual button
+ ir_tx->pushButton(IRConfigSlotToVirtualButton[slot], pressed);
+ }
+}
+
+// Process IR input
+void process_IR(Config &cfg, USBJoystick &js)
+{
+ // if there's no IR receiver attached, there's nothing to do
+ if (ir_rx == 0)
+ return;
+
+ // Time out any received command
+ if (IRCommandIn != 0)
+ {
+ // Time out inter-key gap mode after 30ms; time out all
+ // commands after 100ms.
+ uint32_t t = IRTimer.read_us();
+ if (t > 100000)
+ IRCommandIn = 0;
+ else if (t > 30000)
+ IRKeyGap = false;
+ }
+
+ // Check if we're in learning mode
+ if (IRLearningMode != 0)
+ {
+ // Learning mode. Read raw inputs from the IR sensor and
+ // forward them to the PC via USB reports, up to the report
+ // limit.
+ const int nmax = USBJoystick::maxRawIR;
+ uint16_t raw[nmax];
+ int n;
+ for (n = 0 ; n < nmax && ir_rx->processOne(raw[n]) ; ++n) ;
+
+ // if we read any raw samples, report them
+ if (n != 0)
+ js.reportRawIR(n, raw);
+
+ // check for a command
+ IRCommand c;
+ if (ir_rx->readCommand(c))
+ {
+ // check the current learning state
+ switch (IRLearningMode)
+ {
+ case 1:
+ // Initial state, waiting for the first decoded command.
+ // This is it.
+ learnedIRCode = c;
+
+ // Check if we need additional information. If the
+ // protocol supports dittos, we have to wait for a repeat
+ // to see if the remote actually uses the dittos, since
+ // some implementations of such protocols use the dittos
+ // while others just send repeated full codes. Otherwise,
+ // all we need is the initial code, so we're done.
+ IRLearningMode = (c.hasDittos ? 2 : 3);
+ break;
+
+ case 2:
+ // Code received, awaiting auto-repeat information. If
+ // the protocol has dittos, check to see if we got a ditto:
+ //
+ // - If we received a ditto in the same protocol as the
+ // prior command, the remote uses dittos.
+ //
+ // - If we received a repeat of the prior command (not a
+ // ditto, but a repeat of the full code), the remote
+ // doesn't use dittos even though the protocol supports
+ // them.
+ //
+ // - Otherwise, it's not an auto-repeat at all, so we
+ // can't decide one way or the other on dittos: start
+ // over.
+ if (c.proId == learnedIRCode.proId
+ && c.hasDittos
+ && c.ditto)
+ {
+ // success - the remote uses dittos
+ IRLearningMode = 3;
+ }
+ else if (c.proId == learnedIRCode.proId
+ && c.hasDittos
+ && !c.ditto
+ && c.code == learnedIRCode.code)
+ {
+ // success - it's a repeat of the last code, so
+ // the remote doesn't use dittos even though the
+ // protocol supports them
+ learnedIRCode.hasDittos = false;
+ IRLearningMode = 3;
+ }
+ else
+ {
+ // It's not a ditto and not a full repeat of the
+ // last code, so it's either a new key, or some kind
+ // of multi-code key encoding that we don't recognize.
+ // We can't use this code, so start over.
+ IRLearningMode = 1;
+ }
+ break;
+ }
+
+ // If we ended in state 3, we've successfully decoded
+ // the transmission. Report the decoded data and terminate
+ // learning mode.
+ if (IRLearningMode == 3)
+ {
+ // figure the flags:
+ // 0x02 -> dittos
+ uint8_t flags = 0;
+ if (learnedIRCode.hasDittos)
+ flags |= 0x02;
+
+ // report the code
+ js.reportIRCode(learnedIRCode.proId, flags, learnedIRCode.code);
+
+ // exit learning mode
+ IRLearningMode = 0;
+ }
+ }
+
+ // time out of IR learning mode if it's been too long
+ if (IRLearningMode != 0 && IRTimer.read_us() > 10000000L)
+ {
+ // report the termination by sending a raw IR report with
+ // zero data elements
+ js.reportRawIR(0, 0);
+
+
+ // cancel learning mode
+ IRLearningMode = 0;
+ }
+ }
+ else
+ {
+ // Not in learning mode. We don't care about the raw signals;
+ // just run them through the protocol decoders.
+ ir_rx->process();
+
+ // Check for decoded commands. Keep going until all commands
+ // have been read.
+ IRCommand c;
+ while (ir_rx->readCommand(c))
+ {
+ // We received a decoded command. Determine if it's a repeat,
+ // and if so, try to determine whether it's an auto-repeat (due
+ // to the remote key being held down) or a distinct new press
+ // on the same key as last time. The distinction is significant
+ // because it affects the auto-repeat behavior of the PC key
+ // input. An auto-repeat represents a key being held down on
+ // the remote, which we want to translate to a (virtual) key
+ // being held down on the PC keyboard; a distinct key press on
+ // the remote translates to a distinct key press on the PC.
+ //
+ // It can only be a repeat if there's a prior command that
+ // hasn't timed out yet, so start by checking for a previous
+ // command.
+ bool repeat = false, autoRepeat = false;
+ if (IRCommandIn != 0)
+ {
+ // We have a command in progress. Check to see if the
+ // new command is a repeat of the previous command. Check
+ // first to see if it's a "ditto", which explicitly represents
+ // an auto-repeat of the last command.
+ IRCommandCfg &cmdcfg = cfg.IRCommand[IRCommandIn - 1];
+ if (c.ditto)
+ {
+ // We received a ditto. Dittos are always auto-
+ // repeats, so it's an auto-repeat as long as the
+ // ditto is in the same protocol as the last command.
+ // If the ditto is in a new protocol, the ditto can't
+ // be for the last command we saw, because a ditto
+ // never changes protocols from its antecedent. In
+ // such a case, we must have missed the antecedent
+ // command and thus don't know what's being repeated.
+ repeat = autoRepeat = (c.proId == cmdcfg.protocol);
+ }
+ else
+ {
+ // It's not a ditto. The new command is a repeat if
+ // it matches the protocol and command code of the
+ // prior command.
+ repeat = (c.proId == cmdcfg.protocol
+ && uint32_t(c.code) == cmdcfg.code.lo
+ && uint32_t(c.code >> 32) == cmdcfg.code.hi);
+
+ // If the command is a repeat, try to determine whether
+ // it's an auto-repeat or a new press on the same key.
+ // If the protocol uses dittos, it's definitely a new
+ // key press, because an auto-repeat would have used a
+ // ditto. For a protocol that doesn't use dittos, both
+ // an auto-repeat and a new key press just send the key
+ // code again, so we can't tell the difference based on
+ // that alone. But if the protocol has a toggle bit, we
+ // can tell by the toggle bit value: a new key press has
+ // the opposite toggle value as the last key press, while
+ // an auto-repeat has the same toggle. Note that if the
+ // protocol doesn't use toggle bits, the toggle value
+ // will always be the same, so we'll simply always treat
+ // any repeat as an auto-repeat. Many protocols simply
+ // provide no way to distinguish the two, so in such
+ // cases it's consistent with the native implementations
+ // to treat any repeat as an auto-repeat.
+ autoRepeat =
+ repeat
+ && !(cmdcfg.flags & IRFlagDittos)
+ && c.toggle == lastIRToggle;
+ }
+ }
+
+ // Check to see if it's a repeat of any kind
+ if (repeat)
+ {
+ // It's a repeat. If it's not an auto-repeat, it's a
+ // new distinct key press, so we need to send the PC a
+ // momentary gap where we're not sending the same key,
+ // so that the PC also recognizes this as a distinct
+ // key press event.
+ if (!autoRepeat)
+ IRKeyGap = true;
+
+ // restart the key-up timer
+ IRTimer.reset();
+ }
+ else if (c.ditto)
+ {
+ // It's a ditto, but not a repeat of the last command.
+ // But a ditto doesn't contain any information of its own
+ // on the command being repeated, so given that it's not
+ // our last command, we can't infer what command the ditto
+ // is for and thus can't make sense of it. We have to
+ // simply ignore it and wait for the sender to start with
+ // a full command for a new key press.
+ IRCommandIn = 0;
+ }
+ else
+ {
+ // It's not a repeat, so the last command is no longer
+ // in effect (regardless of whether we find a match for
+ // the new command).
+ IRCommandIn = 0;
+
+ // Check to see if we recognize the new command, by
+ // searching for a match in our learned code list.
+ for (int i = 0 ; i < MAX_IR_CODES ; ++i)
+ {
+ // if the protocol and command code from the code
+ // list both match the input, it's a match
+ IRCommandCfg &cmdcfg = cfg.IRCommand[i];
+ if (cmdcfg.protocol == c.proId
+ && cmdcfg.code.lo == uint32_t(c.code)
+ && cmdcfg.code.hi == uint32_t(c.code >> 32))
+ {
+ // Found it! Make this the last command, and
+ // remember the starting time.
+ IRCommandIn = i + 1;
+ lastIRToggle = c.toggle;
+ IRTimer.reset();
+
+ // no need to keep searching
+ break;
+ }
+ }
+ }
+ }
+ }
+}
+
// ---------------------------------------------------------------------------
//
@@ -2089,9 +2567,6 @@
// initialize the button inputs
void initButtons(Config &cfg, bool &kbKeys)
{
- // presume we'll find no keyboard keys
- kbKeys = false;
-
// presume no shift key
shiftButton.index = -1;
@@ -2208,7 +2683,109 @@
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // D0-DF
0, 0, 1, 0, 0, 0, 0, 0, 0, 2, 4, 0, 0, 0, 0, 0, // E0-EF
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 // F0-FF
- };
+};
+
+// Keyboard key/joystick button state. processButtons() uses this to
+// build the set of key presses to report to the PC based on the logical
+// states of the button iputs.
+struct KeyState
+{
+ KeyState()
+ {
+ // zero all members
+ memset(this, 0, sizeof(*this));
+ }
+
+ // Keyboard media keys currently pressed. This is a bit vector in
+ // the format used in our USB keyboard reports (see USBJoystick.cpp).
+ uint8_t mediakeys;
+
+ // Keyboard modifier (shift) keys currently pressed. This is a bit
+ // vector in the format used in our USB keyboard reports (see
+ // USBJoystick.cpp).
+ uint8_t modkeys;
+
+ // Regular keyboard keys currently pressed. Each element is a USB
+ // key code, or 0 for empty slots. Note that the USB report format
+ // theoretically allows a flexible size limit, but the Windows KB
+ // drivers have a fixed limit of 6 simultaneous keys (and won't
+ // accept reports with more), so there's no point in making this
+ // flexible; we'll just use the fixed size dictated by Windows.
+ uint8_t keys[7];
+
+ // number of valid entries in keys[] array
+ int nkeys;
+
+ // Joystick buttons pressed, as a bit vector. Bit n (1 << n)
+ // represents joystick button n, n in 0..31, with 0 meaning
+ // unpressed and 1 meaning pressed.
+ uint32_t js;
+
+
+ // Add a key press. 'typ' is the button type code (ButtonTypeXxx),
+ // and 'val' is the value (the meaning of which varies by type code).
+ void addKey(uint8_t typ, uint8_t val)
+ {
+ // add the key according to the type
+ switch (typ)
+ {
+ case BtnTypeJoystick:
+ // joystick button
+ js |= (1 << (val - 1));
+ break;
+
+ case BtnTypeKey:
+ // Keyboard key. The USB keyboard report encodes regular
+ // keys and modifier keys separately, so we need to check
+ // which type we have. Note that past versions mapped the
+ // Keyboard Volume Up, Keyboard Volume Down, and Keyboard
+ // Mute keys to the corresponding Media keys. We no longer
+ // do this; instead, we have the separate BtnTypeMedia for
+ // explicitly using media keys if desired.
+ if (val >= 0xE0 && val <= 0xE7)
+ {
+ // It's a modifier key. These are represented in the USB
+ // reports with a bit mask. We arrange the mask bits in
+ // the same order as the scan codes, so we can figure the
+ // appropriate bit with a simple shift.
+ modkeys |= (1 << (val - 0xE0));
+ }
+ else
+ {
+ // It's a regular key. Make sure it's not already in the
+ // list, and that the list isn't full. If neither of these
+ // apply, add the key to the key array.
+ if (nkeys < 7)
+ {
+ bool found = false;
+ for (int i = 0 ; i < nkeys ; ++i)
+ {
+ if (keys[i] == val)
+ {
+ found = true;
+ break;
+ }
+ }
+ if (!found)
+ keys[nkeys++] = val;
+ }
+ }
+ break;
+
+ case BtnTypeMedia:
+ // Media control key. The media keys are mapped in the USB
+ // report to bits, whereas the key codes are specified in the
+ // config with their USB usage numbers. E.g., the config val
+ // for Media Next Track is 0xB5, but we encode this in the USB
+ // report as bit 0x08. The mediaKeyMap[] table translates
+ // from the USB usage number to the mask bit. If the key isn't
+ // among the subset we support, the mapped bit will be zero, so
+ // the "|=" will have no effect and the key will be ignored.
+ mediakeys |= mediaKeyMap[val];
+ break;
+ }
+ }
+};
// Process the button state. This sets up the joystick, keyboard, and
@@ -2217,16 +2794,8 @@
// mapped to special device functions (e.g., Night Mode).
void processButtons(Config &cfg)
{
- // start with an empty list of USB key codes
- uint8_t modkeys = 0;
- uint8_t keys[7] = { 0, 0, 0, 0, 0, 0, 0 };
- int nkeys = 0;
-
- // clear the joystick buttons
- uint32_t newjs = 0;
-
- // start with no media keys pressed
- uint8_t mediakeys = 0;
+ // key state
+ KeyState ks;
// calculate the time since the last run
uint32_t dt = buttonTimer.read_us();
@@ -2275,6 +2844,9 @@
ButtonState *bs = buttonState;
for (int i = 0 ; i < nButtons ; ++i, ++bs)
{
+ // get the config entry for the button
+ ButtonCfg *bc = &cfg.button[bs->cfgIndex];
+
// Check the button type:
// - shift button
// - pulsed button
@@ -2355,45 +2927,78 @@
// not a pulse switch - the logical state is the same as the physical state
bs->logState = bs->physState;
}
+
+ // Determine if we're going to use the shifted version of the
+ // button. We're using the shifted version if the shift button
+ // is down AND the button has ANY shifted meaning - a key assignment,
+ // a Night Mode toggle assignment, or an IR code. If the button
+ // doesn't have any meaning at all in shifted mode, the base version
+ // of the button applies whether or not the shift button is down.
+ //
+ // Note that the test for Night Mode is a bit tricky. The shifted
+ // version of the button is the Night Mode toggle if the button matches
+ // the Night Mode button index, AND its flags are set with "toggle
+ // mode ON" (bit 0x02 is on) and "switch mode OFF" (bit 0x01 is off).
+ // That means the button flags & 0x03 must equal 0x02.
+ bool useShift =
+ (shiftButton.state != 0
+ && (bc->typ2 != BtnTypeNone
+ || bc->IRCommand2 != 0
+ || (cfg.nightMode.btn == i+1 && (cfg.nightMode.flags & 0x03) == 0x02)));
+
+ // If we're using the shift function, and no other button has used
+ // the shift function yet (shift state 1: "shift button is down but
+ // no one has used the shift function yet"), then we've "consumed"
+ // the shift button press (so go to shift state 2: "shift button has
+ // been used by some other button press that has a shifted meaning").
+ if (useShift && shiftButton.state == 1)
+ shiftButton.state = 2;
// carry out any edge effects from buttons changing states
if (bs->logState != bs->prevLogState)
{
- // check for special key transitions
+ // check to see if this is the Night Mode button
if (cfg.nightMode.btn == i + 1)
{
- // Check the switch type in the config flags. If flag 0x01 is set,
- // it's a persistent on/off switch, so the night mode state simply
- // follows the current state of the switch. Otherwise, it's a
- // momentary button, so each button push (i.e., each transition from
- // logical state OFF to ON) toggles the current night mode state.
+ // Check the switch type in the config flags. If flag 0x01 is
+ // set, it's a persistent on/off switch, so the night mode
+ // state simply tracks the current state of the switch.
+ // Otherwise, it's a momentary button, so each button push
+ // (i.e., each transition from logical state OFF to ON) toggles
+ // the night mode state.
+ //
+ // Note that the "shift" flag (0x02) has no effect in switch
+ // mode. Shifting only works for toggle mode.
if (cfg.nightMode.flags & 0x01)
{
- // on/off switch - when the button changes state, change
- // night mode to match the new state
+ // It's an on/off switch. Night mode simply tracks the
+ // current switch state.
setNightMode(bs->logState);
}
else
{
- // Momentary switch - toggle the night mode state when the
- // physical button is pushed (i.e., when its logical state
- // transitions from OFF to ON).
+ // It's a momentary toggle switch. Toggle the night mode
+ // state on each distinct press of the button: that is,
+ // whenever the button's logical state transitions from
+ // OFF to ON.
//
- // In momentary mode, night mode flag 0x02 makes it the
- // shifted version of the button. In this case, only
- // proceed if the shift button is pressed.
- bool pressed = bs->logState;
+ // The "shift" flag (0x02) tells us whether night mode is
+ // assigned to the shifted or unshifted version of the
+ // button.
+ bool pressed;
if ((cfg.nightMode.flags & 0x02) != 0)
{
- // if the shift button is pressed but hasn't been used
- // as a shift yet, mark it as used, so that it doesn't
- // also generate its own key code on release
- if (shiftButton.state == 1)
- shiftButton.state = 2;
-
- // if the shift button isn't even pressed
- if (shiftButton.state == 0)
- pressed = false;
+ // Shift bit is set - night mode is assigned to the
+ // shifted version of the button. This is a Night
+ // Mode toggle only if the Shift button is pressed.
+ pressed = (shiftButton.state != 0);
+ }
+ else
+ {
+ // No shift bit - night mode is assigned to the
+ // regular unshifted button. The button press only
+ // applies if the Shift button is NOT pressed.
+ pressed = (shiftButton.state == 0);
}
// if it's pressed (even after considering the shift mode),
@@ -2403,6 +3008,11 @@
}
}
+ // press or release IR virtual keys on key state changes
+ uint8_t irc = useShift ? bc->IRCommand2 : bc->IRCommand;
+ if (irc != 0)
+ IR_buttonChange(irc, bs->logState);
+
// remember the new state for comparison on the next run
bs->prevLogState = bs->logState;
}
@@ -2413,131 +3023,53 @@
{
// Get the key type and code. Start by assuming that we're
// going to use the normal unshifted meaning.
- ButtonCfg *bc = &cfg.button[bs->cfgIndex];
- uint8_t typ = bc->typ;
- uint8_t val = bc->val;
-
- // If the shift button is down, check for a shifted meaning.
- if (shiftButton.state)
+ uint8_t typ, val;
+ if (useShift)
{
- // assume there's no shifted meaning
- bool useShift = false;
-
- // If the button has a shifted meaning, use that. The
- // meaning might be a keyboard key or joystick button,
- // but it could also be as the Night Mode toggle.
- //
- // The condition to check if it's the Night Mode toggle
- // is a little complicated. First, the easy part: our
- // button index has to match the Night Mode button index.
- // Now the hard part: the Night Mode button flags have
- // to be set to 0x01 OFF and 0x02 ON: toggle mode (not
- // switch mode, 0x01), and shift mode, 0x02. So AND the
- // flags with 0x03 to get these two bits, and check that
- // the result is 0x02, meaning that only shift mode is on.
- if (bc->typ2 != BtnTypeNone)
- {
- // there's a shifted key assignment - use it
- typ = bc->typ2;
- val = bc->val2;
- useShift = true;
- }
- else if (cfg.nightMode.btn == i+1
- && (cfg.nightMode.flags & 0x03) == 0x02)
- {
- // shift+button = night mode toggle
- typ = BtnTypeNone;
- val = 0;
- useShift = true;
- }
-
- // If there's a shifted meaning, advance the shift
- // button state from 1 to 2 if applicable. This signals
- // that we've "consumed" the shift button press as the
- // shift button, so it shouldn't generate its own key
- // code event when released.
- if (useShift && shiftButton.state == 1)
- shiftButton.state = 2;
+ typ = bc->typ2;
+ val = bc->val2;
}
-
+ else
+ {
+ typ = bc->typ;
+ val = bc->val;
+ }
+
// We've decided on the meaning of the button, so process
// the keyboard or joystick event.
- switch (typ)
- {
- case BtnTypeJoystick:
- // joystick button
- newjs |= (1 << (val - 1));
- break;
-
- case BtnTypeKey:
- // Keyboard key. The USB keyboard report encodes regular
- // keys and modifier keys separately, so we need to check
- // which type we have. Note that past versions mapped the
- // Keyboard Volume Up, Keyboard Volume Down, and Keyboard
- // Mute keys to the corresponding Media keys. We no longer
- // do this; instead, we have the separate BtnTypeMedia for
- // explicitly using media keys if desired.
- if (val >= 0xE0 && val <= 0xE7)
- {
- // It's a modifier key. These are represented in the USB
- // reports with a bit mask. We arrange the mask bits in
- // the same order as the scan codes, so we can figure the
- // appropriate bit with a simple shift.
- modkeys |= (1 << (val - 0xE0));
- }
- else
- {
- // It's a regular key. Make sure it's not already in the
- // list, and that the list isn't full. If neither of these
- // apply, add the key to the key array.
- if (nkeys < 7)
- {
- bool found = false;
- for (int j = 0 ; j < nkeys ; ++j)
- {
- if (keys[j] == val)
- {
- found = true;
- break;
- }
- }
- if (!found)
- keys[nkeys++] = val;
- }
- }
- break;
-
- case BtnTypeMedia:
- // Media control key. The media keys are mapped in the USB
- // report to bits, whereas the key codes are specified in the
- // config with their USB usage numbers. E.g., the config val
- // for Media Next Track is 0xB5, but we encode this in the USB
- // report as bit 0x08. The mediaKeyMap[] table translates
- // from the USB usage number to the mask bit. If the key isn't
- // among the subset we support, the mapped bit will be zero, so
- // the "|=" will have no effect and the key will be ignored.
- mediakeys |= mediaKeyMap[val];
- break;
- }
+ ks.addKey(typ, val);
}
}
-
- // check for joystick button changes
- if (jsButtons != newjs)
- jsButtons = newjs;
-
- // Check for changes to the keyboard keys
- if (kbState.data[0] != modkeys
- || kbState.nkeys != nkeys
- || memcmp(keys, &kbState.data[2], 6) != 0)
+
+ // If an IR input command is in effect, add the IR command's
+ // assigned key, if any. If we're in an IR key gap, don't include
+ // the IR key.
+ if (IRCommandIn != 0 && !IRKeyGap)
+ {
+ IRCommandCfg &irc = cfg.IRCommand[IRCommandIn - 1];
+ ks.addKey(irc.keytype, irc.keycode);
+ }
+
+ // We're finished building the new key state. Update the global
+ // key state variables to reflect the new state.
+
+ // set the new joystick buttons (no need to check for changes, as we
+ // report these on every joystick report whether they changed or not)
+ jsButtons = ks.js;
+
+ // check for keyboard key changes (we only send keyboard reports when
+ // something changes)
+ if (kbState.data[0] != ks.modkeys
+ || kbState.nkeys != ks.nkeys
+ || memcmp(ks.keys, &kbState.data[2], 6) != 0)
{
// we have changes - set the change flag and store the new key data
kbState.changed = true;
- kbState.data[0] = modkeys;
- if (nkeys <= 6) {
+ kbState.data[0] = ks.modkeys;
+ if (ks.nkeys <= 6) {
// 6 or fewer simultaneous keys - report the key codes
- kbState.nkeys = nkeys;
- memcpy(&kbState.data[2], keys, 6);
+ kbState.nkeys = ks.nkeys;
+ memcpy(&kbState.data[2], ks.keys, 6);
}
else {
// more than 6 simultaneous keys - report rollover (all '1' key codes)
@@ -2546,11 +3078,13 @@
}
}
- // Check for changes to media keys
- if (mediaState.data != mediakeys)
+ // check for media key changes (we only send media key reports when
+ // something changes)
+ if (mediaState.data != ks.mediakeys)
{
+ // we have changes - set the change flag and store the new key data
mediaState.changed = true;
- mediaState.data = mediakeys;
+ mediaState.data = ks.mediakeys;
}
}
@@ -2811,12 +3345,34 @@
// MMA8451Q. This class encapsulates an interrupt handler and
// automatic calibration.
//
-// We install an interrupt handler on the accelerometer "data ready"
-// interrupt to ensure that we fetch each sample immediately when it
-// becomes available. The accelerometer data rate is fairly high
-// (800 Hz), so it's not practical to keep up with it by polling.
-// Using an interrupt handler lets us respond quickly and read
-// every sample.
+// We collect data at the device's maximum rate of 800kHz (one sample
+// every 1.25ms). To keep up with the high data rate, we use the
+// device's internal FIFO, and drain the FIFO by polling on each
+// iteration of our main application loop. In the past, we used an
+// interrupt handler to read the device immediately on the arrival of
+// each sample, but this created too much latency for the IR remote
+// receiver, due to the relatively long time it takes to transfer the
+// accelerometer readings via I2C. The device's on-board FIFO can
+// store up to 32 samples, which gives us up to about 40ms between
+// polling iterations before the buffer overflows. Our main loop runs
+// in under 2ms, so we can easily keep the FIFO far from overflowing.
+//
+// The MMA8451Q has three range modes, +/- 2G, 4G, and 8G. The ADC
+// sample is the same bit width (14 bits) in all modes, so the higher
+// dynamic range modes trade physical precision for range. For our
+// purposes, precision is more important than range, so we use the
+// +/-2G mode. Further, our joystick range is calibrated for only
+// +/-1G. This was unintentional on my part; I didn't look at the
+// MMA8451Q library closely enough to realize it was normalizing to
+// actual "G" units, and assumed that it was normalizing to a -1..+1
+// scale. In practice, a +/-1G scale seems perfectly adequate for
+// virtual pinball use, so I'm sticking with that range for now. But
+// there might be some benefit in renormalizing to a +/-2G range, in
+// that it would allow for higher dynamic range for very hard nudges.
+// Everyone would have to tweak their nudge sensitivity in VP if I
+// made that change, though, so I'm keeping it as is for now; it would
+// be best to make it a config option ("accelerometer high dynamic range")
+// rather than change it across the board.
//
// We automatically calibrate the accelerometer so that it's not
// necessary to get it exactly level when installing it, and so
@@ -2850,43 +3406,46 @@
// accelerometer input history item, for gathering calibration data
struct AccHist
{
- AccHist() { x = y = d = 0.0; xtot = ytot = 0.0; cnt = 0; }
- void set(float x, float y, AccHist *prv)
+ AccHist() { x = y = dsq = 0; xtot = ytot = 0; cnt = 0; }
+ void set(int x, int y, AccHist *prv)
{
// save the raw position
this->x = x;
this->y = y;
- this->d = distance(prv);
+ this->dsq = distanceSquared(prv);
}
// reading for this entry
- float x, y;
-
- // distance from previous entry
- float d;
+ int x, y;
+
+ // (distance from previous entry) squared
+ int dsq;
// total and count of samples averaged over this period
- float xtot, ytot;
+ int xtot, ytot;
int cnt;
- void clearAvg() { xtot = ytot = 0.0; cnt = 0; }
- void addAvg(float x, float y) { xtot += x; ytot += y; ++cnt; }
- float xAvg() const { return xtot/cnt; }
- float yAvg() const { return ytot/cnt; }
-
- float distance(AccHist *p)
- { return sqrt(square(p->x - x) + square(p->y - y)); }
+ void clearAvg() { xtot = ytot = 0; cnt = 0; }
+ void addAvg(int x, int y) { xtot += x; ytot += y; ++cnt; }
+ int xAvg() const { return xtot/cnt; }
+ int yAvg() const { return ytot/cnt; }
+
+ int distanceSquared(AccHist *p)
+ { return square(p->x - x) + square(p->y - y); }
};
// accelerometer wrapper class
class Accel
{
public:
- Accel(PinName sda, PinName scl, int i2cAddr, PinName irqPin)
- : mma_(sda, scl, i2cAddr), intIn_(irqPin)
+ Accel(PinName sda, PinName scl, int i2cAddr, PinName irqPin, int range)
+ : mma_(sda, scl, i2cAddr)
{
// remember the interrupt pin assignment
irqPin_ = irqPin;
+
+ // remember the range
+ range_ = range;
// reset and initialize
reset();
@@ -2895,138 +3454,130 @@
void reset()
{
// clear the center point
- cx_ = cy_ = 0.0;
+ cx_ = cy_ = 0;
- // start the calibration timer
+ // start the auto-centering timer
tCenter_.start();
iAccPrv_ = nAccPrv_ = 0;
// reset and initialize the MMA8451Q
mma_.init();
+
+ // set the range
+ mma_.setRange(
+ range_ == AccelRange4G ? 4 :
+ range_ == AccelRange8G ? 8 :
+ 2);
- // set the initial integrated velocity reading to zero
- vx_ = vy_ = 0;
-
- // set up our accelerometer interrupt handling
- intIn_.rise(this, &Accel::isr);
- mma_.setInterruptMode(irqPin_ == PTA14 ? 1 : 2);
+ // set the average accumulators to zero
+ xSum_ = ySum_ = 0;
+ nSum_ = 0;
// read the current registers to clear the data ready flag
mma_.getAccXYZ(ax_, ay_, az_);
-
- // start our timers
- tGet_.start();
- tInt_.start();
}
- void disableInterrupts()
+ void poll()
{
- mma_.clearInterruptMode();
+ // read samples until we clear the FIFO
+ while (mma_.getFIFOCount() != 0)
+ {
+ int x, y, z;
+ mma_.getAccXYZ(x, y, z);
+
+ // add the new reading to the running total for averaging
+ xSum_ += (x - cx_);
+ ySum_ += (y - cy_);
+ ++nSum_;
+
+ // store the updates
+ ax_ = x;
+ ay_ = y;
+ az_ = z;
+ }
}
-
+
void get(int &x, int &y)
{
- // disable interrupts while manipulating the shared data
- __disable_irq();
-
- // read the shared data and store locally for calculations
- float ax = ax_, ay = ay_;
- float vx = vx_, vy = vy_;
-
- // reset the velocity sum for the next run
- vx_ = vy_ = 0;
-
- // get the time since the last get() sample
- int dtus = tGet_.read_us();
- tGet_.reset();
-
- // done manipulating the shared data
- __enable_irq();
-
- // adjust the readings for the integration time
- float dt = dtus/1000000.0f;
- vx /= dt;
- vy /= dt;
+ // read the shared data and store locally for calculations
+ int ax = ax_, ay = ay_;
+ int xSum = xSum_, ySum = ySum_;
+ int nSum = nSum_;
- // add this sample to the current calibration interval's running total
- AccHist *p = accPrv_ + iAccPrv_;
- p->addAvg(ax, ay);
-
- // check for auto-centering every so often
- if (tCenter_.read_us() > 1000000)
- {
- // add the latest raw sample to the history list
- AccHist *prv = p;
- iAccPrv_ = (iAccPrv_ + 1) % maxAccPrv;
- p = accPrv_ + iAccPrv_;
- p->set(ax, ay, prv);
-
- // if we have a full complement, check for stability
- if (nAccPrv_ >= maxAccPrv)
- {
- // check if we've been stable for all recent samples
- static const float accTol = .01f;
- AccHist *p0 = accPrv_;
- if (p0[0].d < accTol
- && p0[1].d < accTol
- && p0[2].d < accTol
- && p0[3].d < accTol
- && p0[4].d < accTol)
- {
- // Figure the new calibration point as the average of
- // the samples over the rest period
- cx_ = (p0[0].xAvg() + p0[1].xAvg() + p0[2].xAvg() + p0[3].xAvg() + p0[4].xAvg())/5.0f;
- cy_ = (p0[0].yAvg() + p0[1].yAvg() + p0[2].yAvg() + p0[3].yAvg() + p0[4].yAvg())/5.0f;
- }
- }
- else
- {
- // not enough samples yet; just up the count
- ++nAccPrv_;
- }
+ // reset the average accumulators for the next run
+ xSum_ = ySum_ = 0;
+ nSum_ = 0;
+
+ // add this sample to the current calibration interval's running total
+ AccHist *p = accPrv_ + iAccPrv_;
+ p->addAvg(ax, ay);
+
+ // check for auto-centering every so often
+ if (tCenter_.read_us() > 1000000)
+ {
+ // add the latest raw sample to the history list
+ AccHist *prv = p;
+ iAccPrv_ = (iAccPrv_ + 1);
+ if (iAccPrv_ >= maxAccPrv)
+ iAccPrv_ = 0;
+ p = accPrv_ + iAccPrv_;
+ p->set(ax, ay, prv);
+
+ // if we have a full complement, check for stability
+ if (nAccPrv_ >= maxAccPrv)
+ {
+ // check if we've been stable for all recent samples
+ static const int accTol = 164*164; // 1% of range, squared
+ AccHist *p0 = accPrv_;
+ if (p0[0].dsq < accTol
+ && p0[1].dsq < accTol
+ && p0[2].dsq < accTol
+ && p0[3].dsq < accTol
+ && p0[4].dsq < accTol)
+ {
+ // Figure the new calibration point as the average of
+ // the samples over the rest period
+ cx_ = (p0[0].xAvg() + p0[1].xAvg() + p0[2].xAvg() + p0[3].xAvg() + p0[4].xAvg())/5;
+ cy_ = (p0[0].yAvg() + p0[1].yAvg() + p0[2].yAvg() + p0[3].yAvg() + p0[4].yAvg())/5;
+ }
+ }
+ else
+ {
+ // not enough samples yet; just up the count
+ ++nAccPrv_;
+ }
- // clear the new item's running totals
- p->clearAvg();
+ // clear the new item's running totals
+ p->clearAvg();
- // reset the timer
- tCenter_.reset();
-
- // If we haven't seen an interrupt in a while, do an explicit read to
- // "unstick" the device. The device can become stuck - which is to say,
- // it will stop delivering data-ready interrupts - if we fail to service
- // one data-ready interrupt before the next one occurs. Reading a sample
- // will clear up this overrun condition and allow normal interrupt
- // generation to continue.
- //
- // 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);
- }
- }
+ // reset the timer
+ tCenter_.reset();
+ }
- // report our integrated velocity reading in x,y
- x = rawToReport(vx);
- y = rawToReport(vy);
+ // report our integrated velocity reading in x,y
+ x = rawToReport(xSum/nSum);
+ y = rawToReport(ySum/nSum);
#ifdef DEBUG_PRINTF
- if (x != 0 || y != 0)
- printf("%f %f %d %d %f\r\n", vx, vy, x, y, dt);
+ if (x != 0 || y != 0)
+ printf("%f %f %d %d %f\r\n", vx, vy, x, y, dt);
#endif
- }
+ }
private:
// adjust a raw acceleration figure to a usb report value
- int rawToReport(float v)
+ int rawToReport(int v)
{
- // scale to the joystick report range and round to integer
- int i = int(round(v*JOYMAX));
+ // Scale to the joystick report range. The accelerometer
+ // readings use the native 14-bit signed integer representation,
+ // so their scale is 2^13.
+ //
+ // The 1G range is special: it uses the 2G native hardware range,
+ // but rescales the result to a 1G range for the joystick reports.
+ // So for that mode, we divide by 4096 rather than 8192. All of
+ // the other modes map use the hardware scaling directly.
+ int i = v*JOYMAX;
+ i = (range_ == AccelRange1G ? i/4096 : i/8192);
// if it's near the center, scale it roughly as 20*(i/20)^2,
// to suppress noise near the rest position
@@ -3038,56 +3589,32 @@
return (i > 20 || i < -20 ? i : filter[i+20]);
}
- // interrupt handler
- void isr()
- {
- // Read the axes. Note that we have to read all three axes
- // (even though we only really use x and y) in order to clear
- // the "data ready" status bit in the accelerometer. The
- // interrupt only occurs when the "ready" bit transitions from
- // off to on, so we have to make sure it's off.
- float x, y, z;
- mma_.getAccXYZ(x, y, z);
-
- // calculate the time since the last interrupt
- float dt = tInt_.read();
- tInt_.reset();
-
- // integrate the time slice from the previous reading to this reading
- vx_ += (x + ax_ - 2*cx_)*dt/2;
- vy_ += (y + ay_ - 2*cy_)*dt/2;
-
- // store the updates
- ax_ = x;
- ay_ = y;
- az_ = z;
- }
-
// underlying accelerometer object
MMA8451Q mma_;
- // last raw acceleration readings
- float ax_, ay_, az_;
-
- // integrated velocity reading since last get()
- float vx_, vy_;
+ // last raw acceleration readings, on the device's signed 14-bit
+ // scale -8192..+8191
+ int ax_, ay_, az_;
+
+ // running sum of readings since last get()
+ int xSum_, ySum_;
+
+ // number of readings since last get()
+ int nSum_;
- // timer for measuring time between get() samples
- Timer tGet_;
-
- // timer for measuring time between interrupts
- Timer tInt_;
-
// Calibration reference point for accelerometer. This is the
// average reading on the accelerometer when in the neutral position
// at rest.
- float cx_, cy_;
-
- // timer for atuo-centering
+ int cx_, cy_;
+
+ // range (AccelRangeXxx value, from config.h)
+ uint8_t range_;
+
+ // atuo-centering timer
Timer tCenter_;
// Auto-centering history. This is a separate history list that
- // records results spaced out sparesely over time, so that we can
+ // records results spaced out sparsely over time, so that we can
// watch for long-lasting periods of rest. When we observe nearly
// no motion for an extended period (on the order of 5 seconds), we
// take this to mean that the cabinet is at rest in its neutral
@@ -3104,9 +3631,6 @@
// interurupt pin name
PinName irqPin_;
-
- // interrupt router
- InterruptIn intIn_;
};
// ---------------------------------------------------------------------------
@@ -3274,25 +3798,37 @@
// so we don't want to push the button on a TV that's already on.
//
-// Current PSU2 state:
+// Current PSU2 power state:
// 1 -> default: latch was on at last check, or we haven't checked yet
// 2 -> latch was off at last check, SET pulsed high
// 3 -> SET pulsed low, ready to check status
// 4 -> TV timer countdown in progress
// 5 -> TV relay on
+// 6 -> sending IR signals designed as TV ON signals
uint8_t psu2_state = 1;
// TV relay state. The TV relay can be controlled by the power-on
// timer and directly from the PC (via USB commands), so keep a
// separate state for each:
-//
// 0x01 -> turned on by power-on timer
// 0x02 -> turned on by USB command
uint8_t tv_relay_state = 0x00;
const uint8_t TV_RELAY_POWERON = 0x01;
const uint8_t TV_RELAY_USB = 0x02;
-// TV ON switch relay control
+// TV ON IR command state. When the main PSU2 power state reaches
+// the IR phase, we use this sub-state counter to send the TV ON
+// IR signals. We initialize to state 0 when the main state counter
+// reaches the IR step. In state 0, we start transmitting the first
+// (lowest numbered) IR command slot marked as containing a TV ON
+// code, and advance to state 1. In state 1, we check to see if
+// the transmitter is still sending; if so, we do nothing, if so
+// we start transmitting the second TV ON code and advance to state
+// 2. Continue until we run out of TV ON IR codes, at which point
+// we advance to the next main psu2_state step.
+uint8_t tvon_ir_state = 0;
+
+// TV ON switch relay control output pin
DigitalOut *tv_relay;
// PSU2 power sensing circuit connections
@@ -3313,12 +3849,27 @@
tv_relay->write(tv_relay_state != 0);
}
-// Timer interrupt
-Ticker tv_ticker;
-float tv_delay_time;
-void TVTimerInt()
+// PSU2 Status update routine. The main loop calls this from time
+// to time to update the power sensing state and carry out TV ON
+// functions.
+Timer powerStatusTimer;
+uint32_t tv_delay_time_us;
+void powerStatusUpdate(Config &cfg)
{
- // time since last state change
+ // Only update every 1/4 second or so. Note that if the PSU2
+ // circuit isn't configured, the initialization routine won't
+ // start the timer, so it'll always read zero and we'll always
+ // skip this whole routine.
+ if (powerStatusTimer.read_us() < 250000)
+ return;
+
+ // reset the update timer for next time
+ powerStatusTimer.reset();
+
+ // TV ON timer. We start this timer when we detect a change
+ // in the PSU2 status from OFF to ON. When the timer reaches
+ // the configured TV ON delay time, and the PSU2 power is still
+ // on, we'll trigger the TV ON relay and send the TV ON IR codes.
static Timer tv_timer;
// Check our internal state
@@ -3338,6 +3889,7 @@
// try setting the latch
psu2_status_set->write(1);
}
+ powerTimerDiagState = 0;
break;
case 2:
@@ -3345,6 +3897,7 @@
// the latch. Drop the SET signal and go to CHECK state.
psu2_status_set->write(0);
psu2_state = 3;
+ powerTimerDiagState = 0;
break;
case 3:
@@ -3362,7 +3915,6 @@
// start the power timer diagnostic flashes
powerTimerDiagState = 2;
- diagLED();
}
else
{
@@ -3375,53 +3927,136 @@
break;
case 4:
- // TV timer countdown in progress. If we've reached the
- // delay time, pulse the relay.
- if (tv_timer.read() >= tv_delay_time)
+ // TV timer countdown in progress. The latch has to stay on during
+ // the countdown; if the latch turns off, PSU2 power must have gone
+ // off again before the countdown finished.
+ if (!psu2_status_sense->read())
+ {
+ // power is off - start a new check cycle
+ psu2_status_set->write(1);
+ psu2_state = 2;
+ break;
+ }
+
+ // Flash the power time diagnostic every two cycles
+ powerTimerDiagState = (powerTimerDiagState + 1) & 0x03;
+
+ // if we've reached the delay time, pulse the relay
+ if (tv_timer.read_us() >= tv_delay_time_us)
{
// turn on the relay for one timer interval
tvRelayUpdate(TV_RELAY_POWERON, true);
psu2_state = 5;
+
+ // show solid blue on the diagnostic LED while the relay is on
+ powerTimerDiagState = 2;
}
-
- // flash the power time diagnostic every two interrupts
- powerTimerDiagState = (powerTimerDiagState + 1) & 0x03;
- diagLED();
break;
case 5:
// TV timer relay on. We pulse this for one interval, so
- // it's now time to turn it off and return to the default state.
+ // it's now time to turn it off.
tvRelayUpdate(TV_RELAY_POWERON, false);
+
+ // Proceed to sending any TV ON IR commands
+ psu2_state = 6;
+ tvon_ir_state = 0;
+
+ // diagnostic LEDs off for now
+ powerTimerDiagState = 0;
+ break;
+
+ case 6:
+ // Sending TV ON IR signals. Start with the assumption that
+ // we have no IR work to do, in which case we're done with the
+ // whole TV ON sequence. So by default return to state 1.
psu2_state = 1;
+ powerTimerDiagState = 0;
- // done with the diagnostic flashes
- powerTimerDiagState = 0;
- diagLED();
+ // If we have an IR emitter, check for TV ON IR commands
+ if (ir_tx != 0)
+ {
+ // check to see if the last transmission is still in progress
+ if (ir_tx->isSending())
+ {
+ // We're still sending the last transmission. Stay in
+ // state 6.
+ psu2_state = 6;
+ powerTimerDiagState = 4;
+ break;
+ }
+
+ // The last transmission is done, so check for a new one.
+ // Look for the Nth TV ON IR slot, where N is our state
+ // number.
+ for (int i = 0, n = 0 ; i < MAX_IR_CODES ; ++i)
+ {
+ // is this a TV ON command?
+ if ((cfg.IRCommand[i].flags & IRFlagTVON) != 0)
+ {
+ // It's a TV ON command - check if it's the one we're
+ // looking for.
+ if (n == tvon_ir_state)
+ {
+ // It's the one. Start transmitting it by
+ // pushing its virtual button.
+ int vb = IRConfigSlotToVirtualButton[i];
+ ir_tx->pushButton(vb, true);
+
+ // Pushing the button starts transmission, and once
+ // started, the transmission will run to completion
+ // even if the button is no longer pushed. So we
+ // can immediately un-push the button, since we only
+ // need to send the code once.
+ ir_tx->pushButton(vb, false);
+
+ // Advance to the next TV ON IR state, where we'll
+ // await the end of this transmission and move on to
+ // the next one.
+ psu2_state = 6;
+ tvon_ir_state++;
+ break;
+ }
+
+ // it's not ours - count it and keep looking
+ ++n;
+ }
+ }
+ }
break;
}
+
+ // update the diagnostic LEDs
+ diagLED();
}
-// Start the TV ON checker. If the status sense circuit is enabled in
-// the configuration, we'll set up the pin connections and start the
-// interrupt handler that periodically checks the status. Does nothing
-// if any of the pins are configured as NC.
-void startTVTimer(Config &cfg)
+// Start the power status timer. If the status sense circuit is enabled
+// in the configuration, we'll set up the pin connections and start the
+// timer for our periodic status checks. Does nothing if any of the pins
+// are configured as NC.
+void startPowerStatusTimer(Config &cfg)
{
// only start the timer if the pins are configured and the delay
// time is nonzero
- if (cfg.TVON.delayTime != 0
- && cfg.TVON.statusPin != 0xFF
- && cfg.TVON.latchPin != 0xFF
- && cfg.TVON.relayPin != 0xFF)
+ powerStatusTimer.reset();
+ if (cfg.TVON.statusPin != 0xFF
+ && cfg.TVON.latchPin != 0xFF)
{
+ // set up the power sensing circuit connections
psu2_status_sense = new DigitalIn(wirePinName(cfg.TVON.statusPin));
psu2_status_set = new DigitalOut(wirePinName(cfg.TVON.latchPin));
- tv_relay = new DigitalOut(wirePinName(cfg.TVON.relayPin));
- tv_delay_time = cfg.TVON.delayTime/100.0f;
-
- // Set up our time routine to run every 1/4 second.
- tv_ticker.attach(&TVTimerInt, 0.25);
+
+ // if there's a TV ON relay, set up its control pin
+ if (cfg.TVON.relayPin != 0xFF)
+ tv_relay = new DigitalOut(wirePinName(cfg.TVON.relayPin));
+
+ // Set the TV ON delay time. We store the time internally in
+ // microseconds, but the configuration stores it in units of
+ // 1/100 second = 10ms = 10000us.
+ tv_delay_time_us = cfg.TVON.delayTime * 10000;;
+
+ // Start the TV timer
+ powerStatusTimer.start();
}
}
@@ -3482,6 +4117,18 @@
//
NVM nvm;
+// Flag: configuration save requested. The USB command message handler
+// sets this flag when a command is sent requesting the save. We don't
+// do the save inline in the command handler, but handle it on the next
+// main loop iteration.
+const uint8_t SAVE_CONFIG_ONLY = 1;
+const uint8_t SAVE_CONFIG_AND_REBOOT = 2;
+uint8_t saveConfigPending = 0;
+
+// If saveConfigPending == SAVE_CONFIG_AND_REBOOT, this specifies the
+// delay time in seconds before rebooting.
+uint8_t saveConfigRebootTime;
+
// For convenience, a macro for the Config part of the NVM structure
#define cfg (nvm.d.c)
@@ -3499,26 +4146,10 @@
}
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)
-{
- // figure how many flash sectors we span, rounding up to whole sectors
- numSectors = (sizeof(NVM) + SECTOR_SIZE - 1)/SECTOR_SIZE;
-
- // figure the address - this is the highest flash address where the
- // structure will fit with the start aligned on a sector boundary
- addr = (int)&flash_nvm_memory;
-
- // return the address as a pointer
- return (NVM *)addr;
-}
-
// figure the flash address as a pointer
NVM *configFlashAddr()
{
- int addr, numSectors;
- return configFlashAddr(addr, numSectors);
+ return (NVM *)&flash_nvm_memory;
}
// Load the config from flash. Returns true if a valid non-default
@@ -3570,8 +4201,7 @@
waitPlungerIdle();
// get the config block location in the flash memory
- int addr, sectors;
- configFlashAddr(addr, sectors);
+ uint32_t addr = uint32_t(configFlashAddr());
// loop until we save it successfully
for (int i = 0 ; i < 5 ; ++i)
@@ -3588,10 +4218,10 @@
// verify the data
if (nvm.verify(addr))
{
- // show a diagnostic success flash
- for (int j = 0 ; j < 3 ; ++j)
+ // show a diagnostic success flash (rapid green)
+ for (int j = 0 ; j < 4 ; ++j)
{
- diagLED(0, 1, 1);
+ diagLED(0, 1, 0);
wait_us(50000);
diagLED(0, 0, 0);
wait_us(50000);
@@ -3704,8 +4334,10 @@
// Turn night mode on or off
static void setNightMode(bool on)
{
- // set the new night mode flag in the noisy output class
- nightMode = on;
+ // Set the new night mode flag in the noisy output class. Note
+ // that we use the status report bit flag value 0x02 when on, so
+ // that we can just '|' this into the overall status bits.
+ nightMode = on ? 0x02 : 0x00;
// update the special output pin that shows the night mode state
int port = int(cfg.nightMode.port) - 1;
@@ -4890,6 +5522,7 @@
#define if_msg_valid(test) if (test)
#define v_byte(var, ofs) cfg.var = data[ofs]
#define v_ui16(var, ofs) cfg.var = wireUI16(data+(ofs))
+#define v_ui32(var, ofs) cfg.var = wireUI32(data+(ofs))
#define v_pin(var, ofs) cfg.var = wirePinName(data[ofs])
#define v_byte_ro(val, ofs) // ignore read-only variables on SET
#define v_ui32_ro(val, ofs) // ignore read-only variables on SET
@@ -4901,6 +5534,7 @@
#undef if_msg_valid
#undef v_byte
#undef v_ui16
+#undef v_ui32
#undef v_pin
#undef v_byte_ro
#undef v_ui32_ro
@@ -4911,6 +5545,7 @@
#define if_msg_valid(test)
#define v_byte(var, ofs) data[ofs] = cfg.var
#define v_ui16(var, ofs) ui16Wire(data+(ofs), cfg.var)
+#define v_ui32(var, ofs) ui32Wire(data+(ofs), cfg.var)
#define v_pin(var, ofs) pinNameWire(data+(ofs), cfg.var)
#define v_byte_ro(val, ofs) data[ofs] = (val)
#define v_ui32_ro(val, ofs) ui32Wire(data+(ofs), val);
@@ -4986,12 +5621,9 @@
cfg.psUnitNo = newUnitNo;
cfg.plunger.enabled = data[3] & 0x01;
- // save the configuration
- saveConfigToFlash();
-
- // reboot if necessary
- if (needReset)
- reboot(js);
+ // set the flag to do the save
+ saveConfigPending = needReset ? SAVE_CONFIG_AND_REBOOT : SAVE_CONFIG_ONLY;
+ saveConfigRebootTime = 0;
}
break;
@@ -5035,13 +5667,10 @@
break;
case 6:
- // 6 = Save configuration to flash.
- saveConfigToFlash();
-
- // before disconnecting, pause for the delay time specified in
- // the parameter byte (in seconds)
- rebootTime_us = data[2] * 1000000L;
- rebootTimer.start();
+ // 6 = Save configuration to flash. Reboot after the delay
+ // time in seconds given in data[2].
+ saveConfigPending = SAVE_CONFIG_AND_REBOOT;
+ saveConfigRebootTime = data[2];
break;
case 7:
@@ -5091,7 +5720,20 @@
break;
case 12:
- // Unused
+ // 12 = Learn IR code. This enters IR learning mode. While
+ // in learning mode, we report raw IR signals and the first IR
+ // command decoded through the special IR report format. IR
+ // learning mode automatically ends after a timeout expires if
+ // no command can be decoded within the time limit.
+
+ // enter IR learning mode
+ IRLearningMode = 1;
+
+ // cancel any regular IR input in progress
+ IRCommandIn = 0;
+
+ // reset and start the learning mode timeout timer
+ IRTimer.reset();
break;
case 13:
@@ -5245,7 +5887,8 @@
{
// say hello to the debug console, in case it's connected
printf("\r\nPinscape Controller starting\r\n");
-
+
+
// debugging: print memory config info
// -> 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);}
@@ -5313,12 +5956,20 @@
// start the TLC5940 refresh cycle clock
if (tlc5940 != 0)
tlc5940->start();
-
- // start the TV timer, if applicable
- startTVTimer(cfg);
+
+ // 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
+ // USB keyboard interface.
+ bool kbKeys = false;
+
+ // set up the IR remote control emitter & receiver, if present
+ init_IR(cfg, kbKeys);
+
+ // start the power status time, if applicable
+ startPowerStatusTimer(cfg);
// initialize the button input ports
- bool kbKeys = false;
initButtons(cfg, kbKeys);
// Create the joystick USB client. Note that the USB vendor/product ID
@@ -5349,9 +6000,16 @@
connFlashTimer.reset();
}
+ // If we've been disconnected for more than the reboot timeout,
+ // reboot. Some PCs won't reconnect if we were left plugged in
+ // during a power cycle on the PC, but fortunately a reboot on
+ // the KL25Z will make the host notice us and trigger a reconnect.
if (cfg.disconnectRebootTimeout != 0
&& connTimeoutTimer.read() > cfg.disconnectRebootTimeout)
reboot(js, false, 0);
+
+ // update the PSU2 power sensing status
+ powerStatusUpdate(cfg);
}
// we're now connected to the host
@@ -5418,7 +6076,8 @@
acTimer.start();
// create the accelerometer object
- Accel accel(MMA8451_SCL_PIN, MMA8451_SDA_PIN, MMA8451_I2C_ADDRESS, MMA8451_INT_PIN);
+ Accel accel(MMA8451_SCL_PIN, MMA8451_SDA_PIN, MMA8451_I2C_ADDRESS,
+ MMA8451_INT_PIN, cfg.accelRange);
// last accelerometer report, in joystick units (we report the nudge
// acceleration via the joystick x & y axes, per the VP convention)
@@ -5442,6 +6101,9 @@
// start the PWM update polling timer
polledPwmTimer.start();
+ // Timer for configuration change reboots
+ ExtTimer saveConfigRebootTimer;
+
// we're all set up - now just loop, processing sensor reports and
// host requests
for (;;)
@@ -5456,7 +6118,7 @@
LedWizMsg lwm;
Timer lwt;
lwt.start();
- IF_DIAG(int msgCount = 0;)
+ IF_DIAG(int msgCount = 0;)
while (js.readLedWizMsg(lwm) && lwt.read_us() < 5000)
{
handleInputMsg(lwm, js);
@@ -5472,11 +6134,20 @@
}
)
+ // process IR input
+ process_IR(cfg, js);
+
+ // update the PSU2 power sensing status
+ powerStatusUpdate(cfg);
+
// update flashing LedWiz outputs periodically
wizPulse();
// update PWM outputs
pollPwmUpdates();
+
+ // poll the accelerometer
+ accel.poll();
// collect diagnostic statistics, checkpoint 0
IF_DIAG(mainLoopIterCheckpt[0] += mainLoopTimer.read_us();)
@@ -5487,7 +6158,7 @@
// collect diagnostic statistics, checkpoint 1
IF_DIAG(mainLoopIterCheckpt[1] += mainLoopTimer.read_us();)
-
+
// check for plunger calibration
if (calBtn != 0 && !calBtn->read())
{
@@ -5537,8 +6208,10 @@
// Otherwise, return to the base state without saving anything.
// If the button is released before we make it to calibration
// mode, it simply cancels the attempt.
+ diagLED(1,1,1);
if (calBtnState == 3 && calBtnTimer.read_us() > 15000000)
{
+ diagLED(0,0,0);
// exit calibration mode
calBtnState = 0;
plungerReader.setCalMode(false);
@@ -5549,6 +6222,7 @@
}
else if (calBtnState != 3)
{
+ diagLED(0,1,1);
// didn't make it to calibration mode - cancel the operation
calBtnState = 0;
}
@@ -5635,10 +6309,12 @@
bool jsOK = false;
// figure the current status flags for joystick reports
- uint16_t statusFlags =
- (cfg.plunger.enabled ? 0x01 : 0x00)
- | (nightMode ? 0x02 : 0x00)
- | ((psu2_state & 0x07) << 2);
+ uint16_t statusFlags =
+ cfg.plunger.enabled // 0x01
+ | nightMode // 0x02
+ | ((psu2_state & 0x07) << 2); // 0x04 0x08 0x10
+ if (IRLearningMode != 0)
+ statusFlags |= 0x20;
// If it's been long enough since our last USB status report, send
// the new report. VP only polls for input in 10ms intervals, so
@@ -5692,7 +6368,7 @@
// If joystick reports are turned off, send a generic status report
// periodically for the sake of the Windows config tool.
- if (!cfg.joystickEnabled && jsReportTimer.read_us() > 5000)
+ if (!cfg.joystickEnabled && jsReportTimer.read_us() > 10000UL)
{
jsOK = js.updateStatus(statusFlags);
jsReportTimer.reset();
@@ -5758,8 +6434,23 @@
}
// if we have a reboot timer pending, check for completion
- if (rebootTimer.isRunning() && rebootTimer.read_us() > rebootTime_us)
+ if (saveConfigRebootTimer.isRunning()
+ && saveConfigRebootTimer.read() > saveConfigRebootTime)
reboot(js);
+
+ // if a config save is pending, do it now
+ if (saveConfigPending != 0)
+ {
+ // save the configuration
+ saveConfigToFlash();
+
+ // if desired, reboot after the specified delay
+ if (saveConfigPending == SAVE_CONFIG_AND_REBOOT)
+ saveConfigRebootTimer.start();
+
+ // the save is no longer pending
+ saveConfigPending = 0;
+ }
// if we're disconnected, initiate a new connection
if (!connected)
@@ -5809,10 +6500,19 @@
diagTimer.reset();
}
- // if the disconnect reboot timeout has expired, reboot
+ // If the disconnect reboot timeout has expired, reboot.
+ // Some PC hosts won't reconnect to a device that's left
+ // plugged in through various events on the PC side, such as
+ // rebooting Windows, cycling power on the PC, or just a lost
+ // USB connection. Rebooting the KL25Z seems to be the most
+ // reliable way to get Windows to notice us again after one
+ // of these events and make it reconnect.
if (cfg.disconnectRebootTimeout != 0
&& reconnTimeoutTimer.read() > cfg.disconnectRebootTimeout)
reboot(js, false, 0);
+
+ // update the PSU2 power sensing status
+ powerStatusUpdate(cfg);
}
// resume the main loop timer