An I/O controller for virtual pinball machines: accelerometer nudge sensing, analog plunger input, button input encoding, LedWiz compatible output controls, and more.

Dependencies:   mbed FastIO FastPWM USBDevice

Fork of Pinscape_Controller by Mike R

/media/uploads/mjr/pinscape_no_background_small_L7Miwr6.jpg

This is Version 2 of the Pinscape Controller, an I/O controller for virtual pinball machines. (You can find the old version 1 software here.) Pinscape is software for the KL25Z that turns the board into a full-featured I/O controller for virtual pinball, with support for accelerometer-based nudging, a real plunger, button inputs, and feedback device control.

In case you haven't heard of the concept before, a "virtual pinball machine" is basically a video pinball simulator that's built into a real pinball machine body. A TV monitor goes in place of the pinball playfield, and a second TV goes in the backbox to serve as the "backglass" display. A third smaller monitor can serve as the "DMD" (the Dot Matrix Display used for scoring on newer machines), or you can even install a real pinball plasma DMD. A computer is hidden inside the cabinet, running pinball emulation software that displays a life-sized playfield on the main TV. The cabinet has all of the usual buttons, too, so it not only looks like the real thing, but plays like it too. That's a picture of my own machine to the right. On the outside, it's built exactly like a real arcade pinball machine, with the same overall dimensions and all of the standard pinball cabinet hardware.

A few small companies build and sell complete, finished virtual pinball machines, but I think it's more fun as a DIY project. If you have some basic wood-working skills and know your way around PCs, you can build one from scratch. The computer part is just an ordinary Windows PC, and all of the pinball emulation can be built out of free, open-source software. In that spirit, the Pinscape Controller is an open-source software/hardware project that offers a no-compromises, all-in-one control center for all of the unique input/output needs of a virtual pinball cabinet. If you've been thinking about building one of these, but you're not sure how to connect a plunger, flipper buttons, lights, nudge sensor, and whatever else you can think of, this project might be just what you're looking for.

You can find much more information about DIY Pin Cab building in general in the Virtual Cabinet Forum on vpforums.org. Also visit my Pinscape Resources page for more about this project and other virtual pinball projects I'm working on.

Downloads

  • Pinscape Release Builds: This page has download links for all of the Pinscape software. To get started, install and run the Pinscape Config Tool on your Windows computer. It will lead you through the steps for installing the Pinscape firmware on the KL25Z.
  • Config Tool Source Code. The complete C# source code for the config tool. You don't need this to run the tool, but it's available if you want to customize anything or see how it works inside.

Documentation

The new Version 2 Build Guide is now complete! This new version aims to be a complete guide to building a virtual pinball machine, including not only the Pinscape elements but all of the basics, from sourcing parts to building all of the hardware.

You can also refer to the original Hardware Build Guide (PDF), but that's out of date now, since it refers to the old version 1 software, which was rather different (especially when it comes to configuration).

System Requirements

The new config tool requires a fairly up-to-date Microsoft .NET installation. If you use Windows Update to keep your system current, you should be fine. A modern version of Internet Explorer (IE) is required, even if you don't use it as your main browser, because the config tool uses some system components that Microsoft packages into the IE install set. I test with IE11, so that's known to work. IE8 doesn't work. IE9 and 10 are unknown at this point.

The Windows requirements are only for the config tool. The firmware doesn't care about anything on the Windows side, so if you can make do without the config tool, you can use almost any Windows setup.

Main Features

Plunger: The Pinscape Controller started out as a "mechanical plunger" controller: a device for attaching a real pinball plunger to the video game software so that you could launch the ball the natural way. This is still, of course, a central feature of the project. The software supports several types of sensors: a high-resolution optical sensor (which works by essentially taking pictures of the plunger as it moves); a slide potentionmeter (which determines the position via the changing electrical resistance in the pot); a quadrature sensor (which counts bars printed on a special guide rail that it moves along); and an IR distance sensor (which determines the position by sending pulses of light at the plunger and measuring the round-trip travel time). The Build Guide explains how to set up each type of sensor.

Nudging: The KL25Z (the little microcontroller that the software runs on) has a built-in accelerometer. The Pinscape software uses it to sense when you nudge the cabinet, and feeds the acceleration data to the pinball software on the PC. This turns physical nudges into virtual English on the ball. The accelerometer is quite sensitive and accurate, so we can measure the difference between little bumps and hard shoves, and everything in between. The result is natural and immersive.

Buttons: You can wire real pinball buttons to the KL25Z, and the software will translate the buttons into PC input. You have the option to map each button to a keyboard key or joystick button. You can wire up your flipper buttons, Magna Save buttons, Start button, coin slots, operator buttons, and whatever else you need.

Feedback devices: You can also attach "feedback devices" to the KL25Z. Feedback devices are things that create tactile, sound, and lighting effects in sync with the game action. The most popular PC pinball emulators know how to address a wide variety of these devices, and know how to match them to on-screen action in each virtual table. You just need an I/O controller that translates commands from the PC into electrical signals that turn the devices on and off. The Pinscape Controller can do that for you.

Expansion Boards

There are two main ways to run the Pinscape Controller: standalone, or using the "expansion boards".

In the basic standalone setup, you just need the KL25Z, plus whatever buttons, sensors, and feedback devices you want to attach to it. This mode lets you take advantage of everything the software can do, but for some features, you'll have to build some ad hoc external circuitry to interface external devices with the KL25Z. The Build Guide has detailed plans for exactly what you need to build.

The other option is the Pinscape Expansion Boards. The expansion boards are a companion project, which is also totally free and open-source, that provides Printed Circuit Board (PCB) layouts that are designed specifically to work with the Pinscape software. The PCB designs are in the widely used EAGLE format, which many PCB manufacturers can turn directly into physical boards for you. The expansion boards organize all of the external connections more neatly than on the standalone KL25Z, and they add all of the interface circuitry needed for all of the advanced software functions. The big thing they bring to the table is lots of high-power outputs. The boards provide a modular system that lets you add boards to add more outputs. If you opt for the basic core setup, you'll have enough outputs for all of the toys in a really well-equipped cabinet. If your ambitions go beyond merely well-equipped and run to the ridiculously extravagant, just add an extra board or two. The modular design also means that you can add to the system over time.

Expansion Board project page

Update notes

If you have a Pinscape V1 setup already installed, you should be able to switch to the new version pretty seamlessly. There are just a couple of things to be aware of.

First, the "configuration" procedure is completely different in the new version. Way better and way easier, but it's not what you're used to from V1. In V1, you had to edit the project source code and compile your own custom version of the program. No more! With V2, you simply install the standard, pre-compiled .bin file, and select options using the Pinscape Config Tool on Windows.

Second, if you're using the TSL1410R optical sensor for your plunger, there's a chance you'll need to boost your light source's brightness a little bit. The "shutter speed" is faster in this version, which means that it doesn't spend as much time collecting light per frame as before. The software actually does "auto exposure" adaptation on every frame, so the increased shutter speed really shouldn't bother it, but it does require a certain minimum level of contrast, which requires a certain minimal level of lighting. Check the plunger viewer in the setup tool if you have any problems; if the image looks totally dark, try increasing the light level to see if that helps.

New Features

V2 has numerous new features. Here are some of the highlights...

Dynamic configuration: as explained above, configuration is now handled through the Config Tool on Windows. It's no longer necessary to edit the source code or compile your own modified binary.

Improved plunger sensing: the software now reads the TSL1410R optical sensor about 15x faster than it did before. This allows reading the sensor at full resolution (400dpi), about 400 times per second. The faster frame rate makes a big difference in how accurately we can read the plunger position during the fast motion of a release, which allows for more precise position sensing and faster response. The differences aren't dramatic, since the sensing was already pretty good even with the slower V1 scan rate, but you might notice a little better precision in tricky skill shots.

Keyboard keys: button inputs can now be mapped to keyboard keys. The joystick button option is still available as well, of course. Keyboard keys have the advantage of being closer to universal for PC pinball software: some pinball software can be set up to take joystick input, but nearly all PC pinball emulators can take keyboard input, and nearly all of them use the same key mappings.

Local shift button: one physical button can be designed as the local shift button. This works like a Shift button on a keyboard, but with cabinet buttons. It allows each physical button on the cabinet to have two PC keys assigned, one normal and one shifted. Hold down the local shift button, then press another key, and the other key's shifted key mapping is sent to the PC. The shift button can have a regular key mapping of its own as well, so it can do double duty. The shift feature lets you access more functions without cluttering your cabinet with extra buttons. It's especially nice for less frequently used functions like adjusting the volume or activating night mode.

Night mode: the output controller has a new "night mode" option, which lets you turn off all of your noisy devices with a single button, switch, or PC command. You can designate individual ports as noisy or not. Night mode only disables the noisemakers, so you still get the benefit of your flashers, button lights, and other quiet devices. This lets you play late into the night without disturbing your housemates or neighbors.

Gamma correction: you can designate individual output ports for gamma correction. This adjusts the intensity level of an output to make it match the way the human eye perceives brightness, so that fades and color mixes look more natural in lighting devices. You can apply this to individual ports, so that it only affects ports that actually have lights of some kind attached.

IR Remote Control: the controller software can transmit and/or receive IR remote control commands if you attach appropriate parts (an IR LED to send, an IR sensor chip to receive). This can be used to turn on your TV(s) when the system powers on, if they don't turn on automatically, and for any other functions you can think of requiring IR send/receive capabilities. You can assign IR commands to cabinet buttons, so that pressing a button on your cabinet sends a remote control command from the attached IR LED, and you can have the controller generate virtual key presses on your PC in response to received IR commands. If you have the IR sensor attached, the system can use it to learn commands from your existing remotes.

Yet more USB fixes: I've been gradually finding and fixing USB bugs in the mbed library for months now. This version has all of the fixes of the last couple of releases, of course, plus some new ones. It also has a new "last resort" feature, since there always seems to be "just one more" USB bug. The last resort is that you can tell the device to automatically reboot itself if it loses the USB connection and can't restore it within a given time limit.

More Downloads

  • Custom VP builds: I created modified versions of Visual Pinball 9.9 and Physmod5 that you might want to use in combination with this controller. The modified versions have special handling for plunger calibration specific to the Pinscape Controller, as well as some enhancements to the nudge physics. If you're not using the plunger, you might still want it for the nudge improvements. The modified version also works with any other input controller, so you can get the enhanced nudging effects even if you're using a different plunger/nudge kit. The big change in the modified versions is a "filter" for accelerometer input that's designed to make the response to cabinet nudges more realistic. It also makes the response more subdued than in the standard VP, so it's not to everyone's taste. The downloads include both the updated executables and the source code changes, in case you want to merge the changes into your own custom version(s).

    Note! These features are now standard in the official VP releases, so you don't need my custom builds if you're using 9.9.1 or later and/or VP 10. I don't think there's any reason to use my versions instead of the latest official ones, and in fact I'd encourage you to use the official releases since they're more up to date, but I'm leaving my builds available just in case. In the official versions, look for the checkbox "Enable Nudge Filter" in the Keys preferences dialog. My custom versions don't include that checkbox; they just enable the filter unconditionally.
  • Output circuit shopping list: This is a saved shopping cart at mouser.com with the parts needed to build one copy of the high-power output circuit for the LedWiz emulator feature, for use with the standalone KL25Z (that is, without the expansion boards). The quantities in the cart are for one output channel, so if you want N outputs, simply multiply the quantities by the N, with one exception: you only need one ULN2803 transistor array chip for each eight output circuits. If you're using the expansion boards, you won't need any of this, since the boards provide their own high-power outputs.
  • Cary Owens' optical sensor housing: A 3D-printable design for a housing/mounting bracket for the optical plunger sensor, designed by Cary Owens. This makes it easy to mount the sensor.
  • Lemming77's potentiometer mounting bracket and shooter rod connecter: Sketchup designs for 3D-printable parts for mounting a slide potentiometer as the plunger sensor. These were designed for a particular slide potentiometer that used to be available from an Aliexpress.com seller but is no longer listed. You can probably use this design as a starting point for other similar devices; just check the dimensions before committing the design to plastic.

Copyright and License

The Pinscape firmware is copyright 2014, 2021 by Michael J Roberts. It's released under an MIT open-source license. See License.

Warning to VirtuaPin Kit Owners

This software isn't designed as a replacement for the VirtuaPin plunger kit's firmware. If you bought the VirtuaPin kit, I recommend that you don't install this software. The VirtuaPin kit uses the same KL25Z microcontroller that Pinscape uses, but the rest of its hardware is different and incompatible. In particular, the Pinscape firmware doesn't include support for the IR proximity sensor used in the VirtuaPin plunger kit, so you won't be able to use your plunger device with the Pinscape firmware. In addition, the VirtuaPin setup uses a different set of GPIO pins for the button inputs from the Pinscape defaults, so if you do install the Pinscape firmware, you'll have to go into the Config Tool and reassign all of the buttons to match the VirtuaPin wiring.

Committer:
mjr
Date:
Wed Jan 04 20:14:12 2017 +0000
Revision:
72:884207c0aab0
Parent:
70:9f58735a1732
Child:
73:4e8ce0b18915
Include shifted buttons when deciding whether or not to create a USB keyboard interface during initialization

Who changed what in which revision?

UserRevisionLine numberNew contents of line
mjr 51:57eb311faafa 1 /* Copyright 2014, 2016 M J Roberts, MIT License
mjr 5:a70c0bce770d 2 *
mjr 5:a70c0bce770d 3 * Permission is hereby granted, free of charge, to any person obtaining a copy of this software
mjr 5:a70c0bce770d 4 * and associated documentation files (the "Software"), to deal in the Software without
mjr 5:a70c0bce770d 5 * restriction, including without limitation the rights to use, copy, modify, merge, publish,
mjr 5:a70c0bce770d 6 * distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the
mjr 5:a70c0bce770d 7 * Software is furnished to do so, subject to the following conditions:
mjr 5:a70c0bce770d 8 *
mjr 5:a70c0bce770d 9 * The above copyright notice and this permission notice shall be included in all copies or
mjr 5:a70c0bce770d 10 * substantial portions of the Software.
mjr 5:a70c0bce770d 11 *
mjr 5:a70c0bce770d 12 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
mjr 48:058ace2aed1d 13 * BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILIT Y, FITNESS FOR A PARTICULAR PURPOSE AND
mjr 5:a70c0bce770d 14 * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
mjr 5:a70c0bce770d 15 * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
mjr 5:a70c0bce770d 16 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
mjr 5:a70c0bce770d 17 */
mjr 5:a70c0bce770d 18
mjr 5:a70c0bce770d 19 //
mjr 35:e959ffba78fd 20 // The Pinscape Controller
mjr 35:e959ffba78fd 21 // A comprehensive input/output controller for virtual pinball machines
mjr 5:a70c0bce770d 22 //
mjr 48:058ace2aed1d 23 // This project implements an I/O controller for virtual pinball cabinets. The
mjr 48:058ace2aed1d 24 // controller's function is to connect Visual Pinball (and other Windows pinball
mjr 48:058ace2aed1d 25 // emulators) with physical devices in the cabinet: buttons, sensors, and
mjr 48:058ace2aed1d 26 // feedback devices that create visual or mechanical effects during play.
mjr 38:091e511ce8a0 27 //
mjr 48:058ace2aed1d 28 // The controller can perform several different functions, which can be used
mjr 38:091e511ce8a0 29 // individually or in any combination:
mjr 5:a70c0bce770d 30 //
mjr 38:091e511ce8a0 31 // - Nudge sensing. This uses the KL25Z's on-board accelerometer to sense the
mjr 38:091e511ce8a0 32 // motion of the cabinet when you nudge it. Visual Pinball and other pinball
mjr 38:091e511ce8a0 33 // emulators on the PC have native handling for this type of input, so that
mjr 38:091e511ce8a0 34 // physical nudges on the cabinet turn into simulated effects on the virtual
mjr 38:091e511ce8a0 35 // ball. The KL25Z measures accelerations as analog readings and is quite
mjr 38:091e511ce8a0 36 // sensitive, so the effect of a nudge on the simulation is proportional
mjr 38:091e511ce8a0 37 // to the strength of the nudge. Accelerations are reported to the PC via a
mjr 38:091e511ce8a0 38 // simulated joystick (using the X and Y axes); you just have to set some
mjr 38:091e511ce8a0 39 // preferences in your pinball software to tell it that an accelerometer
mjr 38:091e511ce8a0 40 // is attached.
mjr 5:a70c0bce770d 41 //
mjr 38:091e511ce8a0 42 // - Plunger position sensing, with mulitple sensor options. To use this feature,
mjr 35:e959ffba78fd 43 // you need to choose a sensor and set it up, connect the sensor electrically to
mjr 35:e959ffba78fd 44 // the KL25Z, and configure the Pinscape software on the KL25Z to let it know how
mjr 35:e959ffba78fd 45 // the sensor is hooked up. The Pinscape software monitors the sensor and sends
mjr 35:e959ffba78fd 46 // readings to Visual Pinball via the joystick Z axis. VP and other PC software
mjr 38:091e511ce8a0 47 // have native support for this type of input; as with the nudge setup, you just
mjr 38:091e511ce8a0 48 // have to set some options in VP to activate the plunger.
mjr 17:ab3cec0c8bf4 49 //
mjr 35:e959ffba78fd 50 // The Pinscape software supports optical sensors (the TAOS TSL1410R and TSL1412R
mjr 35:e959ffba78fd 51 // linear sensor arrays) as well as slide potentiometers. The specific equipment
mjr 35:e959ffba78fd 52 // that's supported, along with physical mounting and wiring details, can be found
mjr 35:e959ffba78fd 53 // in the Build Guide.
mjr 35:e959ffba78fd 54 //
mjr 38:091e511ce8a0 55 // Note VP has built-in support for plunger devices like this one, but some VP
mjr 38:091e511ce8a0 56 // tables can't use it without some additional scripting work. The Build Guide has
mjr 38:091e511ce8a0 57 // advice on adjusting tables to add plunger support when necessary.
mjr 5:a70c0bce770d 58 //
mjr 6:cc35eb643e8f 59 // For best results, the plunger sensor should be calibrated. The calibration
mjr 6:cc35eb643e8f 60 // is stored in non-volatile memory on board the KL25Z, so it's only necessary
mjr 6:cc35eb643e8f 61 // to do the calibration once, when you first install everything. (You might
mjr 6:cc35eb643e8f 62 // also want to re-calibrate if you physically remove and reinstall the CCD
mjr 17:ab3cec0c8bf4 63 // sensor or the mechanical plunger, since their alignment shift change slightly
mjr 17:ab3cec0c8bf4 64 // when you put everything back together.) You can optionally install a
mjr 17:ab3cec0c8bf4 65 // dedicated momentary switch or pushbutton to activate the calibration mode;
mjr 17:ab3cec0c8bf4 66 // this is describe in the project documentation. If you don't want to bother
mjr 17:ab3cec0c8bf4 67 // with the extra button, you can also trigger calibration using the Windows
mjr 17:ab3cec0c8bf4 68 // setup software, which you can find on the Pinscape project page.
mjr 6:cc35eb643e8f 69 //
mjr 17:ab3cec0c8bf4 70 // The calibration procedure is described in the project documentation. Briefly,
mjr 17:ab3cec0c8bf4 71 // when you trigger calibration mode, the software will scan the CCD for about
mjr 17:ab3cec0c8bf4 72 // 15 seconds, during which you should simply pull the physical plunger back
mjr 17:ab3cec0c8bf4 73 // all the way, hold it for a moment, and then slowly return it to the rest
mjr 17:ab3cec0c8bf4 74 // position. (DON'T just release it from the retracted position, since that
mjr 17:ab3cec0c8bf4 75 // let it shoot forward too far. We want to measure the range from the park
mjr 17:ab3cec0c8bf4 76 // position to the fully retracted position only.)
mjr 5:a70c0bce770d 77 //
mjr 13:72dda449c3c0 78 // - Button input wiring. 24 of the KL25Z's GPIO ports are mapped as digital inputs
mjr 38:091e511ce8a0 79 // for buttons and switches. You can wire each input to a physical pinball-style
mjr 38:091e511ce8a0 80 // button or switch, such as flipper buttons, Start buttons, coin chute switches,
mjr 38:091e511ce8a0 81 // tilt bobs, and service buttons. Each button can be configured to be reported
mjr 38:091e511ce8a0 82 // to the PC as a joystick button or as a keyboard key (you can select which key
mjr 38:091e511ce8a0 83 // is used for each button).
mjr 13:72dda449c3c0 84 //
mjr 53:9b2611964afc 85 // - LedWiz emulation. The KL25Z can pretend to be an LedWiz device. This lets
mjr 53:9b2611964afc 86 // you connect feedback devices (lights, solenoids, motors) to GPIO ports on the
mjr 53:9b2611964afc 87 // KL25Z, and lets PC software (such as Visual Pinball) control them during game
mjr 53:9b2611964afc 88 // play to create a more immersive playing experience. The Pinscape software
mjr 53:9b2611964afc 89 // presents itself to the host as an LedWiz device and accepts the full LedWiz
mjr 53:9b2611964afc 90 // command set, so software on the PC designed for real LedWiz'es can control
mjr 53:9b2611964afc 91 // attached devices without any modifications.
mjr 5:a70c0bce770d 92 //
mjr 53:9b2611964afc 93 // Even though the software provides a very thorough LedWiz emulation, the KL25Z
mjr 53:9b2611964afc 94 // GPIO hardware design imposes some serious limitations. The big one is that
mjr 53:9b2611964afc 95 // the KL25Z only has 10 PWM channels, meaning that only 10 ports can have
mjr 53:9b2611964afc 96 // varying-intensity outputs (e.g., for controlling the brightness level of an
mjr 53:9b2611964afc 97 // LED or the speed or a motor). You can control more than 10 output ports, but
mjr 53:9b2611964afc 98 // only 10 can have PWM control; the rest are simple "digital" ports that can only
mjr 53:9b2611964afc 99 // be switched fully on or fully off. The second limitation is that the KL25Z
mjr 53:9b2611964afc 100 // just doesn't have that many GPIO ports overall. There are enough to populate
mjr 53:9b2611964afc 101 // all 32 button inputs OR all 32 LedWiz outputs, but not both. The default is
mjr 53:9b2611964afc 102 // to assign 24 buttons and 22 LedWiz ports; you can change this balance to trade
mjr 53:9b2611964afc 103 // off more outputs for fewer inputs, or vice versa. The third limitation is that
mjr 53:9b2611964afc 104 // the KL25Z GPIO pins have *very* tiny amperage limits - just 4mA, which isn't
mjr 53:9b2611964afc 105 // even enough to control a small LED. So in order to connect any kind of feedback
mjr 53:9b2611964afc 106 // device to an output, you *must* build some external circuitry to boost the
mjr 53:9b2611964afc 107 // current handing. The Build Guide has a reference circuit design for this
mjr 53:9b2611964afc 108 // purpose that's simple and inexpensive to build.
mjr 6:cc35eb643e8f 109 //
mjr 26:cb71c4af2912 110 // - Enhanced LedWiz emulation with TLC5940 PWM controller chips. You can attach
mjr 26:cb71c4af2912 111 // external PWM controller chips for controlling device outputs, instead of using
mjr 53:9b2611964afc 112 // the on-board GPIO ports as described above. The software can control a set of
mjr 53:9b2611964afc 113 // daisy-chained TLC5940 chips. Each chip provides 16 PWM outputs, so you just
mjr 53:9b2611964afc 114 // need two of them to get the full complement of 32 output ports of a real LedWiz.
mjr 53:9b2611964afc 115 // You can hook up even more, though. Four chips gives you 64 ports, which should
mjr 53:9b2611964afc 116 // be plenty for nearly any virtual pinball project. To accommodate the larger
mjr 53:9b2611964afc 117 // supply of ports possible with the PWM chips, the controller software provides
mjr 53:9b2611964afc 118 // a custom, extended version of the LedWiz protocol that can handle up to 128
mjr 53:9b2611964afc 119 // ports. PC software designed only for the real LedWiz obviously won't know
mjr 53:9b2611964afc 120 // about the extended protocol and won't be able to take advantage of its extra
mjr 53:9b2611964afc 121 // capabilities, but the latest version of DOF (DirectOutput Framework) *does*
mjr 53:9b2611964afc 122 // know the new language and can take full advantage. Older software will still
mjr 53:9b2611964afc 123 // work, though - the new extensions are all backward compatible, so old software
mjr 53:9b2611964afc 124 // that only knows about the original LedWiz protocol will still work, with the
mjr 53:9b2611964afc 125 // obvious limitation that it can only access the first 32 ports.
mjr 53:9b2611964afc 126 //
mjr 53:9b2611964afc 127 // The Pinscape Expansion Board project (which appeared in early 2016) provides
mjr 53:9b2611964afc 128 // a reference hardware design, with EAGLE circuit board layouts, that takes full
mjr 53:9b2611964afc 129 // advantage of the TLC5940 capability. It lets you create a customized set of
mjr 53:9b2611964afc 130 // outputs with full PWM control and power handling for high-current devices
mjr 53:9b2611964afc 131 // built in to the boards.
mjr 26:cb71c4af2912 132 //
mjr 38:091e511ce8a0 133 // - Night Mode control for output devices. You can connect a switch or button
mjr 38:091e511ce8a0 134 // to the controller to activate "Night Mode", which disables feedback devices
mjr 38:091e511ce8a0 135 // that you designate as noisy. You can designate outputs individually as being
mjr 38:091e511ce8a0 136 // included in this set or not. This is useful if you want to play a game on
mjr 38:091e511ce8a0 137 // your cabinet late at night without waking the kids and annoying the neighbors.
mjr 38:091e511ce8a0 138 //
mjr 38:091e511ce8a0 139 // - TV ON switch. The controller can pulse a relay to turn on your TVs after
mjr 38:091e511ce8a0 140 // power to the cabinet comes on, with a configurable delay timer. This feature
mjr 38:091e511ce8a0 141 // is for TVs that don't turn themselves on automatically when first plugged in.
mjr 38:091e511ce8a0 142 // To use this feature, you have to build some external circuitry to allow the
mjr 38:091e511ce8a0 143 // software to sense the power supply status, and you have to run wires to your
mjr 38:091e511ce8a0 144 // TV's on/off button, which requires opening the case on your TV. The Build
mjr 38:091e511ce8a0 145 // Guide has details on the necessary circuitry and connections to the TV.
mjr 38:091e511ce8a0 146 //
mjr 35:e959ffba78fd 147 //
mjr 35:e959ffba78fd 148 //
mjr 33:d832bcab089e 149 // STATUS LIGHTS: The on-board LED on the KL25Z flashes to indicate the current
mjr 33:d832bcab089e 150 // device status. The flash patterns are:
mjr 6:cc35eb643e8f 151 //
mjr 48:058ace2aed1d 152 // short yellow flash = waiting to connect
mjr 6:cc35eb643e8f 153 //
mjr 48:058ace2aed1d 154 // short red flash = the connection is suspended (the host is in sleep
mjr 48:058ace2aed1d 155 // or suspend mode, the USB cable is unplugged after a connection
mjr 48:058ace2aed1d 156 // has been established)
mjr 48:058ace2aed1d 157 //
mjr 48:058ace2aed1d 158 // two short red flashes = connection lost (the device should immediately
mjr 48:058ace2aed1d 159 // go back to short-yellow "waiting to reconnect" mode when a connection
mjr 48:058ace2aed1d 160 // is lost, so this display shouldn't normally appear)
mjr 6:cc35eb643e8f 161 //
mjr 38:091e511ce8a0 162 // long red/yellow = USB connection problem. The device still has a USB
mjr 48:058ace2aed1d 163 // connection to the host (or so it appears to the device), but data
mjr 48:058ace2aed1d 164 // transmissions are failing.
mjr 38:091e511ce8a0 165 //
mjr 6:cc35eb643e8f 166 // long yellow/green = everything's working, but the plunger hasn't
mjr 38:091e511ce8a0 167 // been calibrated. Follow the calibration procedure described in
mjr 38:091e511ce8a0 168 // the project documentation. This flash mode won't appear if there's
mjr 38:091e511ce8a0 169 // no plunger sensor configured.
mjr 6:cc35eb643e8f 170 //
mjr 38:091e511ce8a0 171 // alternating blue/green = everything's working normally, and plunger
mjr 38:091e511ce8a0 172 // calibration has been completed (or there's no plunger attached)
mjr 10:976666ffa4ef 173 //
mjr 48:058ace2aed1d 174 // fast red/purple = out of memory. The controller halts and displays
mjr 48:058ace2aed1d 175 // this diagnostic code until you manually reset it. If this happens,
mjr 48:058ace2aed1d 176 // it's probably because the configuration is too complex, in which
mjr 48:058ace2aed1d 177 // case the same error will occur after the reset. If it's stuck
mjr 48:058ace2aed1d 178 // in this cycle, you'll have to restore the default configuration
mjr 48:058ace2aed1d 179 // by re-installing the controller software (the Pinscape .bin file).
mjr 10:976666ffa4ef 180 //
mjr 48:058ace2aed1d 181 //
mjr 48:058ace2aed1d 182 // USB PROTOCOL: Most of our USB messaging is through standard USB HID
mjr 48:058ace2aed1d 183 // classes (joystick, keyboard). We also accept control messages on our
mjr 48:058ace2aed1d 184 // primary HID interface "OUT endpoint" using a custom protocol that's
mjr 48:058ace2aed1d 185 // not defined in any USB standards (we do have to provide a USB HID
mjr 48:058ace2aed1d 186 // Report Descriptor for it, but this just describes the protocol as
mjr 48:058ace2aed1d 187 // opaque vendor-defined bytes). The control protocol incorporates the
mjr 48:058ace2aed1d 188 // LedWiz protocol as a subset, and adds our own private extensions.
mjr 48:058ace2aed1d 189 // For full details, see USBProtocol.h.
mjr 33:d832bcab089e 190
mjr 33:d832bcab089e 191
mjr 0:5acbbe3f4cf4 192 #include "mbed.h"
mjr 6:cc35eb643e8f 193 #include "math.h"
mjr 48:058ace2aed1d 194 #include "pinscape.h"
mjr 0:5acbbe3f4cf4 195 #include "USBJoystick.h"
mjr 0:5acbbe3f4cf4 196 #include "MMA8451Q.h"
mjr 1:d913e0afb2ac 197 #include "tsl1410r.h"
mjr 1:d913e0afb2ac 198 #include "FreescaleIAP.h"
mjr 2:c174f9ee414a 199 #include "crc32.h"
mjr 26:cb71c4af2912 200 #include "TLC5940.h"
mjr 34:6b981a2afab7 201 #include "74HC595.h"
mjr 35:e959ffba78fd 202 #include "nvm.h"
mjr 35:e959ffba78fd 203 #include "plunger.h"
mjr 35:e959ffba78fd 204 #include "ccdSensor.h"
mjr 35:e959ffba78fd 205 #include "potSensor.h"
mjr 35:e959ffba78fd 206 #include "nullSensor.h"
mjr 48:058ace2aed1d 207 #include "TinyDigitalIn.h"
mjr 64:ef7ca92dff36 208 #include "FastPWM.h"
mjr 2:c174f9ee414a 209
mjr 21:5048e16cc9ef 210 #define DECL_EXTERNS
mjr 17:ab3cec0c8bf4 211 #include "config.h"
mjr 17:ab3cec0c8bf4 212
mjr 53:9b2611964afc 213
mjr 53:9b2611964afc 214 // --------------------------------------------------------------------------
mjr 53:9b2611964afc 215 //
mjr 53:9b2611964afc 216 // OpenSDA module identifier. This is for the benefit of the Windows
mjr 53:9b2611964afc 217 // configuration tool. When the config tool installs a .bin file onto
mjr 53:9b2611964afc 218 // the KL25Z, it will first find the sentinel string within the .bin file,
mjr 53:9b2611964afc 219 // and patch the "\0" bytes that follow the sentinel string with the
mjr 53:9b2611964afc 220 // OpenSDA module ID data. This allows us to report the OpenSDA
mjr 53:9b2611964afc 221 // identifiers back to the host system via USB, which in turn allows the
mjr 53:9b2611964afc 222 // config tool to figure out which OpenSDA MSD (mass storage device - a
mjr 53:9b2611964afc 223 // virtual disk drive) correlates to which Pinscape controller USB
mjr 53:9b2611964afc 224 // interface.
mjr 53:9b2611964afc 225 //
mjr 53:9b2611964afc 226 // This is only important if multiple Pinscape devices are attached to
mjr 53:9b2611964afc 227 // the same host. There doesn't seem to be any other way to figure out
mjr 53:9b2611964afc 228 // which OpenSDA MSD corresponds to which KL25Z USB interface; the OpenSDA
mjr 53:9b2611964afc 229 // MSD doesn't report the KL25Z CPU ID anywhere, and the KL25Z doesn't
mjr 53:9b2611964afc 230 // have any way to learn about the OpenSDA module it's connected to. The
mjr 53:9b2611964afc 231 // only way to pass this information to the KL25Z side that I can come up
mjr 53:9b2611964afc 232 // with is to have the Windows host embed it in the .bin file before
mjr 53:9b2611964afc 233 // downloading it to the OpenSDA MSD.
mjr 53:9b2611964afc 234 //
mjr 53:9b2611964afc 235 // We initialize the const data buffer (the part after the sentinel string)
mjr 53:9b2611964afc 236 // with all "\0" bytes, so that's what will be in the executable image that
mjr 53:9b2611964afc 237 // comes out of the mbed compiler. If you manually install the resulting
mjr 53:9b2611964afc 238 // .bin file onto the KL25Z (via the Windows desktop, say), the "\0" bytes
mjr 53:9b2611964afc 239 // will stay this way and read as all 0's at run-time. Since a real TUID
mjr 53:9b2611964afc 240 // would never be all 0's, that tells us that we were never patched and
mjr 53:9b2611964afc 241 // thus don't have any information on the OpenSDA module.
mjr 53:9b2611964afc 242 //
mjr 53:9b2611964afc 243 const char *getOpenSDAID()
mjr 53:9b2611964afc 244 {
mjr 53:9b2611964afc 245 #define OPENSDA_PREFIX "///Pinscape.OpenSDA.TUID///"
mjr 53:9b2611964afc 246 static const char OpenSDA[] = OPENSDA_PREFIX "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0///";
mjr 53:9b2611964afc 247 const size_t OpenSDA_prefix_length = sizeof(OPENSDA_PREFIX) - 1;
mjr 53:9b2611964afc 248
mjr 53:9b2611964afc 249 return OpenSDA + OpenSDA_prefix_length;
mjr 53:9b2611964afc 250 }
mjr 53:9b2611964afc 251
mjr 53:9b2611964afc 252 // --------------------------------------------------------------------------
mjr 53:9b2611964afc 253 //
mjr 53:9b2611964afc 254 // Build ID. We use the date and time of compiling the program as a build
mjr 53:9b2611964afc 255 // identifier. It would be a little nicer to use a simple serial number
mjr 53:9b2611964afc 256 // instead, but the mbed platform doesn't have a way to automate that. The
mjr 53:9b2611964afc 257 // timestamp is a pretty good proxy for a serial number in that it will
mjr 53:9b2611964afc 258 // naturally increase on each new build, which is the primary property we
mjr 53:9b2611964afc 259 // want from this.
mjr 53:9b2611964afc 260 //
mjr 53:9b2611964afc 261 // As with the embedded OpenSDA ID, we store the build timestamp with a
mjr 53:9b2611964afc 262 // sentinel string prefix, to allow automated tools to find the static data
mjr 53:9b2611964afc 263 // in the .bin file by searching for the sentinel string. In contrast to
mjr 53:9b2611964afc 264 // the OpenSDA ID, the value we store here is for tools to extract rather
mjr 53:9b2611964afc 265 // than store, since we automatically populate it via the preprocessor
mjr 53:9b2611964afc 266 // macros.
mjr 53:9b2611964afc 267 //
mjr 53:9b2611964afc 268 const char *getBuildID()
mjr 53:9b2611964afc 269 {
mjr 53:9b2611964afc 270 #define BUILDID_PREFIX "///Pinscape.Build.ID///"
mjr 53:9b2611964afc 271 static const char BuildID[] = BUILDID_PREFIX __DATE__ " " __TIME__ "///";
mjr 53:9b2611964afc 272 const size_t BuildID_prefix_length = sizeof(BUILDID_PREFIX) - 1;
mjr 53:9b2611964afc 273
mjr 53:9b2611964afc 274 return BuildID + BuildID_prefix_length;
mjr 53:9b2611964afc 275 }
mjr 53:9b2611964afc 276
mjr 53:9b2611964afc 277
mjr 48:058ace2aed1d 278 // --------------------------------------------------------------------------
mjr 48:058ace2aed1d 279 //
mjr 59:94eb9265b6d7 280 // Custom memory allocator. We use our own version of malloc() for more
mjr 59:94eb9265b6d7 281 // efficient memory usage, and to provide diagnostics if we run out of heap.
mjr 48:058ace2aed1d 282 //
mjr 59:94eb9265b6d7 283 // We can implement a more efficient malloc than the library can because we
mjr 59:94eb9265b6d7 284 // can make an assumption that the library can't: allocations are permanent.
mjr 59:94eb9265b6d7 285 // The normal malloc has to assume that allocations can be freed, so it has
mjr 59:94eb9265b6d7 286 // to track blocks individually. For the purposes of this program, though,
mjr 59:94eb9265b6d7 287 // we don't have to do this because virtually all of our allocations are
mjr 59:94eb9265b6d7 288 // de facto permanent. We only allocate dyanmic memory during setup, and
mjr 59:94eb9265b6d7 289 // once we set things up, we never delete anything. This means that we can
mjr 59:94eb9265b6d7 290 // allocate memory in bare blocks without any bookkeeping overhead.
mjr 59:94eb9265b6d7 291 //
mjr 59:94eb9265b6d7 292 // In addition, we can make a much larger overall pool of memory available
mjr 59:94eb9265b6d7 293 // in a custom allocator. The mbed library malloc() seems to have a pool
mjr 59:94eb9265b6d7 294 // of about 3K to work with, even though there's really about 9K of RAM
mjr 59:94eb9265b6d7 295 // left over after counting the static writable data and reserving space
mjr 59:94eb9265b6d7 296 // for a reasonable stack. I haven't looked at the mbed malloc to see why
mjr 59:94eb9265b6d7 297 // they're so stingy, but it appears from empirical testing that we can
mjr 59:94eb9265b6d7 298 // create a static array up to about 9K before things get crashy.
mjr 59:94eb9265b6d7 299
mjr 48:058ace2aed1d 300 void *xmalloc(size_t siz)
mjr 48:058ace2aed1d 301 {
mjr 59:94eb9265b6d7 302 // Dynamic memory pool. We'll reserve space for all dynamic
mjr 59:94eb9265b6d7 303 // allocations by creating a simple C array of bytes. The size
mjr 59:94eb9265b6d7 304 // of this array is the maximum number of bytes we can allocate
mjr 59:94eb9265b6d7 305 // with malloc or operator 'new'.
mjr 59:94eb9265b6d7 306 //
mjr 59:94eb9265b6d7 307 // The maximum safe size for this array is, in essence, the
mjr 59:94eb9265b6d7 308 // amount of physical KL25Z RAM left over after accounting for
mjr 59:94eb9265b6d7 309 // static data throughout the rest of the program, the run-time
mjr 59:94eb9265b6d7 310 // stack, and any other space reserved for compiler or MCU
mjr 59:94eb9265b6d7 311 // overhead. Unfortunately, it's not straightforward to
mjr 59:94eb9265b6d7 312 // determine this analytically. The big complication is that
mjr 59:94eb9265b6d7 313 // the minimum stack size isn't easily predictable, as the stack
mjr 59:94eb9265b6d7 314 // grows according to what the program does. In addition, the
mjr 59:94eb9265b6d7 315 // mbed platform tools don't give us detailed data on the
mjr 59:94eb9265b6d7 316 // compiler/linker memory map. All we get is a generic total
mjr 59:94eb9265b6d7 317 // RAM requirement, which doesn't necessarily account for all
mjr 59:94eb9265b6d7 318 // overhead (e.g., gaps inserted to get proper alignment for
mjr 59:94eb9265b6d7 319 // particular memory blocks).
mjr 59:94eb9265b6d7 320 //
mjr 59:94eb9265b6d7 321 // A very rough estimate: the total RAM size reported by the
mjr 59:94eb9265b6d7 322 // linker is about 3.5K (currently - that can obviously change
mjr 59:94eb9265b6d7 323 // as the project evolves) out of 16K total. Assuming about a
mjr 59:94eb9265b6d7 324 // 3K stack, that leaves in the ballpark of 10K. Empirically,
mjr 59:94eb9265b6d7 325 // that seems pretty close. In testing, we start to see some
mjr 59:94eb9265b6d7 326 // instability at 10K, while 9K seems safe. To be conservative,
mjr 59:94eb9265b6d7 327 // we'll reduce this to 8K.
mjr 59:94eb9265b6d7 328 //
mjr 59:94eb9265b6d7 329 // Our measured total usage in the base configuration (22 GPIO
mjr 59:94eb9265b6d7 330 // output ports, TSL1410R plunger sensor) is about 4000 bytes.
mjr 59:94eb9265b6d7 331 // A pretty fully decked-out configuration (121 output ports,
mjr 59:94eb9265b6d7 332 // with 8 TLC5940 chips and 3 74HC595 chips, plus the TSL1412R
mjr 59:94eb9265b6d7 333 // sensor with the higher pixel count, and all expansion board
mjr 59:94eb9265b6d7 334 // features enabled) comes to about 6700 bytes. That leaves
mjr 59:94eb9265b6d7 335 // us with about 1.5K free out of our 8K, so we still have a
mjr 59:94eb9265b6d7 336 // little more headroom for future expansion.
mjr 59:94eb9265b6d7 337 //
mjr 59:94eb9265b6d7 338 // For comparison, the standard mbed malloc() runs out of
mjr 59:94eb9265b6d7 339 // memory at about 6K. That's what led to this custom malloc:
mjr 59:94eb9265b6d7 340 // we can just fit the base configuration into that 4K, but
mjr 59:94eb9265b6d7 341 // it's not enough space for more complex setups. There's
mjr 59:94eb9265b6d7 342 // still a little room for squeezing out unnecessary space
mjr 59:94eb9265b6d7 343 // from the mbed library code, but at this point I'd prefer
mjr 59:94eb9265b6d7 344 // to treat that as a last resort, since it would mean having
mjr 59:94eb9265b6d7 345 // to fork private copies of the libraries.
mjr 59:94eb9265b6d7 346 static char pool[8*1024];
mjr 59:94eb9265b6d7 347 static char *nxt = pool;
mjr 59:94eb9265b6d7 348 static size_t rem = sizeof(pool);
mjr 59:94eb9265b6d7 349
mjr 59:94eb9265b6d7 350 // align to a 4-byte increment
mjr 59:94eb9265b6d7 351 siz = (siz + 3) & ~3;
mjr 59:94eb9265b6d7 352
mjr 59:94eb9265b6d7 353 // If insufficient memory is available, halt and show a fast red/purple
mjr 59:94eb9265b6d7 354 // diagnostic flash. We don't want to return, since we assume throughout
mjr 59:94eb9265b6d7 355 // the program that all memory allocations must succeed. Note that this
mjr 59:94eb9265b6d7 356 // is generally considered bad programming practice in applications on
mjr 59:94eb9265b6d7 357 // "real" computers, but for the purposes of this microcontroller app,
mjr 59:94eb9265b6d7 358 // there's no point in checking for failed allocations individually
mjr 59:94eb9265b6d7 359 // because there's no way to recover from them. It's better in this
mjr 59:94eb9265b6d7 360 // context to handle failed allocations as fatal errors centrally. We
mjr 59:94eb9265b6d7 361 // can't recover from these automatically, so we have to resort to user
mjr 59:94eb9265b6d7 362 // intervention, which we signal with the diagnostic LED flashes.
mjr 59:94eb9265b6d7 363 if (siz > rem)
mjr 59:94eb9265b6d7 364 {
mjr 59:94eb9265b6d7 365 // halt with the diagnostic display (by looping forever)
mjr 59:94eb9265b6d7 366 for (;;)
mjr 59:94eb9265b6d7 367 {
mjr 59:94eb9265b6d7 368 diagLED(1, 0, 0);
mjr 59:94eb9265b6d7 369 wait_us(200000);
mjr 59:94eb9265b6d7 370 diagLED(1, 0, 1);
mjr 59:94eb9265b6d7 371 wait_us(200000);
mjr 59:94eb9265b6d7 372 }
mjr 59:94eb9265b6d7 373 }
mjr 48:058ace2aed1d 374
mjr 59:94eb9265b6d7 375 // get the next free location from the pool to return
mjr 59:94eb9265b6d7 376 char *ret = nxt;
mjr 59:94eb9265b6d7 377
mjr 59:94eb9265b6d7 378 // advance the pool pointer and decrement the remaining size counter
mjr 59:94eb9265b6d7 379 nxt += siz;
mjr 59:94eb9265b6d7 380 rem -= siz;
mjr 59:94eb9265b6d7 381
mjr 59:94eb9265b6d7 382 // return the allocated block
mjr 59:94eb9265b6d7 383 return ret;
mjr 48:058ace2aed1d 384 }
mjr 48:058ace2aed1d 385
mjr 59:94eb9265b6d7 386 // Overload operator new to call our custom malloc. This ensures that
mjr 59:94eb9265b6d7 387 // all 'new' allocations throughout the program (including library code)
mjr 59:94eb9265b6d7 388 // go through our private allocator.
mjr 48:058ace2aed1d 389 void *operator new(size_t siz) { return xmalloc(siz); }
mjr 48:058ace2aed1d 390 void *operator new[](size_t siz) { return xmalloc(siz); }
mjr 5:a70c0bce770d 391
mjr 59:94eb9265b6d7 392 // Since we don't do bookkeeping to track released memory, 'delete' does
mjr 59:94eb9265b6d7 393 // nothing. In actual testing, this routine appears to never be called.
mjr 59:94eb9265b6d7 394 // If it *is* ever called, it will simply leave the block in place, which
mjr 59:94eb9265b6d7 395 // will make it unavailable for re-use but will otherwise be harmless.
mjr 59:94eb9265b6d7 396 void operator delete(void *ptr) { }
mjr 59:94eb9265b6d7 397
mjr 59:94eb9265b6d7 398
mjr 5:a70c0bce770d 399 // ---------------------------------------------------------------------------
mjr 38:091e511ce8a0 400 //
mjr 38:091e511ce8a0 401 // Forward declarations
mjr 38:091e511ce8a0 402 //
mjr 38:091e511ce8a0 403 void setNightMode(bool on);
mjr 38:091e511ce8a0 404 void toggleNightMode();
mjr 38:091e511ce8a0 405
mjr 38:091e511ce8a0 406 // ---------------------------------------------------------------------------
mjr 17:ab3cec0c8bf4 407 // utilities
mjr 17:ab3cec0c8bf4 408
mjr 26:cb71c4af2912 409 // floating point square of a number
mjr 26:cb71c4af2912 410 inline float square(float x) { return x*x; }
mjr 26:cb71c4af2912 411
mjr 26:cb71c4af2912 412 // floating point rounding
mjr 26:cb71c4af2912 413 inline float round(float x) { return x > 0 ? floor(x + 0.5) : ceil(x - 0.5); }
mjr 26:cb71c4af2912 414
mjr 17:ab3cec0c8bf4 415
mjr 33:d832bcab089e 416 // --------------------------------------------------------------------------
mjr 33:d832bcab089e 417 //
mjr 40:cc0d9814522b 418 // Extended verison of Timer class. This adds the ability to interrogate
mjr 40:cc0d9814522b 419 // the running state.
mjr 40:cc0d9814522b 420 //
mjr 40:cc0d9814522b 421 class Timer2: public Timer
mjr 40:cc0d9814522b 422 {
mjr 40:cc0d9814522b 423 public:
mjr 40:cc0d9814522b 424 Timer2() : running(false) { }
mjr 40:cc0d9814522b 425
mjr 40:cc0d9814522b 426 void start() { running = true; Timer::start(); }
mjr 40:cc0d9814522b 427 void stop() { running = false; Timer::stop(); }
mjr 40:cc0d9814522b 428
mjr 40:cc0d9814522b 429 bool isRunning() const { return running; }
mjr 40:cc0d9814522b 430
mjr 40:cc0d9814522b 431 private:
mjr 40:cc0d9814522b 432 bool running;
mjr 40:cc0d9814522b 433 };
mjr 40:cc0d9814522b 434
mjr 53:9b2611964afc 435
mjr 53:9b2611964afc 436 // --------------------------------------------------------------------------
mjr 53:9b2611964afc 437 //
mjr 53:9b2611964afc 438 // Reboot timer. When we have a deferred reboot operation pending, we
mjr 53:9b2611964afc 439 // set the target time and start the timer.
mjr 53:9b2611964afc 440 Timer2 rebootTimer;
mjr 53:9b2611964afc 441 long rebootTime_us;
mjr 53:9b2611964afc 442
mjr 40:cc0d9814522b 443 // --------------------------------------------------------------------------
mjr 40:cc0d9814522b 444 //
mjr 33:d832bcab089e 445 // USB product version number
mjr 5:a70c0bce770d 446 //
mjr 47:df7a88cd249c 447 const uint16_t USB_VERSION_NO = 0x000A;
mjr 33:d832bcab089e 448
mjr 33:d832bcab089e 449 // --------------------------------------------------------------------------
mjr 33:d832bcab089e 450 //
mjr 6:cc35eb643e8f 451 // Joystick axis report range - we report from -JOYMAX to +JOYMAX
mjr 33:d832bcab089e 452 //
mjr 6:cc35eb643e8f 453 #define JOYMAX 4096
mjr 6:cc35eb643e8f 454
mjr 9:fd65b0a94720 455
mjr 17:ab3cec0c8bf4 456 // ---------------------------------------------------------------------------
mjr 17:ab3cec0c8bf4 457 //
mjr 40:cc0d9814522b 458 // Wire protocol value translations. These translate byte values to and
mjr 40:cc0d9814522b 459 // from the USB protocol to local native format.
mjr 35:e959ffba78fd 460 //
mjr 35:e959ffba78fd 461
mjr 35:e959ffba78fd 462 // unsigned 16-bit integer
mjr 35:e959ffba78fd 463 inline uint16_t wireUI16(const uint8_t *b)
mjr 35:e959ffba78fd 464 {
mjr 35:e959ffba78fd 465 return b[0] | ((uint16_t)b[1] << 8);
mjr 35:e959ffba78fd 466 }
mjr 40:cc0d9814522b 467 inline void ui16Wire(uint8_t *b, uint16_t val)
mjr 40:cc0d9814522b 468 {
mjr 40:cc0d9814522b 469 b[0] = (uint8_t)(val & 0xff);
mjr 40:cc0d9814522b 470 b[1] = (uint8_t)((val >> 8) & 0xff);
mjr 40:cc0d9814522b 471 }
mjr 35:e959ffba78fd 472
mjr 35:e959ffba78fd 473 inline int16_t wireI16(const uint8_t *b)
mjr 35:e959ffba78fd 474 {
mjr 35:e959ffba78fd 475 return (int16_t)wireUI16(b);
mjr 35:e959ffba78fd 476 }
mjr 40:cc0d9814522b 477 inline void i16Wire(uint8_t *b, int16_t val)
mjr 40:cc0d9814522b 478 {
mjr 40:cc0d9814522b 479 ui16Wire(b, (uint16_t)val);
mjr 40:cc0d9814522b 480 }
mjr 35:e959ffba78fd 481
mjr 35:e959ffba78fd 482 inline uint32_t wireUI32(const uint8_t *b)
mjr 35:e959ffba78fd 483 {
mjr 35:e959ffba78fd 484 return b[0] | ((uint32_t)b[1] << 8) | ((uint32_t)b[2] << 16) | ((uint32_t)b[3] << 24);
mjr 35:e959ffba78fd 485 }
mjr 40:cc0d9814522b 486 inline void ui32Wire(uint8_t *b, uint32_t val)
mjr 40:cc0d9814522b 487 {
mjr 40:cc0d9814522b 488 b[0] = (uint8_t)(val & 0xff);
mjr 40:cc0d9814522b 489 b[1] = (uint8_t)((val >> 8) & 0xff);
mjr 40:cc0d9814522b 490 b[2] = (uint8_t)((val >> 16) & 0xff);
mjr 40:cc0d9814522b 491 b[3] = (uint8_t)((val >> 24) & 0xff);
mjr 40:cc0d9814522b 492 }
mjr 35:e959ffba78fd 493
mjr 35:e959ffba78fd 494 inline int32_t wireI32(const uint8_t *b)
mjr 35:e959ffba78fd 495 {
mjr 35:e959ffba78fd 496 return (int32_t)wireUI32(b);
mjr 35:e959ffba78fd 497 }
mjr 35:e959ffba78fd 498
mjr 53:9b2611964afc 499 // Convert "wire" (USB) pin codes to/from PinName values.
mjr 53:9b2611964afc 500 //
mjr 53:9b2611964afc 501 // The internal mbed PinName format is
mjr 53:9b2611964afc 502 //
mjr 53:9b2611964afc 503 // ((port) << PORT_SHIFT) | (pin << 2) // MBED FORMAT
mjr 53:9b2611964afc 504 //
mjr 53:9b2611964afc 505 // where 'port' is 0-4 for Port A to Port E, and 'pin' is
mjr 53:9b2611964afc 506 // 0 to 31. E.g., E31 is (4 << PORT_SHIFT) | (31<<2).
mjr 53:9b2611964afc 507 //
mjr 53:9b2611964afc 508 // We remap this to our more compact wire format where each
mjr 53:9b2611964afc 509 // pin name fits in 8 bits:
mjr 53:9b2611964afc 510 //
mjr 53:9b2611964afc 511 // ((port) << 5) | pin) // WIRE FORMAT
mjr 53:9b2611964afc 512 //
mjr 53:9b2611964afc 513 // E.g., E31 is (4 << 5) | 31.
mjr 53:9b2611964afc 514 //
mjr 53:9b2611964afc 515 // Wire code FF corresponds to PinName NC (not connected).
mjr 53:9b2611964afc 516 //
mjr 53:9b2611964afc 517 inline PinName wirePinName(uint8_t c)
mjr 35:e959ffba78fd 518 {
mjr 53:9b2611964afc 519 if (c == 0xFF)
mjr 53:9b2611964afc 520 return NC; // 0xFF -> NC
mjr 53:9b2611964afc 521 else
mjr 53:9b2611964afc 522 return PinName(
mjr 53:9b2611964afc 523 (int(c & 0xE0) << (PORT_SHIFT - 5)) // top three bits are the port
mjr 53:9b2611964afc 524 | (int(c & 0x1F) << 2)); // bottom five bits are pin
mjr 40:cc0d9814522b 525 }
mjr 40:cc0d9814522b 526 inline void pinNameWire(uint8_t *b, PinName n)
mjr 40:cc0d9814522b 527 {
mjr 53:9b2611964afc 528 *b = PINNAME_TO_WIRE(n);
mjr 35:e959ffba78fd 529 }
mjr 35:e959ffba78fd 530
mjr 35:e959ffba78fd 531
mjr 35:e959ffba78fd 532 // ---------------------------------------------------------------------------
mjr 35:e959ffba78fd 533 //
mjr 38:091e511ce8a0 534 // On-board RGB LED elements - we use these for diagnostic displays.
mjr 38:091e511ce8a0 535 //
mjr 38:091e511ce8a0 536 // Note that LED3 (the blue segment) is hard-wired on the KL25Z to PTD1,
mjr 38:091e511ce8a0 537 // so PTD1 shouldn't be used for any other purpose (e.g., as a keyboard
mjr 38:091e511ce8a0 538 // input or a device output). This is kind of unfortunate in that it's
mjr 38:091e511ce8a0 539 // one of only two ports exposed on the jumper pins that can be muxed to
mjr 38:091e511ce8a0 540 // SPI0 SCLK. This effectively limits us to PTC5 if we want to use the
mjr 38:091e511ce8a0 541 // SPI capability.
mjr 38:091e511ce8a0 542 //
mjr 38:091e511ce8a0 543 DigitalOut *ledR, *ledG, *ledB;
mjr 38:091e511ce8a0 544
mjr 38:091e511ce8a0 545 // Show the indicated pattern on the diagnostic LEDs. 0 is off, 1 is
mjr 38:091e511ce8a0 546 // on, and -1 is no change (leaves the current setting intact).
mjr 38:091e511ce8a0 547 void diagLED(int r, int g, int b)
mjr 38:091e511ce8a0 548 {
mjr 38:091e511ce8a0 549 if (ledR != 0 && r != -1) ledR->write(!r);
mjr 38:091e511ce8a0 550 if (ledG != 0 && g != -1) ledG->write(!g);
mjr 38:091e511ce8a0 551 if (ledB != 0 && b != -1) ledB->write(!b);
mjr 38:091e511ce8a0 552 }
mjr 38:091e511ce8a0 553
mjr 38:091e511ce8a0 554 // check an output port assignment to see if it conflicts with
mjr 38:091e511ce8a0 555 // an on-board LED segment
mjr 38:091e511ce8a0 556 struct LedSeg
mjr 38:091e511ce8a0 557 {
mjr 38:091e511ce8a0 558 bool r, g, b;
mjr 38:091e511ce8a0 559 LedSeg() { r = g = b = false; }
mjr 38:091e511ce8a0 560
mjr 38:091e511ce8a0 561 void check(LedWizPortCfg &pc)
mjr 38:091e511ce8a0 562 {
mjr 38:091e511ce8a0 563 // if it's a GPIO, check to see if it's assigned to one of
mjr 38:091e511ce8a0 564 // our on-board LED segments
mjr 38:091e511ce8a0 565 int t = pc.typ;
mjr 38:091e511ce8a0 566 if (t == PortTypeGPIOPWM || t == PortTypeGPIODig)
mjr 38:091e511ce8a0 567 {
mjr 38:091e511ce8a0 568 // it's a GPIO port - check for a matching pin assignment
mjr 38:091e511ce8a0 569 PinName pin = wirePinName(pc.pin);
mjr 38:091e511ce8a0 570 if (pin == LED1)
mjr 38:091e511ce8a0 571 r = true;
mjr 38:091e511ce8a0 572 else if (pin == LED2)
mjr 38:091e511ce8a0 573 g = true;
mjr 38:091e511ce8a0 574 else if (pin == LED3)
mjr 38:091e511ce8a0 575 b = true;
mjr 38:091e511ce8a0 576 }
mjr 38:091e511ce8a0 577 }
mjr 38:091e511ce8a0 578 };
mjr 38:091e511ce8a0 579
mjr 38:091e511ce8a0 580 // Initialize the diagnostic LEDs. By default, we use the on-board
mjr 38:091e511ce8a0 581 // RGB LED to display the microcontroller status. However, we allow
mjr 38:091e511ce8a0 582 // the user to commandeer the on-board LED as an LedWiz output device,
mjr 38:091e511ce8a0 583 // which can be useful for testing a new installation. So we'll check
mjr 38:091e511ce8a0 584 // for LedWiz outputs assigned to the on-board LED segments, and turn
mjr 38:091e511ce8a0 585 // off the diagnostic use for any so assigned.
mjr 38:091e511ce8a0 586 void initDiagLEDs(Config &cfg)
mjr 38:091e511ce8a0 587 {
mjr 38:091e511ce8a0 588 // run through the configuration list and cross off any of the
mjr 38:091e511ce8a0 589 // LED segments assigned to LedWiz ports
mjr 38:091e511ce8a0 590 LedSeg l;
mjr 38:091e511ce8a0 591 for (int i = 0 ; i < MAX_OUT_PORTS && cfg.outPort[i].typ != PortTypeDisabled ; ++i)
mjr 38:091e511ce8a0 592 l.check(cfg.outPort[i]);
mjr 38:091e511ce8a0 593
mjr 38:091e511ce8a0 594 // We now know which segments are taken for LedWiz use and which
mjr 38:091e511ce8a0 595 // are free. Create diagnostic ports for the ones not claimed for
mjr 38:091e511ce8a0 596 // LedWiz use.
mjr 38:091e511ce8a0 597 if (!l.r) ledR = new DigitalOut(LED1, 1);
mjr 38:091e511ce8a0 598 if (!l.g) ledG = new DigitalOut(LED2, 1);
mjr 38:091e511ce8a0 599 if (!l.b) ledB = new DigitalOut(LED3, 1);
mjr 38:091e511ce8a0 600 }
mjr 38:091e511ce8a0 601
mjr 38:091e511ce8a0 602
mjr 38:091e511ce8a0 603 // ---------------------------------------------------------------------------
mjr 38:091e511ce8a0 604 //
mjr 29:582472d0bc57 605 // LedWiz emulation, and enhanced TLC5940 output controller
mjr 5:a70c0bce770d 606 //
mjr 26:cb71c4af2912 607 // There are two modes for this feature. The default mode uses the on-board
mjr 26:cb71c4af2912 608 // GPIO ports to implement device outputs - each LedWiz software port is
mjr 26:cb71c4af2912 609 // connected to a physical GPIO pin on the KL25Z. The KL25Z only has 10
mjr 26:cb71c4af2912 610 // PWM channels, so in this mode only 10 LedWiz ports will be dimmable; the
mjr 26:cb71c4af2912 611 // rest are strictly on/off. The KL25Z also has a limited number of GPIO
mjr 26:cb71c4af2912 612 // ports overall - not enough for the full complement of 32 LedWiz ports
mjr 26:cb71c4af2912 613 // and 24 VP joystick inputs, so it's necessary to trade one against the
mjr 26:cb71c4af2912 614 // other if both features are to be used.
mjr 26:cb71c4af2912 615 //
mjr 26:cb71c4af2912 616 // The alternative, enhanced mode uses external TLC5940 PWM controller
mjr 26:cb71c4af2912 617 // chips to control device outputs. In this mode, each LedWiz software
mjr 26:cb71c4af2912 618 // port is mapped to an output on one of the external TLC5940 chips.
mjr 26:cb71c4af2912 619 // Two 5940s is enough for the full set of 32 LedWiz ports, and we can
mjr 26:cb71c4af2912 620 // support even more chips for even more outputs (although doing so requires
mjr 26:cb71c4af2912 621 // breaking LedWiz compatibility, since the LedWiz USB protocol is hardwired
mjr 26:cb71c4af2912 622 // for 32 outputs). Every port in this mode has full PWM support.
mjr 26:cb71c4af2912 623 //
mjr 5:a70c0bce770d 624
mjr 29:582472d0bc57 625
mjr 26:cb71c4af2912 626 // Current starting output index for "PBA" messages from the PC (using
mjr 26:cb71c4af2912 627 // the LedWiz USB protocol). Each PBA message implicitly uses the
mjr 26:cb71c4af2912 628 // current index as the starting point for the ports referenced in
mjr 26:cb71c4af2912 629 // the message, and increases it (by 8) for the next call.
mjr 0:5acbbe3f4cf4 630 static int pbaIdx = 0;
mjr 0:5acbbe3f4cf4 631
mjr 26:cb71c4af2912 632 // Generic LedWiz output port interface. We create a cover class to
mjr 26:cb71c4af2912 633 // virtualize digital vs PWM outputs, and on-board KL25Z GPIO vs external
mjr 26:cb71c4af2912 634 // TLC5940 outputs, and give them all a common interface.
mjr 6:cc35eb643e8f 635 class LwOut
mjr 6:cc35eb643e8f 636 {
mjr 6:cc35eb643e8f 637 public:
mjr 40:cc0d9814522b 638 // Set the output intensity. 'val' is 0 for fully off, 255 for
mjr 40:cc0d9814522b 639 // fully on, with values in between signifying lower intensity.
mjr 40:cc0d9814522b 640 virtual void set(uint8_t val) = 0;
mjr 6:cc35eb643e8f 641 };
mjr 26:cb71c4af2912 642
mjr 35:e959ffba78fd 643 // LwOut class for virtual ports. This type of port is visible to
mjr 35:e959ffba78fd 644 // the host software, but isn't connected to any physical output.
mjr 35:e959ffba78fd 645 // This can be used for special software-only ports like the ZB
mjr 35:e959ffba78fd 646 // Launch Ball output, or simply for placeholders in the LedWiz port
mjr 35:e959ffba78fd 647 // numbering.
mjr 35:e959ffba78fd 648 class LwVirtualOut: public LwOut
mjr 33:d832bcab089e 649 {
mjr 33:d832bcab089e 650 public:
mjr 35:e959ffba78fd 651 LwVirtualOut() { }
mjr 40:cc0d9814522b 652 virtual void set(uint8_t ) { }
mjr 33:d832bcab089e 653 };
mjr 26:cb71c4af2912 654
mjr 34:6b981a2afab7 655 // Active Low out. For any output marked as active low, we layer this
mjr 34:6b981a2afab7 656 // on top of the physical pin interface. This simply inverts the value of
mjr 40:cc0d9814522b 657 // the output value, so that 255 means fully off and 0 means fully on.
mjr 34:6b981a2afab7 658 class LwInvertedOut: public LwOut
mjr 34:6b981a2afab7 659 {
mjr 34:6b981a2afab7 660 public:
mjr 34:6b981a2afab7 661 LwInvertedOut(LwOut *o) : out(o) { }
mjr 40:cc0d9814522b 662 virtual void set(uint8_t val) { out->set(255 - val); }
mjr 34:6b981a2afab7 663
mjr 34:6b981a2afab7 664 private:
mjr 53:9b2611964afc 665 // underlying physical output
mjr 34:6b981a2afab7 666 LwOut *out;
mjr 34:6b981a2afab7 667 };
mjr 34:6b981a2afab7 668
mjr 53:9b2611964afc 669 // Global ZB Launch Ball state
mjr 53:9b2611964afc 670 bool zbLaunchOn = false;
mjr 53:9b2611964afc 671
mjr 53:9b2611964afc 672 // ZB Launch Ball output. This is layered on a port (physical or virtual)
mjr 53:9b2611964afc 673 // to track the ZB Launch Ball signal.
mjr 53:9b2611964afc 674 class LwZbLaunchOut: public LwOut
mjr 53:9b2611964afc 675 {
mjr 53:9b2611964afc 676 public:
mjr 53:9b2611964afc 677 LwZbLaunchOut(LwOut *o) : out(o) { }
mjr 53:9b2611964afc 678 virtual void set(uint8_t val)
mjr 53:9b2611964afc 679 {
mjr 53:9b2611964afc 680 // update the global ZB Launch Ball state
mjr 53:9b2611964afc 681 zbLaunchOn = (val != 0);
mjr 53:9b2611964afc 682
mjr 53:9b2611964afc 683 // pass it along to the underlying port, in case it's a physical output
mjr 53:9b2611964afc 684 out->set(val);
mjr 53:9b2611964afc 685 }
mjr 53:9b2611964afc 686
mjr 53:9b2611964afc 687 private:
mjr 53:9b2611964afc 688 // underlying physical or virtual output
mjr 53:9b2611964afc 689 LwOut *out;
mjr 53:9b2611964afc 690 };
mjr 53:9b2611964afc 691
mjr 53:9b2611964afc 692
mjr 40:cc0d9814522b 693 // Gamma correction table for 8-bit input values
mjr 40:cc0d9814522b 694 static const uint8_t gamma[] = {
mjr 40:cc0d9814522b 695 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
mjr 40:cc0d9814522b 696 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1,
mjr 40:cc0d9814522b 697 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2,
mjr 40:cc0d9814522b 698 2, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 5, 5, 5,
mjr 40:cc0d9814522b 699 5, 6, 6, 6, 6, 7, 7, 7, 7, 8, 8, 8, 9, 9, 9, 10,
mjr 40:cc0d9814522b 700 10, 10, 11, 11, 11, 12, 12, 13, 13, 13, 14, 14, 15, 15, 16, 16,
mjr 40:cc0d9814522b 701 17, 17, 18, 18, 19, 19, 20, 20, 21, 21, 22, 22, 23, 24, 24, 25,
mjr 40:cc0d9814522b 702 25, 26, 27, 27, 28, 29, 29, 30, 31, 32, 32, 33, 34, 35, 35, 36,
mjr 40:cc0d9814522b 703 37, 38, 39, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 50,
mjr 40:cc0d9814522b 704 51, 52, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 66, 67, 68,
mjr 40:cc0d9814522b 705 69, 70, 72, 73, 74, 75, 77, 78, 79, 81, 82, 83, 85, 86, 87, 89,
mjr 40:cc0d9814522b 706 90, 92, 93, 95, 96, 98, 99, 101, 102, 104, 105, 107, 109, 110, 112, 114,
mjr 40:cc0d9814522b 707 115, 117, 119, 120, 122, 124, 126, 127, 129, 131, 133, 135, 137, 138, 140, 142,
mjr 40:cc0d9814522b 708 144, 146, 148, 150, 152, 154, 156, 158, 160, 162, 164, 167, 169, 171, 173, 175,
mjr 40:cc0d9814522b 709 177, 180, 182, 184, 186, 189, 191, 193, 196, 198, 200, 203, 205, 208, 210, 213,
mjr 40:cc0d9814522b 710 215, 218, 220, 223, 225, 228, 231, 233, 236, 239, 241, 244, 247, 249, 252, 255
mjr 40:cc0d9814522b 711 };
mjr 40:cc0d9814522b 712
mjr 40:cc0d9814522b 713 // Gamma-corrected out. This is a filter object that we layer on top
mjr 40:cc0d9814522b 714 // of a physical pin interface. This applies gamma correction to the
mjr 40:cc0d9814522b 715 // input value and then passes it along to the underlying pin object.
mjr 40:cc0d9814522b 716 class LwGammaOut: public LwOut
mjr 40:cc0d9814522b 717 {
mjr 40:cc0d9814522b 718 public:
mjr 40:cc0d9814522b 719 LwGammaOut(LwOut *o) : out(o) { }
mjr 40:cc0d9814522b 720 virtual void set(uint8_t val) { out->set(gamma[val]); }
mjr 40:cc0d9814522b 721
mjr 40:cc0d9814522b 722 private:
mjr 40:cc0d9814522b 723 LwOut *out;
mjr 40:cc0d9814522b 724 };
mjr 40:cc0d9814522b 725
mjr 53:9b2611964afc 726 // global night mode flag
mjr 53:9b2611964afc 727 static bool nightMode = false;
mjr 53:9b2611964afc 728
mjr 40:cc0d9814522b 729 // Noisy output. This is a filter object that we layer on top of
mjr 40:cc0d9814522b 730 // a physical pin output. This filter disables the port when night
mjr 40:cc0d9814522b 731 // mode is engaged.
mjr 40:cc0d9814522b 732 class LwNoisyOut: public LwOut
mjr 40:cc0d9814522b 733 {
mjr 40:cc0d9814522b 734 public:
mjr 40:cc0d9814522b 735 LwNoisyOut(LwOut *o) : out(o) { }
mjr 40:cc0d9814522b 736 virtual void set(uint8_t val) { out->set(nightMode ? 0 : val); }
mjr 40:cc0d9814522b 737
mjr 53:9b2611964afc 738 private:
mjr 53:9b2611964afc 739 LwOut *out;
mjr 53:9b2611964afc 740 };
mjr 53:9b2611964afc 741
mjr 53:9b2611964afc 742 // Night Mode indicator output. This is a filter object that we
mjr 53:9b2611964afc 743 // layer on top of a physical pin output. This filter ignores the
mjr 53:9b2611964afc 744 // host value and simply shows the night mode status.
mjr 53:9b2611964afc 745 class LwNightModeIndicatorOut: public LwOut
mjr 53:9b2611964afc 746 {
mjr 53:9b2611964afc 747 public:
mjr 53:9b2611964afc 748 LwNightModeIndicatorOut(LwOut *o) : out(o) { }
mjr 53:9b2611964afc 749 virtual void set(uint8_t)
mjr 53:9b2611964afc 750 {
mjr 53:9b2611964afc 751 // ignore the host value and simply show the current
mjr 53:9b2611964afc 752 // night mode setting
mjr 53:9b2611964afc 753 out->set(nightMode ? 255 : 0);
mjr 53:9b2611964afc 754 }
mjr 40:cc0d9814522b 755
mjr 40:cc0d9814522b 756 private:
mjr 40:cc0d9814522b 757 LwOut *out;
mjr 40:cc0d9814522b 758 };
mjr 40:cc0d9814522b 759
mjr 26:cb71c4af2912 760
mjr 35:e959ffba78fd 761 //
mjr 35:e959ffba78fd 762 // The TLC5940 interface object. We'll set this up with the port
mjr 35:e959ffba78fd 763 // assignments set in config.h.
mjr 33:d832bcab089e 764 //
mjr 35:e959ffba78fd 765 TLC5940 *tlc5940 = 0;
mjr 35:e959ffba78fd 766 void init_tlc5940(Config &cfg)
mjr 35:e959ffba78fd 767 {
mjr 35:e959ffba78fd 768 if (cfg.tlc5940.nchips != 0)
mjr 35:e959ffba78fd 769 {
mjr 53:9b2611964afc 770 tlc5940 = new TLC5940(
mjr 53:9b2611964afc 771 wirePinName(cfg.tlc5940.sclk),
mjr 53:9b2611964afc 772 wirePinName(cfg.tlc5940.sin),
mjr 53:9b2611964afc 773 wirePinName(cfg.tlc5940.gsclk),
mjr 53:9b2611964afc 774 wirePinName(cfg.tlc5940.blank),
mjr 53:9b2611964afc 775 wirePinName(cfg.tlc5940.xlat),
mjr 53:9b2611964afc 776 cfg.tlc5940.nchips);
mjr 35:e959ffba78fd 777 }
mjr 35:e959ffba78fd 778 }
mjr 26:cb71c4af2912 779
mjr 40:cc0d9814522b 780 // Conversion table for 8-bit DOF level to 12-bit TLC5940 level
mjr 40:cc0d9814522b 781 static const uint16_t dof_to_tlc[] = {
mjr 40:cc0d9814522b 782 0, 16, 32, 48, 64, 80, 96, 112, 128, 145, 161, 177, 193, 209, 225, 241,
mjr 40:cc0d9814522b 783 257, 273, 289, 305, 321, 337, 353, 369, 385, 401, 418, 434, 450, 466, 482, 498,
mjr 40:cc0d9814522b 784 514, 530, 546, 562, 578, 594, 610, 626, 642, 658, 674, 691, 707, 723, 739, 755,
mjr 40:cc0d9814522b 785 771, 787, 803, 819, 835, 851, 867, 883, 899, 915, 931, 947, 964, 980, 996, 1012,
mjr 40:cc0d9814522b 786 1028, 1044, 1060, 1076, 1092, 1108, 1124, 1140, 1156, 1172, 1188, 1204, 1220, 1237, 1253, 1269,
mjr 40:cc0d9814522b 787 1285, 1301, 1317, 1333, 1349, 1365, 1381, 1397, 1413, 1429, 1445, 1461, 1477, 1493, 1510, 1526,
mjr 40:cc0d9814522b 788 1542, 1558, 1574, 1590, 1606, 1622, 1638, 1654, 1670, 1686, 1702, 1718, 1734, 1750, 1766, 1783,
mjr 40:cc0d9814522b 789 1799, 1815, 1831, 1847, 1863, 1879, 1895, 1911, 1927, 1943, 1959, 1975, 1991, 2007, 2023, 2039,
mjr 40:cc0d9814522b 790 2056, 2072, 2088, 2104, 2120, 2136, 2152, 2168, 2184, 2200, 2216, 2232, 2248, 2264, 2280, 2296,
mjr 40:cc0d9814522b 791 2312, 2329, 2345, 2361, 2377, 2393, 2409, 2425, 2441, 2457, 2473, 2489, 2505, 2521, 2537, 2553,
mjr 40:cc0d9814522b 792 2569, 2585, 2602, 2618, 2634, 2650, 2666, 2682, 2698, 2714, 2730, 2746, 2762, 2778, 2794, 2810,
mjr 40:cc0d9814522b 793 2826, 2842, 2858, 2875, 2891, 2907, 2923, 2939, 2955, 2971, 2987, 3003, 3019, 3035, 3051, 3067,
mjr 40:cc0d9814522b 794 3083, 3099, 3115, 3131, 3148, 3164, 3180, 3196, 3212, 3228, 3244, 3260, 3276, 3292, 3308, 3324,
mjr 40:cc0d9814522b 795 3340, 3356, 3372, 3388, 3404, 3421, 3437, 3453, 3469, 3485, 3501, 3517, 3533, 3549, 3565, 3581,
mjr 40:cc0d9814522b 796 3597, 3613, 3629, 3645, 3661, 3677, 3694, 3710, 3726, 3742, 3758, 3774, 3790, 3806, 3822, 3838,
mjr 40:cc0d9814522b 797 3854, 3870, 3886, 3902, 3918, 3934, 3950, 3967, 3983, 3999, 4015, 4031, 4047, 4063, 4079, 4095
mjr 40:cc0d9814522b 798 };
mjr 40:cc0d9814522b 799
mjr 40:cc0d9814522b 800 // Conversion table for 8-bit DOF level to 12-bit TLC5940 level, with
mjr 40:cc0d9814522b 801 // gamma correction. Note that the output layering scheme can handle
mjr 40:cc0d9814522b 802 // this without a separate table, by first applying gamma to the DOF
mjr 40:cc0d9814522b 803 // level to produce an 8-bit gamma-corrected value, then convert that
mjr 40:cc0d9814522b 804 // to the 12-bit TLC5940 value. But we get better precision by doing
mjr 40:cc0d9814522b 805 // the gamma correction in the 12-bit TLC5940 domain. We can only
mjr 40:cc0d9814522b 806 // get the 12-bit domain by combining both steps into one layering
mjr 40:cc0d9814522b 807 // object, though, since the intermediate values in the layering system
mjr 40:cc0d9814522b 808 // are always 8 bits.
mjr 40:cc0d9814522b 809 static const uint16_t dof_to_gamma_tlc[] = {
mjr 40:cc0d9814522b 810 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1,
mjr 40:cc0d9814522b 811 2, 2, 2, 3, 3, 4, 4, 5, 5, 6, 7, 8, 8, 9, 10, 11,
mjr 40:cc0d9814522b 812 12, 13, 15, 16, 17, 18, 20, 21, 23, 25, 26, 28, 30, 32, 34, 36,
mjr 40:cc0d9814522b 813 38, 40, 43, 45, 48, 50, 53, 56, 59, 62, 65, 68, 71, 75, 78, 82,
mjr 40:cc0d9814522b 814 85, 89, 93, 97, 101, 105, 110, 114, 119, 123, 128, 133, 138, 143, 149, 154,
mjr 40:cc0d9814522b 815 159, 165, 171, 177, 183, 189, 195, 202, 208, 215, 222, 229, 236, 243, 250, 258,
mjr 40:cc0d9814522b 816 266, 273, 281, 290, 298, 306, 315, 324, 332, 341, 351, 360, 369, 379, 389, 399,
mjr 40:cc0d9814522b 817 409, 419, 430, 440, 451, 462, 473, 485, 496, 508, 520, 532, 544, 556, 569, 582,
mjr 40:cc0d9814522b 818 594, 608, 621, 634, 648, 662, 676, 690, 704, 719, 734, 749, 764, 779, 795, 811,
mjr 40:cc0d9814522b 819 827, 843, 859, 876, 893, 910, 927, 944, 962, 980, 998, 1016, 1034, 1053, 1072, 1091,
mjr 40:cc0d9814522b 820 1110, 1130, 1150, 1170, 1190, 1210, 1231, 1252, 1273, 1294, 1316, 1338, 1360, 1382, 1404, 1427,
mjr 40:cc0d9814522b 821 1450, 1473, 1497, 1520, 1544, 1568, 1593, 1617, 1642, 1667, 1693, 1718, 1744, 1770, 1797, 1823,
mjr 40:cc0d9814522b 822 1850, 1877, 1905, 1932, 1960, 1988, 2017, 2045, 2074, 2103, 2133, 2162, 2192, 2223, 2253, 2284,
mjr 40:cc0d9814522b 823 2315, 2346, 2378, 2410, 2442, 2474, 2507, 2540, 2573, 2606, 2640, 2674, 2708, 2743, 2778, 2813,
mjr 40:cc0d9814522b 824 2849, 2884, 2920, 2957, 2993, 3030, 3067, 3105, 3143, 3181, 3219, 3258, 3297, 3336, 3376, 3416,
mjr 40:cc0d9814522b 825 3456, 3496, 3537, 3578, 3619, 3661, 3703, 3745, 3788, 3831, 3874, 3918, 3962, 4006, 4050, 4095
mjr 40:cc0d9814522b 826 };
mjr 40:cc0d9814522b 827
mjr 26:cb71c4af2912 828 // LwOut class for TLC5940 outputs. These are fully PWM capable.
mjr 26:cb71c4af2912 829 // The 'idx' value in the constructor is the output index in the
mjr 26:cb71c4af2912 830 // daisy-chained TLC5940 array. 0 is output #0 on the first chip,
mjr 26:cb71c4af2912 831 // 1 is #1 on the first chip, 15 is #15 on the first chip, 16 is
mjr 26:cb71c4af2912 832 // #0 on the second chip, 32 is #0 on the third chip, etc.
mjr 26:cb71c4af2912 833 class Lw5940Out: public LwOut
mjr 26:cb71c4af2912 834 {
mjr 26:cb71c4af2912 835 public:
mjr 60:f38da020aa13 836 Lw5940Out(uint8_t idx) : idx(idx) { prv = 0; }
mjr 40:cc0d9814522b 837 virtual void set(uint8_t val)
mjr 26:cb71c4af2912 838 {
mjr 26:cb71c4af2912 839 if (val != prv)
mjr 40:cc0d9814522b 840 tlc5940->set(idx, dof_to_tlc[prv = val]);
mjr 26:cb71c4af2912 841 }
mjr 60:f38da020aa13 842 uint8_t idx;
mjr 40:cc0d9814522b 843 uint8_t prv;
mjr 26:cb71c4af2912 844 };
mjr 26:cb71c4af2912 845
mjr 40:cc0d9814522b 846 // LwOut class for TLC5940 gamma-corrected outputs.
mjr 40:cc0d9814522b 847 class Lw5940GammaOut: public LwOut
mjr 40:cc0d9814522b 848 {
mjr 40:cc0d9814522b 849 public:
mjr 60:f38da020aa13 850 Lw5940GammaOut(uint8_t idx) : idx(idx) { prv = 0; }
mjr 40:cc0d9814522b 851 virtual void set(uint8_t val)
mjr 40:cc0d9814522b 852 {
mjr 40:cc0d9814522b 853 if (val != prv)
mjr 40:cc0d9814522b 854 tlc5940->set(idx, dof_to_gamma_tlc[prv = val]);
mjr 40:cc0d9814522b 855 }
mjr 60:f38da020aa13 856 uint8_t idx;
mjr 40:cc0d9814522b 857 uint8_t prv;
mjr 40:cc0d9814522b 858 };
mjr 40:cc0d9814522b 859
mjr 40:cc0d9814522b 860
mjr 33:d832bcab089e 861
mjr 34:6b981a2afab7 862 // 74HC595 interface object. Set this up with the port assignments in
mjr 34:6b981a2afab7 863 // config.h.
mjr 35:e959ffba78fd 864 HC595 *hc595 = 0;
mjr 35:e959ffba78fd 865
mjr 35:e959ffba78fd 866 // initialize the 74HC595 interface
mjr 35:e959ffba78fd 867 void init_hc595(Config &cfg)
mjr 35:e959ffba78fd 868 {
mjr 35:e959ffba78fd 869 if (cfg.hc595.nchips != 0)
mjr 35:e959ffba78fd 870 {
mjr 53:9b2611964afc 871 hc595 = new HC595(
mjr 53:9b2611964afc 872 wirePinName(cfg.hc595.nchips),
mjr 53:9b2611964afc 873 wirePinName(cfg.hc595.sin),
mjr 53:9b2611964afc 874 wirePinName(cfg.hc595.sclk),
mjr 53:9b2611964afc 875 wirePinName(cfg.hc595.latch),
mjr 53:9b2611964afc 876 wirePinName(cfg.hc595.ena));
mjr 35:e959ffba78fd 877 hc595->init();
mjr 35:e959ffba78fd 878 hc595->update();
mjr 35:e959ffba78fd 879 }
mjr 35:e959ffba78fd 880 }
mjr 34:6b981a2afab7 881
mjr 34:6b981a2afab7 882 // LwOut class for 74HC595 outputs. These are simple digial outs.
mjr 34:6b981a2afab7 883 // The 'idx' value in the constructor is the output index in the
mjr 34:6b981a2afab7 884 // daisy-chained 74HC595 array. 0 is output #0 on the first chip,
mjr 34:6b981a2afab7 885 // 1 is #1 on the first chip, 7 is #7 on the first chip, 8 is
mjr 34:6b981a2afab7 886 // #0 on the second chip, etc.
mjr 34:6b981a2afab7 887 class Lw595Out: public LwOut
mjr 33:d832bcab089e 888 {
mjr 33:d832bcab089e 889 public:
mjr 60:f38da020aa13 890 Lw595Out(uint8_t idx) : idx(idx) { prv = 0; }
mjr 40:cc0d9814522b 891 virtual void set(uint8_t val)
mjr 34:6b981a2afab7 892 {
mjr 34:6b981a2afab7 893 if (val != prv)
mjr 40:cc0d9814522b 894 hc595->set(idx, (prv = val) == 0 ? 0 : 1);
mjr 34:6b981a2afab7 895 }
mjr 60:f38da020aa13 896 uint8_t idx;
mjr 40:cc0d9814522b 897 uint8_t prv;
mjr 33:d832bcab089e 898 };
mjr 33:d832bcab089e 899
mjr 26:cb71c4af2912 900
mjr 40:cc0d9814522b 901
mjr 64:ef7ca92dff36 902 // Conversion table - 8-bit DOF output level to PWM duty cycle,
mjr 64:ef7ca92dff36 903 // normalized to 0.0 to 1.0 scale.
mjr 40:cc0d9814522b 904 static const float pwm_level[] = {
mjr 64:ef7ca92dff36 905 0.000000f, 0.003922f, 0.007843f, 0.011765f, 0.015686f, 0.019608f, 0.023529f, 0.027451f,
mjr 64:ef7ca92dff36 906 0.031373f, 0.035294f, 0.039216f, 0.043137f, 0.047059f, 0.050980f, 0.054902f, 0.058824f,
mjr 64:ef7ca92dff36 907 0.062745f, 0.066667f, 0.070588f, 0.074510f, 0.078431f, 0.082353f, 0.086275f, 0.090196f,
mjr 64:ef7ca92dff36 908 0.094118f, 0.098039f, 0.101961f, 0.105882f, 0.109804f, 0.113725f, 0.117647f, 0.121569f,
mjr 64:ef7ca92dff36 909 0.125490f, 0.129412f, 0.133333f, 0.137255f, 0.141176f, 0.145098f, 0.149020f, 0.152941f,
mjr 64:ef7ca92dff36 910 0.156863f, 0.160784f, 0.164706f, 0.168627f, 0.172549f, 0.176471f, 0.180392f, 0.184314f,
mjr 64:ef7ca92dff36 911 0.188235f, 0.192157f, 0.196078f, 0.200000f, 0.203922f, 0.207843f, 0.211765f, 0.215686f,
mjr 64:ef7ca92dff36 912 0.219608f, 0.223529f, 0.227451f, 0.231373f, 0.235294f, 0.239216f, 0.243137f, 0.247059f,
mjr 64:ef7ca92dff36 913 0.250980f, 0.254902f, 0.258824f, 0.262745f, 0.266667f, 0.270588f, 0.274510f, 0.278431f,
mjr 64:ef7ca92dff36 914 0.282353f, 0.286275f, 0.290196f, 0.294118f, 0.298039f, 0.301961f, 0.305882f, 0.309804f,
mjr 64:ef7ca92dff36 915 0.313725f, 0.317647f, 0.321569f, 0.325490f, 0.329412f, 0.333333f, 0.337255f, 0.341176f,
mjr 64:ef7ca92dff36 916 0.345098f, 0.349020f, 0.352941f, 0.356863f, 0.360784f, 0.364706f, 0.368627f, 0.372549f,
mjr 64:ef7ca92dff36 917 0.376471f, 0.380392f, 0.384314f, 0.388235f, 0.392157f, 0.396078f, 0.400000f, 0.403922f,
mjr 64:ef7ca92dff36 918 0.407843f, 0.411765f, 0.415686f, 0.419608f, 0.423529f, 0.427451f, 0.431373f, 0.435294f,
mjr 64:ef7ca92dff36 919 0.439216f, 0.443137f, 0.447059f, 0.450980f, 0.454902f, 0.458824f, 0.462745f, 0.466667f,
mjr 64:ef7ca92dff36 920 0.470588f, 0.474510f, 0.478431f, 0.482353f, 0.486275f, 0.490196f, 0.494118f, 0.498039f,
mjr 64:ef7ca92dff36 921 0.501961f, 0.505882f, 0.509804f, 0.513725f, 0.517647f, 0.521569f, 0.525490f, 0.529412f,
mjr 64:ef7ca92dff36 922 0.533333f, 0.537255f, 0.541176f, 0.545098f, 0.549020f, 0.552941f, 0.556863f, 0.560784f,
mjr 64:ef7ca92dff36 923 0.564706f, 0.568627f, 0.572549f, 0.576471f, 0.580392f, 0.584314f, 0.588235f, 0.592157f,
mjr 64:ef7ca92dff36 924 0.596078f, 0.600000f, 0.603922f, 0.607843f, 0.611765f, 0.615686f, 0.619608f, 0.623529f,
mjr 64:ef7ca92dff36 925 0.627451f, 0.631373f, 0.635294f, 0.639216f, 0.643137f, 0.647059f, 0.650980f, 0.654902f,
mjr 64:ef7ca92dff36 926 0.658824f, 0.662745f, 0.666667f, 0.670588f, 0.674510f, 0.678431f, 0.682353f, 0.686275f,
mjr 64:ef7ca92dff36 927 0.690196f, 0.694118f, 0.698039f, 0.701961f, 0.705882f, 0.709804f, 0.713725f, 0.717647f,
mjr 64:ef7ca92dff36 928 0.721569f, 0.725490f, 0.729412f, 0.733333f, 0.737255f, 0.741176f, 0.745098f, 0.749020f,
mjr 64:ef7ca92dff36 929 0.752941f, 0.756863f, 0.760784f, 0.764706f, 0.768627f, 0.772549f, 0.776471f, 0.780392f,
mjr 64:ef7ca92dff36 930 0.784314f, 0.788235f, 0.792157f, 0.796078f, 0.800000f, 0.803922f, 0.807843f, 0.811765f,
mjr 64:ef7ca92dff36 931 0.815686f, 0.819608f, 0.823529f, 0.827451f, 0.831373f, 0.835294f, 0.839216f, 0.843137f,
mjr 64:ef7ca92dff36 932 0.847059f, 0.850980f, 0.854902f, 0.858824f, 0.862745f, 0.866667f, 0.870588f, 0.874510f,
mjr 64:ef7ca92dff36 933 0.878431f, 0.882353f, 0.886275f, 0.890196f, 0.894118f, 0.898039f, 0.901961f, 0.905882f,
mjr 64:ef7ca92dff36 934 0.909804f, 0.913725f, 0.917647f, 0.921569f, 0.925490f, 0.929412f, 0.933333f, 0.937255f,
mjr 64:ef7ca92dff36 935 0.941176f, 0.945098f, 0.949020f, 0.952941f, 0.956863f, 0.960784f, 0.964706f, 0.968627f,
mjr 64:ef7ca92dff36 936 0.972549f, 0.976471f, 0.980392f, 0.984314f, 0.988235f, 0.992157f, 0.996078f, 1.000000f
mjr 40:cc0d9814522b 937 };
mjr 26:cb71c4af2912 938
mjr 64:ef7ca92dff36 939
mjr 64:ef7ca92dff36 940 // Conversion table for 8-bit DOF level to pulse width in microseconds,
mjr 64:ef7ca92dff36 941 // with gamma correction. We could use the layered gamma output on top
mjr 64:ef7ca92dff36 942 // of the regular LwPwmOut class for this, but we get better precision
mjr 64:ef7ca92dff36 943 // with a dedicated table, because we apply gamma correction to the
mjr 64:ef7ca92dff36 944 // 32-bit microsecond values rather than the 8-bit DOF levels.
mjr 64:ef7ca92dff36 945 static const float dof_to_gamma_pwm[] = {
mjr 64:ef7ca92dff36 946 0.000000f, 0.000000f, 0.000001f, 0.000004f, 0.000009f, 0.000017f, 0.000028f, 0.000042f,
mjr 64:ef7ca92dff36 947 0.000062f, 0.000086f, 0.000115f, 0.000151f, 0.000192f, 0.000240f, 0.000296f, 0.000359f,
mjr 64:ef7ca92dff36 948 0.000430f, 0.000509f, 0.000598f, 0.000695f, 0.000803f, 0.000920f, 0.001048f, 0.001187f,
mjr 64:ef7ca92dff36 949 0.001337f, 0.001499f, 0.001673f, 0.001860f, 0.002059f, 0.002272f, 0.002498f, 0.002738f,
mjr 64:ef7ca92dff36 950 0.002993f, 0.003262f, 0.003547f, 0.003847f, 0.004162f, 0.004494f, 0.004843f, 0.005208f,
mjr 64:ef7ca92dff36 951 0.005591f, 0.005991f, 0.006409f, 0.006845f, 0.007301f, 0.007775f, 0.008268f, 0.008781f,
mjr 64:ef7ca92dff36 952 0.009315f, 0.009868f, 0.010442f, 0.011038f, 0.011655f, 0.012293f, 0.012954f, 0.013637f,
mjr 64:ef7ca92dff36 953 0.014342f, 0.015071f, 0.015823f, 0.016599f, 0.017398f, 0.018223f, 0.019071f, 0.019945f,
mjr 64:ef7ca92dff36 954 0.020844f, 0.021769f, 0.022720f, 0.023697f, 0.024701f, 0.025731f, 0.026789f, 0.027875f,
mjr 64:ef7ca92dff36 955 0.028988f, 0.030129f, 0.031299f, 0.032498f, 0.033726f, 0.034983f, 0.036270f, 0.037587f,
mjr 64:ef7ca92dff36 956 0.038935f, 0.040313f, 0.041722f, 0.043162f, 0.044634f, 0.046138f, 0.047674f, 0.049243f,
mjr 64:ef7ca92dff36 957 0.050844f, 0.052478f, 0.054146f, 0.055847f, 0.057583f, 0.059353f, 0.061157f, 0.062996f,
mjr 64:ef7ca92dff36 958 0.064870f, 0.066780f, 0.068726f, 0.070708f, 0.072726f, 0.074780f, 0.076872f, 0.079001f,
mjr 64:ef7ca92dff36 959 0.081167f, 0.083371f, 0.085614f, 0.087895f, 0.090214f, 0.092572f, 0.094970f, 0.097407f,
mjr 64:ef7ca92dff36 960 0.099884f, 0.102402f, 0.104959f, 0.107558f, 0.110197f, 0.112878f, 0.115600f, 0.118364f,
mjr 64:ef7ca92dff36 961 0.121170f, 0.124019f, 0.126910f, 0.129844f, 0.132821f, 0.135842f, 0.138907f, 0.142016f,
mjr 64:ef7ca92dff36 962 0.145170f, 0.148367f, 0.151610f, 0.154898f, 0.158232f, 0.161611f, 0.165037f, 0.168509f,
mjr 64:ef7ca92dff36 963 0.172027f, 0.175592f, 0.179205f, 0.182864f, 0.186572f, 0.190327f, 0.194131f, 0.197983f,
mjr 64:ef7ca92dff36 964 0.201884f, 0.205834f, 0.209834f, 0.213883f, 0.217982f, 0.222131f, 0.226330f, 0.230581f,
mjr 64:ef7ca92dff36 965 0.234882f, 0.239234f, 0.243638f, 0.248094f, 0.252602f, 0.257162f, 0.261774f, 0.266440f,
mjr 64:ef7ca92dff36 966 0.271159f, 0.275931f, 0.280756f, 0.285636f, 0.290570f, 0.295558f, 0.300601f, 0.305699f,
mjr 64:ef7ca92dff36 967 0.310852f, 0.316061f, 0.321325f, 0.326645f, 0.332022f, 0.337456f, 0.342946f, 0.348493f,
mjr 64:ef7ca92dff36 968 0.354098f, 0.359760f, 0.365480f, 0.371258f, 0.377095f, 0.382990f, 0.388944f, 0.394958f,
mjr 64:ef7ca92dff36 969 0.401030f, 0.407163f, 0.413356f, 0.419608f, 0.425921f, 0.432295f, 0.438730f, 0.445226f,
mjr 64:ef7ca92dff36 970 0.451784f, 0.458404f, 0.465085f, 0.471829f, 0.478635f, 0.485504f, 0.492436f, 0.499432f,
mjr 64:ef7ca92dff36 971 0.506491f, 0.513614f, 0.520800f, 0.528052f, 0.535367f, 0.542748f, 0.550194f, 0.557705f,
mjr 64:ef7ca92dff36 972 0.565282f, 0.572924f, 0.580633f, 0.588408f, 0.596249f, 0.604158f, 0.612133f, 0.620176f,
mjr 64:ef7ca92dff36 973 0.628287f, 0.636465f, 0.644712f, 0.653027f, 0.661410f, 0.669863f, 0.678384f, 0.686975f,
mjr 64:ef7ca92dff36 974 0.695636f, 0.704366f, 0.713167f, 0.722038f, 0.730979f, 0.739992f, 0.749075f, 0.758230f,
mjr 64:ef7ca92dff36 975 0.767457f, 0.776755f, 0.786126f, 0.795568f, 0.805084f, 0.814672f, 0.824334f, 0.834068f,
mjr 64:ef7ca92dff36 976 0.843877f, 0.853759f, 0.863715f, 0.873746f, 0.883851f, 0.894031f, 0.904286f, 0.914616f,
mjr 64:ef7ca92dff36 977 0.925022f, 0.935504f, 0.946062f, 0.956696f, 0.967407f, 0.978194f, 0.989058f, 1.000000f
mjr 64:ef7ca92dff36 978 };
mjr 64:ef7ca92dff36 979
mjr 64:ef7ca92dff36 980 // LwOut class for a PWM-capable GPIO port. Note that we use FastPWM for
mjr 64:ef7ca92dff36 981 // the underlying port interface. This isn't because we need the "fast"
mjr 64:ef7ca92dff36 982 // part; it's because FastPWM fixes a bug in the base mbed PwmOut class
mjr 64:ef7ca92dff36 983 // that makes it look ugly for fades. The base PwmOut class resets
mjr 64:ef7ca92dff36 984 // the cycle counter when changing the duty cycle, which makes the output
mjr 64:ef7ca92dff36 985 // reset immediately on every change. For an output connected to a lamp
mjr 64:ef7ca92dff36 986 // or LED, this causes obvious flickering when performing a rapid series
mjr 64:ef7ca92dff36 987 // of writes, such as during a fade. The KL25Z TPM hardware is specifically
mjr 64:ef7ca92dff36 988 // designed to make it easy for software to avoid this kind of flickering
mjr 64:ef7ca92dff36 989 // when used correctly: it has an internal staging register for the duty
mjr 64:ef7ca92dff36 990 // cycle register that gets latched at the start of the next cycle, ensuring
mjr 64:ef7ca92dff36 991 // that the duty cycle setting never changes mid-cycle. The mbed PwmOut
mjr 64:ef7ca92dff36 992 // defeats this by resetting the cycle counter on every write, which aborts
mjr 64:ef7ca92dff36 993 // the current cycle at the moment of the write, causing an effectively random
mjr 64:ef7ca92dff36 994 // drop in brightness on each write (by artificially shortening a cycle).
mjr 64:ef7ca92dff36 995 // Fortunately, we can fix this by switching to the API-compatible FastPWM
mjr 64:ef7ca92dff36 996 // class, which does the write right (heh).
mjr 6:cc35eb643e8f 997 class LwPwmOut: public LwOut
mjr 6:cc35eb643e8f 998 {
mjr 6:cc35eb643e8f 999 public:
mjr 43:7a6364d82a41 1000 LwPwmOut(PinName pin, uint8_t initVal) : p(pin)
mjr 43:7a6364d82a41 1001 {
mjr 43:7a6364d82a41 1002 prv = initVal ^ 0xFF;
mjr 43:7a6364d82a41 1003 set(initVal);
mjr 43:7a6364d82a41 1004 }
mjr 40:cc0d9814522b 1005 virtual void set(uint8_t val)
mjr 13:72dda449c3c0 1006 {
mjr 13:72dda449c3c0 1007 if (val != prv)
mjr 40:cc0d9814522b 1008 p.write(pwm_level[prv = val]);
mjr 13:72dda449c3c0 1009 }
mjr 64:ef7ca92dff36 1010 FastPWM p;
mjr 40:cc0d9814522b 1011 uint8_t prv;
mjr 6:cc35eb643e8f 1012 };
mjr 26:cb71c4af2912 1013
mjr 64:ef7ca92dff36 1014 // Gamma corrected PWM GPIO output
mjr 64:ef7ca92dff36 1015 class LwPwmGammaOut: public LwPwmOut
mjr 64:ef7ca92dff36 1016 {
mjr 64:ef7ca92dff36 1017 public:
mjr 64:ef7ca92dff36 1018 LwPwmGammaOut(PinName pin, uint8_t initVal)
mjr 64:ef7ca92dff36 1019 : LwPwmOut(pin, initVal)
mjr 64:ef7ca92dff36 1020 {
mjr 64:ef7ca92dff36 1021 }
mjr 64:ef7ca92dff36 1022 virtual void set(uint8_t val)
mjr 64:ef7ca92dff36 1023 {
mjr 64:ef7ca92dff36 1024 if (val != prv)
mjr 64:ef7ca92dff36 1025 p.write(dof_to_gamma_pwm[prv = val]);
mjr 64:ef7ca92dff36 1026 }
mjr 64:ef7ca92dff36 1027 };
mjr 64:ef7ca92dff36 1028
mjr 64:ef7ca92dff36 1029
mjr 26:cb71c4af2912 1030 // LwOut class for a Digital-Only (Non-PWM) GPIO port
mjr 6:cc35eb643e8f 1031 class LwDigOut: public LwOut
mjr 6:cc35eb643e8f 1032 {
mjr 6:cc35eb643e8f 1033 public:
mjr 43:7a6364d82a41 1034 LwDigOut(PinName pin, uint8_t initVal) : p(pin, initVal ? 1 : 0) { prv = initVal; }
mjr 40:cc0d9814522b 1035 virtual void set(uint8_t val)
mjr 13:72dda449c3c0 1036 {
mjr 13:72dda449c3c0 1037 if (val != prv)
mjr 40:cc0d9814522b 1038 p.write((prv = val) == 0 ? 0 : 1);
mjr 13:72dda449c3c0 1039 }
mjr 6:cc35eb643e8f 1040 DigitalOut p;
mjr 40:cc0d9814522b 1041 uint8_t prv;
mjr 6:cc35eb643e8f 1042 };
mjr 26:cb71c4af2912 1043
mjr 29:582472d0bc57 1044 // Array of output physical pin assignments. This array is indexed
mjr 29:582472d0bc57 1045 // by LedWiz logical port number - lwPin[n] is the maping for LedWiz
mjr 35:e959ffba78fd 1046 // port n (0-based).
mjr 35:e959ffba78fd 1047 //
mjr 35:e959ffba78fd 1048 // Each pin is handled by an interface object for the physical output
mjr 35:e959ffba78fd 1049 // type for the port, as set in the configuration. The interface
mjr 35:e959ffba78fd 1050 // objects handle the specifics of addressing the different hardware
mjr 35:e959ffba78fd 1051 // types (GPIO PWM ports, GPIO digital ports, TLC5940 ports, and
mjr 35:e959ffba78fd 1052 // 74HC595 ports).
mjr 33:d832bcab089e 1053 static int numOutputs;
mjr 33:d832bcab089e 1054 static LwOut **lwPin;
mjr 33:d832bcab089e 1055
mjr 38:091e511ce8a0 1056
mjr 35:e959ffba78fd 1057 // Number of LedWiz emulation outputs. This is the number of ports
mjr 35:e959ffba78fd 1058 // accessible through the standard (non-extended) LedWiz protocol
mjr 35:e959ffba78fd 1059 // messages. The protocol has a fixed set of 32 outputs, but we
mjr 35:e959ffba78fd 1060 // might have fewer actual outputs. This is therefore set to the
mjr 35:e959ffba78fd 1061 // lower of 32 or the actual number of outputs.
mjr 35:e959ffba78fd 1062 static int numLwOutputs;
mjr 35:e959ffba78fd 1063
mjr 63:5cd1a5f3a41b 1064 // Current absolute brightness levels for all outputs. These are
mjr 63:5cd1a5f3a41b 1065 // DOF brightness level value, from 0 for fully off to 255 for fully
mjr 63:5cd1a5f3a41b 1066 // on. These are always used for extended ports (33 and above), and
mjr 63:5cd1a5f3a41b 1067 // are used for LedWiz ports (1-32) when we're in extended protocol
mjr 63:5cd1a5f3a41b 1068 // mode (i.e., ledWizMode == false).
mjr 40:cc0d9814522b 1069 static uint8_t *outLevel;
mjr 38:091e511ce8a0 1070
mjr 38:091e511ce8a0 1071 // create a single output pin
mjr 53:9b2611964afc 1072 LwOut *createLwPin(int portno, LedWizPortCfg &pc, Config &cfg)
mjr 38:091e511ce8a0 1073 {
mjr 38:091e511ce8a0 1074 // get this item's values
mjr 38:091e511ce8a0 1075 int typ = pc.typ;
mjr 38:091e511ce8a0 1076 int pin = pc.pin;
mjr 38:091e511ce8a0 1077 int flags = pc.flags;
mjr 40:cc0d9814522b 1078 int noisy = flags & PortFlagNoisemaker;
mjr 38:091e511ce8a0 1079 int activeLow = flags & PortFlagActiveLow;
mjr 40:cc0d9814522b 1080 int gamma = flags & PortFlagGamma;
mjr 38:091e511ce8a0 1081
mjr 38:091e511ce8a0 1082 // create the pin interface object according to the port type
mjr 38:091e511ce8a0 1083 LwOut *lwp;
mjr 38:091e511ce8a0 1084 switch (typ)
mjr 38:091e511ce8a0 1085 {
mjr 38:091e511ce8a0 1086 case PortTypeGPIOPWM:
mjr 48:058ace2aed1d 1087 // PWM GPIO port - assign if we have a valid pin
mjr 48:058ace2aed1d 1088 if (pin != 0)
mjr 64:ef7ca92dff36 1089 {
mjr 64:ef7ca92dff36 1090 // If gamma correction is to be used, and we're not inverting the output,
mjr 64:ef7ca92dff36 1091 // use the combined Pwmout + Gamma output class; otherwise use the plain
mjr 64:ef7ca92dff36 1092 // PwmOut class. We can't use the combined class for inverted outputs
mjr 64:ef7ca92dff36 1093 // because we have to apply gamma correction before the inversion.
mjr 64:ef7ca92dff36 1094 if (gamma && !activeLow)
mjr 64:ef7ca92dff36 1095 {
mjr 64:ef7ca92dff36 1096 // use the gamma-corrected PwmOut type
mjr 64:ef7ca92dff36 1097 lwp = new LwPwmGammaOut(wirePinName(pin), 0);
mjr 64:ef7ca92dff36 1098
mjr 64:ef7ca92dff36 1099 // don't apply further gamma correction to this output
mjr 64:ef7ca92dff36 1100 gamma = false;
mjr 64:ef7ca92dff36 1101 }
mjr 64:ef7ca92dff36 1102 else
mjr 64:ef7ca92dff36 1103 {
mjr 64:ef7ca92dff36 1104 // no gamma correction - use the standard PwmOut class
mjr 64:ef7ca92dff36 1105 lwp = new LwPwmOut(wirePinName(pin), activeLow ? 255 : 0);
mjr 64:ef7ca92dff36 1106 }
mjr 64:ef7ca92dff36 1107 }
mjr 48:058ace2aed1d 1108 else
mjr 48:058ace2aed1d 1109 lwp = new LwVirtualOut();
mjr 38:091e511ce8a0 1110 break;
mjr 38:091e511ce8a0 1111
mjr 38:091e511ce8a0 1112 case PortTypeGPIODig:
mjr 38:091e511ce8a0 1113 // Digital GPIO port
mjr 48:058ace2aed1d 1114 if (pin != 0)
mjr 48:058ace2aed1d 1115 lwp = new LwDigOut(wirePinName(pin), activeLow ? 255 : 0);
mjr 48:058ace2aed1d 1116 else
mjr 48:058ace2aed1d 1117 lwp = new LwVirtualOut();
mjr 38:091e511ce8a0 1118 break;
mjr 38:091e511ce8a0 1119
mjr 38:091e511ce8a0 1120 case PortTypeTLC5940:
mjr 38:091e511ce8a0 1121 // TLC5940 port (if we don't have a TLC controller object, or it's not a valid
mjr 38:091e511ce8a0 1122 // output port number on the chips we have, create a virtual port)
mjr 38:091e511ce8a0 1123 if (tlc5940 != 0 && pin < cfg.tlc5940.nchips*16)
mjr 40:cc0d9814522b 1124 {
mjr 40:cc0d9814522b 1125 // If gamma correction is to be used, and we're not inverting the output,
mjr 40:cc0d9814522b 1126 // use the combined TLC4950 + Gamma output class. Otherwise use the plain
mjr 40:cc0d9814522b 1127 // TLC5940 output. We skip the combined class if the output is inverted
mjr 40:cc0d9814522b 1128 // because we need to apply gamma BEFORE the inversion to get the right
mjr 40:cc0d9814522b 1129 // results, but the combined class would apply it after because of the
mjr 40:cc0d9814522b 1130 // layering scheme - the combined class is a physical device output class,
mjr 40:cc0d9814522b 1131 // and a physical device output class is necessarily at the bottom of
mjr 40:cc0d9814522b 1132 // the stack. We don't have a combined inverted+gamma+TLC class, because
mjr 40:cc0d9814522b 1133 // inversion isn't recommended for TLC5940 chips in the first place, so
mjr 40:cc0d9814522b 1134 // it's not worth the extra memory footprint to have a dedicated table
mjr 40:cc0d9814522b 1135 // for this unlikely case.
mjr 40:cc0d9814522b 1136 if (gamma && !activeLow)
mjr 40:cc0d9814522b 1137 {
mjr 40:cc0d9814522b 1138 // use the gamma-corrected 5940 output mapper
mjr 40:cc0d9814522b 1139 lwp = new Lw5940GammaOut(pin);
mjr 40:cc0d9814522b 1140
mjr 40:cc0d9814522b 1141 // DON'T apply further gamma correction to this output
mjr 40:cc0d9814522b 1142 gamma = false;
mjr 40:cc0d9814522b 1143 }
mjr 40:cc0d9814522b 1144 else
mjr 40:cc0d9814522b 1145 {
mjr 40:cc0d9814522b 1146 // no gamma - use the plain (linear) 5940 output class
mjr 40:cc0d9814522b 1147 lwp = new Lw5940Out(pin);
mjr 40:cc0d9814522b 1148 }
mjr 40:cc0d9814522b 1149 }
mjr 38:091e511ce8a0 1150 else
mjr 40:cc0d9814522b 1151 {
mjr 40:cc0d9814522b 1152 // no TLC5940 chips, or invalid port number - use a virtual out
mjr 38:091e511ce8a0 1153 lwp = new LwVirtualOut();
mjr 40:cc0d9814522b 1154 }
mjr 38:091e511ce8a0 1155 break;
mjr 38:091e511ce8a0 1156
mjr 38:091e511ce8a0 1157 case PortType74HC595:
mjr 38:091e511ce8a0 1158 // 74HC595 port (if we don't have an HC595 controller object, or it's not a valid
mjr 38:091e511ce8a0 1159 // output number, create a virtual port)
mjr 38:091e511ce8a0 1160 if (hc595 != 0 && pin < cfg.hc595.nchips*8)
mjr 38:091e511ce8a0 1161 lwp = new Lw595Out(pin);
mjr 38:091e511ce8a0 1162 else
mjr 38:091e511ce8a0 1163 lwp = new LwVirtualOut();
mjr 38:091e511ce8a0 1164 break;
mjr 38:091e511ce8a0 1165
mjr 38:091e511ce8a0 1166 case PortTypeVirtual:
mjr 43:7a6364d82a41 1167 case PortTypeDisabled:
mjr 38:091e511ce8a0 1168 default:
mjr 38:091e511ce8a0 1169 // virtual or unknown
mjr 38:091e511ce8a0 1170 lwp = new LwVirtualOut();
mjr 38:091e511ce8a0 1171 break;
mjr 38:091e511ce8a0 1172 }
mjr 38:091e511ce8a0 1173
mjr 40:cc0d9814522b 1174 // If it's Active Low, layer on an inverter. Note that an inverter
mjr 40:cc0d9814522b 1175 // needs to be the bottom-most layer, since all of the other filters
mjr 40:cc0d9814522b 1176 // assume that they're working with normal (non-inverted) values.
mjr 38:091e511ce8a0 1177 if (activeLow)
mjr 38:091e511ce8a0 1178 lwp = new LwInvertedOut(lwp);
mjr 40:cc0d9814522b 1179
mjr 40:cc0d9814522b 1180 // If it's a noisemaker, layer on a night mode switch. Note that this
mjr 40:cc0d9814522b 1181 // needs to be
mjr 40:cc0d9814522b 1182 if (noisy)
mjr 40:cc0d9814522b 1183 lwp = new LwNoisyOut(lwp);
mjr 40:cc0d9814522b 1184
mjr 40:cc0d9814522b 1185 // If it's gamma-corrected, layer on a gamma corrector
mjr 40:cc0d9814522b 1186 if (gamma)
mjr 40:cc0d9814522b 1187 lwp = new LwGammaOut(lwp);
mjr 53:9b2611964afc 1188
mjr 53:9b2611964afc 1189 // If this is the ZB Launch Ball port, layer a monitor object. Note
mjr 64:ef7ca92dff36 1190 // that the nominal port numbering in the config starts at 1, but we're
mjr 53:9b2611964afc 1191 // using an array index, so test against portno+1.
mjr 53:9b2611964afc 1192 if (portno + 1 == cfg.plunger.zbLaunchBall.port)
mjr 53:9b2611964afc 1193 lwp = new LwZbLaunchOut(lwp);
mjr 53:9b2611964afc 1194
mjr 53:9b2611964afc 1195 // If this is the Night Mode indicator port, layer a night mode object.
mjr 53:9b2611964afc 1196 if (portno + 1 == cfg.nightMode.port)
mjr 53:9b2611964afc 1197 lwp = new LwNightModeIndicatorOut(lwp);
mjr 38:091e511ce8a0 1198
mjr 38:091e511ce8a0 1199 // turn it off initially
mjr 38:091e511ce8a0 1200 lwp->set(0);
mjr 38:091e511ce8a0 1201
mjr 38:091e511ce8a0 1202 // return the pin
mjr 38:091e511ce8a0 1203 return lwp;
mjr 38:091e511ce8a0 1204 }
mjr 38:091e511ce8a0 1205
mjr 6:cc35eb643e8f 1206 // initialize the output pin array
mjr 35:e959ffba78fd 1207 void initLwOut(Config &cfg)
mjr 6:cc35eb643e8f 1208 {
mjr 35:e959ffba78fd 1209 // Count the outputs. The first disabled output determines the
mjr 35:e959ffba78fd 1210 // total number of ports.
mjr 35:e959ffba78fd 1211 numOutputs = MAX_OUT_PORTS;
mjr 33:d832bcab089e 1212 int i;
mjr 35:e959ffba78fd 1213 for (i = 0 ; i < MAX_OUT_PORTS ; ++i)
mjr 6:cc35eb643e8f 1214 {
mjr 35:e959ffba78fd 1215 if (cfg.outPort[i].typ == PortTypeDisabled)
mjr 34:6b981a2afab7 1216 {
mjr 35:e959ffba78fd 1217 numOutputs = i;
mjr 34:6b981a2afab7 1218 break;
mjr 34:6b981a2afab7 1219 }
mjr 33:d832bcab089e 1220 }
mjr 33:d832bcab089e 1221
mjr 35:e959ffba78fd 1222 // the real LedWiz protocol can access at most 32 ports, or the
mjr 35:e959ffba78fd 1223 // actual number of outputs, whichever is lower
mjr 35:e959ffba78fd 1224 numLwOutputs = (numOutputs < 32 ? numOutputs : 32);
mjr 35:e959ffba78fd 1225
mjr 33:d832bcab089e 1226 // allocate the pin array
mjr 33:d832bcab089e 1227 lwPin = new LwOut*[numOutputs];
mjr 33:d832bcab089e 1228
mjr 38:091e511ce8a0 1229 // Allocate the current brightness array. For these, allocate at
mjr 38:091e511ce8a0 1230 // least 32, so that we have enough for all LedWiz messages, but
mjr 38:091e511ce8a0 1231 // allocate the full set of actual ports if we have more than the
mjr 38:091e511ce8a0 1232 // LedWiz complement.
mjr 38:091e511ce8a0 1233 int minOuts = numOutputs < 32 ? 32 : numOutputs;
mjr 40:cc0d9814522b 1234 outLevel = new uint8_t[minOuts];
mjr 33:d832bcab089e 1235
mjr 35:e959ffba78fd 1236 // create the pin interface object for each port
mjr 35:e959ffba78fd 1237 for (i = 0 ; i < numOutputs ; ++i)
mjr 53:9b2611964afc 1238 lwPin[i] = createLwPin(i, cfg.outPort[i], cfg);
mjr 6:cc35eb643e8f 1239 }
mjr 6:cc35eb643e8f 1240
mjr 63:5cd1a5f3a41b 1241 // LedWiz/Extended protocol mode.
mjr 63:5cd1a5f3a41b 1242 //
mjr 63:5cd1a5f3a41b 1243 // We implement output port control using both the legacy LedWiz
mjr 63:5cd1a5f3a41b 1244 // protocol and a private extended protocol (which is 100% backwards
mjr 63:5cd1a5f3a41b 1245 // compatible with the LedWiz protocol: we recognize all valid legacy
mjr 63:5cd1a5f3a41b 1246 // protocol commands and handle them the same way a real LedWiz does).
mjr 63:5cd1a5f3a41b 1247 // The legacy protocol can access the first 32 ports; the extended
mjr 63:5cd1a5f3a41b 1248 // protocol can access all ports, including the first 32 as well as
mjr 63:5cd1a5f3a41b 1249 // the higher numbered ports. This means that the first 32 ports
mjr 63:5cd1a5f3a41b 1250 // can be addressed with either protocol, which muddies the waters
mjr 63:5cd1a5f3a41b 1251 // a bit because of the different approaches the two protocols take.
mjr 63:5cd1a5f3a41b 1252 // The legacy protocol separates the brightness/flash state of an
mjr 63:5cd1a5f3a41b 1253 // output (which it calls the "profile" state) from the on/off state.
mjr 63:5cd1a5f3a41b 1254 // The extended protocol doesn't; "off" is simply represented as
mjr 63:5cd1a5f3a41b 1255 // brightness 0.
mjr 63:5cd1a5f3a41b 1256 //
mjr 63:5cd1a5f3a41b 1257 // To deal with the different approaches, we use this flag to keep
mjr 63:5cd1a5f3a41b 1258 // track of the global protocol state. Each time we get an output
mjr 63:5cd1a5f3a41b 1259 // port command, we switch the protocol state to the protocol that
mjr 63:5cd1a5f3a41b 1260 // was used in the command. On a legacy SBA or PBA, we switch to
mjr 63:5cd1a5f3a41b 1261 // LedWiz mode; on an extended output set message, we switch to
mjr 63:5cd1a5f3a41b 1262 // extended mode. We remember the LedWiz and extended output state
mjr 63:5cd1a5f3a41b 1263 // for each LW ports (1-32) separately. Any time the mode changes,
mjr 63:5cd1a5f3a41b 1264 // we set ports 1-32 back to the state for the new mode.
mjr 63:5cd1a5f3a41b 1265 //
mjr 63:5cd1a5f3a41b 1266 // The reasoning here is that any given client (on the PC) will use
mjr 63:5cd1a5f3a41b 1267 // one mode or the other, and won't mix the two. An older program
mjr 63:5cd1a5f3a41b 1268 // that only knows about the LedWiz protocol will use the legacy
mjr 63:5cd1a5f3a41b 1269 // protocol only, and never send us an extended command. A DOF-based
mjr 63:5cd1a5f3a41b 1270 // program might use one or the other, according to how the user has
mjr 63:5cd1a5f3a41b 1271 // configured DOF. We have to be able to switch seamlessly between
mjr 63:5cd1a5f3a41b 1272 // the protocols to accommodate switching from one type of program
mjr 63:5cd1a5f3a41b 1273 // on the PC to the other, but we shouldn't have to worry about one
mjr 63:5cd1a5f3a41b 1274 // program switching back and forth.
mjr 63:5cd1a5f3a41b 1275 static uint8_t ledWizMode = true;
mjr 63:5cd1a5f3a41b 1276
mjr 29:582472d0bc57 1277 // LedWiz output states.
mjr 29:582472d0bc57 1278 //
mjr 29:582472d0bc57 1279 // The LedWiz protocol has two separate control axes for each output.
mjr 29:582472d0bc57 1280 // One axis is its on/off state; the other is its "profile" state, which
mjr 29:582472d0bc57 1281 // is either a fixed brightness or a blinking pattern for the light.
mjr 29:582472d0bc57 1282 // The two axes are independent.
mjr 29:582472d0bc57 1283 //
mjr 29:582472d0bc57 1284 // Note that the LedWiz protocol can only address 32 outputs, so the
mjr 29:582472d0bc57 1285 // wizOn and wizVal arrays have fixed sizes of 32 elements no matter
mjr 29:582472d0bc57 1286 // how many physical outputs we're using.
mjr 29:582472d0bc57 1287
mjr 0:5acbbe3f4cf4 1288 // on/off state for each LedWiz output
mjr 1:d913e0afb2ac 1289 static uint8_t wizOn[32];
mjr 0:5acbbe3f4cf4 1290
mjr 40:cc0d9814522b 1291 // LedWiz "Profile State" (the LedWiz brightness level or blink mode)
mjr 40:cc0d9814522b 1292 // for each LedWiz output. If the output was last updated through an
mjr 40:cc0d9814522b 1293 // LedWiz protocol message, it will have one of these values:
mjr 29:582472d0bc57 1294 //
mjr 29:582472d0bc57 1295 // 0-48 = fixed brightness 0% to 100%
mjr 40:cc0d9814522b 1296 // 49 = fixed brightness 100% (equivalent to 48)
mjr 29:582472d0bc57 1297 // 129 = ramp up / ramp down
mjr 29:582472d0bc57 1298 // 130 = flash on / off
mjr 29:582472d0bc57 1299 // 131 = on / ramp down
mjr 29:582472d0bc57 1300 // 132 = ramp up / on
mjr 29:582472d0bc57 1301 //
mjr 40:cc0d9814522b 1302 // (Note that value 49 isn't documented in the LedWiz spec, but real
mjr 40:cc0d9814522b 1303 // LedWiz units treat it as equivalent to 48, and some PC software uses
mjr 40:cc0d9814522b 1304 // it, so we need to accept it for compatibility.)
mjr 1:d913e0afb2ac 1305 static uint8_t wizVal[32] = {
mjr 13:72dda449c3c0 1306 48, 48, 48, 48, 48, 48, 48, 48,
mjr 13:72dda449c3c0 1307 48, 48, 48, 48, 48, 48, 48, 48,
mjr 13:72dda449c3c0 1308 48, 48, 48, 48, 48, 48, 48, 48,
mjr 13:72dda449c3c0 1309 48, 48, 48, 48, 48, 48, 48, 48
mjr 0:5acbbe3f4cf4 1310 };
mjr 0:5acbbe3f4cf4 1311
mjr 29:582472d0bc57 1312 // LedWiz flash speed. This is a value from 1 to 7 giving the pulse
mjr 29:582472d0bc57 1313 // rate for lights in blinking states.
mjr 29:582472d0bc57 1314 static uint8_t wizSpeed = 2;
mjr 29:582472d0bc57 1315
mjr 40:cc0d9814522b 1316 // Current LedWiz flash cycle counter. This runs from 0 to 255
mjr 40:cc0d9814522b 1317 // during each cycle.
mjr 29:582472d0bc57 1318 static uint8_t wizFlashCounter = 0;
mjr 29:582472d0bc57 1319
mjr 40:cc0d9814522b 1320 // translate an LedWiz brightness level (0-49) to a DOF brightness
mjr 40:cc0d9814522b 1321 // level (0-255)
mjr 40:cc0d9814522b 1322 static const uint8_t lw_to_dof[] = {
mjr 40:cc0d9814522b 1323 0, 5, 11, 16, 21, 27, 32, 37,
mjr 40:cc0d9814522b 1324 43, 48, 53, 58, 64, 69, 74, 80,
mjr 40:cc0d9814522b 1325 85, 90, 96, 101, 106, 112, 117, 122,
mjr 40:cc0d9814522b 1326 128, 133, 138, 143, 149, 154, 159, 165,
mjr 40:cc0d9814522b 1327 170, 175, 181, 186, 191, 197, 202, 207,
mjr 40:cc0d9814522b 1328 213, 218, 223, 228, 234, 239, 244, 250,
mjr 40:cc0d9814522b 1329 255, 255
mjr 40:cc0d9814522b 1330 };
mjr 40:cc0d9814522b 1331
mjr 40:cc0d9814522b 1332 // Translate an LedWiz output (ports 1-32) to a DOF brightness level.
mjr 40:cc0d9814522b 1333 static uint8_t wizState(int idx)
mjr 0:5acbbe3f4cf4 1334 {
mjr 63:5cd1a5f3a41b 1335 // If we're in extended protocol mode, ignore the LedWiz setting
mjr 63:5cd1a5f3a41b 1336 // for the port and use the new protocol setting instead.
mjr 63:5cd1a5f3a41b 1337 if (!ledWizMode)
mjr 29:582472d0bc57 1338 return outLevel[idx];
mjr 29:582472d0bc57 1339
mjr 29:582472d0bc57 1340 // if it's off, show at zero intensity
mjr 29:582472d0bc57 1341 if (!wizOn[idx])
mjr 29:582472d0bc57 1342 return 0;
mjr 29:582472d0bc57 1343
mjr 29:582472d0bc57 1344 // check the state
mjr 29:582472d0bc57 1345 uint8_t val = wizVal[idx];
mjr 40:cc0d9814522b 1346 if (val <= 49)
mjr 29:582472d0bc57 1347 {
mjr 29:582472d0bc57 1348 // PWM brightness/intensity level. Rescale from the LedWiz
mjr 29:582472d0bc57 1349 // 0..48 integer range to our internal PwmOut 0..1 float range.
mjr 29:582472d0bc57 1350 // Note that on the actual LedWiz, level 48 is actually about
mjr 29:582472d0bc57 1351 // 98% on - contrary to the LedWiz documentation, level 49 is
mjr 29:582472d0bc57 1352 // the true 100% level. (In the documentation, level 49 is
mjr 29:582472d0bc57 1353 // simply not a valid setting.) Even so, we treat level 48 as
mjr 29:582472d0bc57 1354 // 100% on to match the documentation. This won't be perfectly
mjr 29:582472d0bc57 1355 // ocmpatible with the actual LedWiz, but it makes for such a
mjr 29:582472d0bc57 1356 // small difference in brightness (if the output device is an
mjr 29:582472d0bc57 1357 // LED, say) that no one should notice. It seems better to
mjr 29:582472d0bc57 1358 // err in this direction, because while the difference in
mjr 29:582472d0bc57 1359 // brightness when attached to an LED won't be noticeable, the
mjr 29:582472d0bc57 1360 // difference in duty cycle when attached to something like a
mjr 29:582472d0bc57 1361 // contactor *can* be noticeable - anything less than 100%
mjr 29:582472d0bc57 1362 // can cause a contactor or relay to chatter. There's almost
mjr 29:582472d0bc57 1363 // never a situation where you'd want values other than 0% and
mjr 29:582472d0bc57 1364 // 100% for a contactor or relay, so treating level 48 as 100%
mjr 29:582472d0bc57 1365 // makes us work properly with software that's expecting the
mjr 29:582472d0bc57 1366 // documented LedWiz behavior and therefore uses level 48 to
mjr 29:582472d0bc57 1367 // turn a contactor or relay fully on.
mjr 40:cc0d9814522b 1368 //
mjr 40:cc0d9814522b 1369 // Note that value 49 is undefined in the LedWiz documentation,
mjr 40:cc0d9814522b 1370 // but real LedWiz units treat it as 100%, equivalent to 48.
mjr 40:cc0d9814522b 1371 // Some software on the PC side uses this, so we need to treat
mjr 40:cc0d9814522b 1372 // it the same way for compatibility.
mjr 40:cc0d9814522b 1373 return lw_to_dof[val];
mjr 29:582472d0bc57 1374 }
mjr 29:582472d0bc57 1375 else if (val == 129)
mjr 29:582472d0bc57 1376 {
mjr 40:cc0d9814522b 1377 // 129 = ramp up / ramp down
mjr 30:6e9902f06f48 1378 return wizFlashCounter < 128
mjr 40:cc0d9814522b 1379 ? wizFlashCounter*2 + 1
mjr 40:cc0d9814522b 1380 : (255 - wizFlashCounter)*2;
mjr 29:582472d0bc57 1381 }
mjr 29:582472d0bc57 1382 else if (val == 130)
mjr 29:582472d0bc57 1383 {
mjr 40:cc0d9814522b 1384 // 130 = flash on / off
mjr 40:cc0d9814522b 1385 return wizFlashCounter < 128 ? 255 : 0;
mjr 29:582472d0bc57 1386 }
mjr 29:582472d0bc57 1387 else if (val == 131)
mjr 29:582472d0bc57 1388 {
mjr 40:cc0d9814522b 1389 // 131 = on / ramp down
mjr 40:cc0d9814522b 1390 return wizFlashCounter < 128 ? 255 : (255 - wizFlashCounter)*2;
mjr 0:5acbbe3f4cf4 1391 }
mjr 29:582472d0bc57 1392 else if (val == 132)
mjr 29:582472d0bc57 1393 {
mjr 40:cc0d9814522b 1394 // 132 = ramp up / on
mjr 40:cc0d9814522b 1395 return wizFlashCounter < 128 ? wizFlashCounter*2 : 255;
mjr 29:582472d0bc57 1396 }
mjr 29:582472d0bc57 1397 else
mjr 13:72dda449c3c0 1398 {
mjr 29:582472d0bc57 1399 // Other values are undefined in the LedWiz documentation. Hosts
mjr 29:582472d0bc57 1400 // *should* never send undefined values, since whatever behavior an
mjr 29:582472d0bc57 1401 // LedWiz unit exhibits in response is accidental and could change
mjr 29:582472d0bc57 1402 // in a future version. We'll treat all undefined values as equivalent
mjr 29:582472d0bc57 1403 // to 48 (fully on).
mjr 40:cc0d9814522b 1404 return 255;
mjr 0:5acbbe3f4cf4 1405 }
mjr 0:5acbbe3f4cf4 1406 }
mjr 0:5acbbe3f4cf4 1407
mjr 29:582472d0bc57 1408 // LedWiz flash timer pulse. This fires periodically to update
mjr 29:582472d0bc57 1409 // LedWiz flashing outputs. At the slowest pulse speed set via
mjr 29:582472d0bc57 1410 // the SBA command, each waveform cycle has 256 steps, so we
mjr 29:582472d0bc57 1411 // choose the pulse time base so that the slowest cycle completes
mjr 29:582472d0bc57 1412 // in 2 seconds. This seems to roughly match the real LedWiz
mjr 29:582472d0bc57 1413 // behavior. We run the pulse timer at the same rate regardless
mjr 29:582472d0bc57 1414 // of the pulse speed; at higher pulse speeds, we simply use
mjr 29:582472d0bc57 1415 // larger steps through the cycle on each interrupt. Running
mjr 29:582472d0bc57 1416 // every 1/127 of a second = 8ms seems to be a pretty light load.
mjr 29:582472d0bc57 1417 Timeout wizPulseTimer;
mjr 38:091e511ce8a0 1418 #define WIZ_PULSE_TIME_BASE (1.0f/127.0f)
mjr 29:582472d0bc57 1419 static void wizPulse()
mjr 29:582472d0bc57 1420 {
mjr 29:582472d0bc57 1421 // increase the counter by the speed increment, and wrap at 256
mjr 29:582472d0bc57 1422 wizFlashCounter += wizSpeed;
mjr 29:582472d0bc57 1423 wizFlashCounter &= 0xff;
mjr 29:582472d0bc57 1424
mjr 29:582472d0bc57 1425 // if we have any flashing lights, update them
mjr 29:582472d0bc57 1426 int ena = false;
mjr 35:e959ffba78fd 1427 for (int i = 0 ; i < numLwOutputs ; ++i)
mjr 29:582472d0bc57 1428 {
mjr 29:582472d0bc57 1429 if (wizOn[i])
mjr 29:582472d0bc57 1430 {
mjr 29:582472d0bc57 1431 uint8_t s = wizVal[i];
mjr 29:582472d0bc57 1432 if (s >= 129 && s <= 132)
mjr 29:582472d0bc57 1433 {
mjr 40:cc0d9814522b 1434 lwPin[i]->set(wizState(i));
mjr 29:582472d0bc57 1435 ena = true;
mjr 29:582472d0bc57 1436 }
mjr 29:582472d0bc57 1437 }
mjr 29:582472d0bc57 1438 }
mjr 29:582472d0bc57 1439
mjr 29:582472d0bc57 1440 // Set up the next timer pulse only if we found anything flashing.
mjr 29:582472d0bc57 1441 // To minimize overhead from this feature, we only enable the interrupt
mjr 29:582472d0bc57 1442 // when we need it. This eliminates any performance penalty to other
mjr 29:582472d0bc57 1443 // features when the host software doesn't care about the flashing
mjr 29:582472d0bc57 1444 // modes. For example, DOF never uses these modes, so there's no
mjr 29:582472d0bc57 1445 // need for them when running Visual Pinball.
mjr 29:582472d0bc57 1446 if (ena)
mjr 29:582472d0bc57 1447 wizPulseTimer.attach(wizPulse, WIZ_PULSE_TIME_BASE);
mjr 29:582472d0bc57 1448 }
mjr 29:582472d0bc57 1449
mjr 29:582472d0bc57 1450 // Update the physical outputs connected to the LedWiz ports. This is
mjr 29:582472d0bc57 1451 // called after any update from an LedWiz protocol message.
mjr 1:d913e0afb2ac 1452 static void updateWizOuts()
mjr 1:d913e0afb2ac 1453 {
mjr 29:582472d0bc57 1454 // update each output
mjr 29:582472d0bc57 1455 int pulse = false;
mjr 35:e959ffba78fd 1456 for (int i = 0 ; i < numLwOutputs ; ++i)
mjr 29:582472d0bc57 1457 {
mjr 29:582472d0bc57 1458 pulse |= (wizVal[i] >= 129 && wizVal[i] <= 132);
mjr 40:cc0d9814522b 1459 lwPin[i]->set(wizState(i));
mjr 29:582472d0bc57 1460 }
mjr 29:582472d0bc57 1461
mjr 29:582472d0bc57 1462 // if any outputs are set to flashing mode, and the pulse timer
mjr 29:582472d0bc57 1463 // isn't running, turn it on
mjr 29:582472d0bc57 1464 if (pulse)
mjr 29:582472d0bc57 1465 wizPulseTimer.attach(wizPulse, WIZ_PULSE_TIME_BASE);
mjr 34:6b981a2afab7 1466
mjr 34:6b981a2afab7 1467 // flush changes to 74HC595 chips, if attached
mjr 35:e959ffba78fd 1468 if (hc595 != 0)
mjr 35:e959ffba78fd 1469 hc595->update();
mjr 1:d913e0afb2ac 1470 }
mjr 38:091e511ce8a0 1471
mjr 38:091e511ce8a0 1472 // Update all physical outputs. This is called after a change to a global
mjr 38:091e511ce8a0 1473 // setting that affects all outputs, such as engaging or canceling Night Mode.
mjr 38:091e511ce8a0 1474 static void updateAllOuts()
mjr 38:091e511ce8a0 1475 {
mjr 38:091e511ce8a0 1476 // uddate each LedWiz output
mjr 38:091e511ce8a0 1477 for (int i = 0 ; i < numLwOutputs ; ++i)
mjr 40:cc0d9814522b 1478 lwPin[i]->set(wizState(i));
mjr 34:6b981a2afab7 1479
mjr 38:091e511ce8a0 1480 // update each extended output
mjr 63:5cd1a5f3a41b 1481 for (int i = numLwOutputs ; i < numOutputs ; ++i)
mjr 40:cc0d9814522b 1482 lwPin[i]->set(outLevel[i]);
mjr 38:091e511ce8a0 1483
mjr 38:091e511ce8a0 1484 // flush 74HC595 changes, if necessary
mjr 38:091e511ce8a0 1485 if (hc595 != 0)
mjr 38:091e511ce8a0 1486 hc595->update();
mjr 38:091e511ce8a0 1487 }
mjr 38:091e511ce8a0 1488
mjr 11:bd9da7088e6e 1489 // ---------------------------------------------------------------------------
mjr 11:bd9da7088e6e 1490 //
mjr 11:bd9da7088e6e 1491 // Button input
mjr 11:bd9da7088e6e 1492 //
mjr 11:bd9da7088e6e 1493
mjr 18:5e890ebd0023 1494 // button state
mjr 18:5e890ebd0023 1495 struct ButtonState
mjr 18:5e890ebd0023 1496 {
mjr 38:091e511ce8a0 1497 ButtonState()
mjr 38:091e511ce8a0 1498 {
mjr 38:091e511ce8a0 1499 di = NULL;
mjr 53:9b2611964afc 1500 physState = logState = prevLogState = 0;
mjr 53:9b2611964afc 1501 virtState = 0;
mjr 53:9b2611964afc 1502 dbState = 0;
mjr 38:091e511ce8a0 1503 pulseState = 0;
mjr 53:9b2611964afc 1504 pulseTime = 0;
mjr 38:091e511ce8a0 1505 }
mjr 35:e959ffba78fd 1506
mjr 53:9b2611964afc 1507 // "Virtually" press or un-press the button. This can be used to
mjr 53:9b2611964afc 1508 // control the button state via a software (virtual) source, such as
mjr 53:9b2611964afc 1509 // the ZB Launch Ball feature.
mjr 53:9b2611964afc 1510 //
mjr 53:9b2611964afc 1511 // To allow sharing of one button by multiple virtual sources, each
mjr 53:9b2611964afc 1512 // virtual source must keep track of its own state internally, and
mjr 53:9b2611964afc 1513 // only call this routine to CHANGE the state. This is because calls
mjr 53:9b2611964afc 1514 // to this routine are additive: turning the button ON twice will
mjr 53:9b2611964afc 1515 // require turning it OFF twice before it actually turns off.
mjr 53:9b2611964afc 1516 void virtPress(bool on)
mjr 53:9b2611964afc 1517 {
mjr 53:9b2611964afc 1518 // Increment or decrement the current state
mjr 53:9b2611964afc 1519 virtState += on ? 1 : -1;
mjr 53:9b2611964afc 1520 }
mjr 53:9b2611964afc 1521
mjr 53:9b2611964afc 1522 // DigitalIn for the button, if connected to a physical input
mjr 48:058ace2aed1d 1523 TinyDigitalIn *di;
mjr 38:091e511ce8a0 1524
mjr 65:739875521aae 1525 // Time of last pulse state transition.
mjr 65:739875521aae 1526 //
mjr 65:739875521aae 1527 // Each state change sticks for a minimum period; when the timer expires,
mjr 65:739875521aae 1528 // if the underlying physical switch is in a different state, we switch
mjr 65:739875521aae 1529 // to the next state and restart the timer. pulseTime is the time remaining
mjr 65:739875521aae 1530 // remaining before we can make another state transition, in microseconds.
mjr 65:739875521aae 1531 // The state transitions require a complete cycle, 1 -> 2 -> 3 -> 4 -> 1...;
mjr 65:739875521aae 1532 // this guarantees that the parity of the pulse count always matches the
mjr 65:739875521aae 1533 // current physical switch state when the latter is stable, which makes
mjr 65:739875521aae 1534 // it impossible to "trick" the host by rapidly toggling the switch state.
mjr 65:739875521aae 1535 // (On my original Pinscape cabinet, I had a hardware pulse generator
mjr 65:739875521aae 1536 // for coin door, and that *was* possible to trick by rapid toggling.
mjr 65:739875521aae 1537 // This software system can't be fooled that way.)
mjr 65:739875521aae 1538 uint32_t pulseTime;
mjr 18:5e890ebd0023 1539
mjr 65:739875521aae 1540 // Config key index. This points to the ButtonCfg structure in the
mjr 65:739875521aae 1541 // configuration that contains the PC key mapping for the button.
mjr 65:739875521aae 1542 uint8_t cfgIndex;
mjr 53:9b2611964afc 1543
mjr 53:9b2611964afc 1544 // Virtual press state. This is used to simulate pressing the button via
mjr 53:9b2611964afc 1545 // software inputs rather than physical inputs. To allow one button to be
mjr 53:9b2611964afc 1546 // controlled by mulitple software sources, each source should keep track
mjr 53:9b2611964afc 1547 // of its own virtual state for the button independently, and then INCREMENT
mjr 53:9b2611964afc 1548 // this variable when the source's state transitions from off to on, and
mjr 53:9b2611964afc 1549 // DECREMENT it when the source's state transitions from on to off. That
mjr 53:9b2611964afc 1550 // will make the button's pressed state the logical OR of all of the virtual
mjr 53:9b2611964afc 1551 // and physical source states.
mjr 53:9b2611964afc 1552 uint8_t virtState;
mjr 38:091e511ce8a0 1553
mjr 38:091e511ce8a0 1554 // Debounce history. On each scan, we shift in a 1 bit to the lsb if
mjr 38:091e511ce8a0 1555 // the physical key is reporting ON, and shift in a 0 bit if the physical
mjr 38:091e511ce8a0 1556 // key is reporting OFF. We consider the key to have a new stable state
mjr 38:091e511ce8a0 1557 // if we have N consecutive 0's or 1's in the low N bits (where N is
mjr 38:091e511ce8a0 1558 // a parameter that determines how long we wait for transients to settle).
mjr 53:9b2611964afc 1559 uint8_t dbState;
mjr 38:091e511ce8a0 1560
mjr 65:739875521aae 1561 // current PHYSICAL on/off state, after debouncing
mjr 65:739875521aae 1562 uint8_t physState : 1;
mjr 65:739875521aae 1563
mjr 65:739875521aae 1564 // current LOGICAL on/off state as reported to the host.
mjr 65:739875521aae 1565 uint8_t logState : 1;
mjr 65:739875521aae 1566
mjr 65:739875521aae 1567 // previous logical on/off state, when keys were last processed for USB
mjr 65:739875521aae 1568 // reports and local effects
mjr 65:739875521aae 1569 uint8_t prevLogState : 1;
mjr 65:739875521aae 1570
mjr 65:739875521aae 1571 // Pulse state
mjr 65:739875521aae 1572 //
mjr 65:739875521aae 1573 // A button in pulse mode (selected via the config flags for the button)
mjr 65:739875521aae 1574 // transmits a brief logical button press and release each time the attached
mjr 65:739875521aae 1575 // physical switch changes state. This is useful for cases where the host
mjr 65:739875521aae 1576 // expects a key press for each change in the state of the physical switch.
mjr 65:739875521aae 1577 // The canonical example is the Coin Door switch in VPinMAME, which requires
mjr 65:739875521aae 1578 // pressing the END key to toggle the open/closed state. This software design
mjr 65:739875521aae 1579 // isn't easily implemented in a physical coin door, though; the simplest
mjr 65:739875521aae 1580 // physical sensor for the coin door state is a switch that's on when the
mjr 65:739875521aae 1581 // door is open and off when the door is closed (or vice versa, but in either
mjr 65:739875521aae 1582 // case, the switch state corresponds to the current state of the door at any
mjr 65:739875521aae 1583 // given time, rather than pulsing on state changes). The "pulse mode"
mjr 65:739875521aae 1584 // option brdiges this gap by generating a toggle key event each time
mjr 65:739875521aae 1585 // there's a change to the physical switch's state.
mjr 38:091e511ce8a0 1586 //
mjr 38:091e511ce8a0 1587 // Pulse state:
mjr 38:091e511ce8a0 1588 // 0 -> not a pulse switch - logical key state equals physical switch state
mjr 38:091e511ce8a0 1589 // 1 -> off
mjr 38:091e511ce8a0 1590 // 2 -> transitioning off-on
mjr 38:091e511ce8a0 1591 // 3 -> on
mjr 38:091e511ce8a0 1592 // 4 -> transitioning on-off
mjr 65:739875521aae 1593 uint8_t pulseState : 3; // 5 states -> we need 3 bits
mjr 65:739875521aae 1594
mjr 65:739875521aae 1595 } __attribute__((packed));
mjr 65:739875521aae 1596
mjr 65:739875521aae 1597 ButtonState *buttonState; // live button slots, allocated on startup
mjr 65:739875521aae 1598 int8_t nButtons; // number of live button slots allocated
mjr 65:739875521aae 1599 int8_t zblButtonIndex = -1; // index of ZB Launch button slot; -1 if unused
mjr 18:5e890ebd0023 1600
mjr 66:2e3583fbd2f4 1601 // Shift button state
mjr 66:2e3583fbd2f4 1602 struct
mjr 66:2e3583fbd2f4 1603 {
mjr 66:2e3583fbd2f4 1604 int8_t index; // buttonState[] index of shift button; -1 if none
mjr 66:2e3583fbd2f4 1605 uint8_t state : 2; // current shift state:
mjr 66:2e3583fbd2f4 1606 // 0 = not shifted
mjr 66:2e3583fbd2f4 1607 // 1 = shift button down, no key pressed yet
mjr 66:2e3583fbd2f4 1608 // 2 = shift button down, key pressed
mjr 66:2e3583fbd2f4 1609 uint8_t pulse : 1; // sending pulsed keystroke on release
mjr 66:2e3583fbd2f4 1610 uint32_t pulseTime; // time of start of pulsed keystroke
mjr 66:2e3583fbd2f4 1611 }
mjr 66:2e3583fbd2f4 1612 __attribute__((packed)) shiftButton;
mjr 38:091e511ce8a0 1613
mjr 38:091e511ce8a0 1614 // Button data
mjr 38:091e511ce8a0 1615 uint32_t jsButtons = 0;
mjr 38:091e511ce8a0 1616
mjr 38:091e511ce8a0 1617 // Keyboard report state. This tracks the USB keyboard state. We can
mjr 38:091e511ce8a0 1618 // report at most 6 simultaneous non-modifier keys here, plus the 8
mjr 38:091e511ce8a0 1619 // modifier keys.
mjr 38:091e511ce8a0 1620 struct
mjr 38:091e511ce8a0 1621 {
mjr 38:091e511ce8a0 1622 bool changed; // flag: changed since last report sent
mjr 48:058ace2aed1d 1623 uint8_t nkeys; // number of active keys in the list
mjr 38:091e511ce8a0 1624 uint8_t data[8]; // key state, in USB report format: byte 0 is the modifier key mask,
mjr 38:091e511ce8a0 1625 // byte 1 is reserved, and bytes 2-7 are the currently pressed key codes
mjr 38:091e511ce8a0 1626 } kbState = { false, 0, { 0, 0, 0, 0, 0, 0, 0, 0 } };
mjr 38:091e511ce8a0 1627
mjr 38:091e511ce8a0 1628 // Media key state
mjr 38:091e511ce8a0 1629 struct
mjr 38:091e511ce8a0 1630 {
mjr 38:091e511ce8a0 1631 bool changed; // flag: changed since last report sent
mjr 38:091e511ce8a0 1632 uint8_t data; // key state byte for USB reports
mjr 38:091e511ce8a0 1633 } mediaState = { false, 0 };
mjr 38:091e511ce8a0 1634
mjr 38:091e511ce8a0 1635 // button scan interrupt ticker
mjr 38:091e511ce8a0 1636 Ticker buttonTicker;
mjr 38:091e511ce8a0 1637
mjr 38:091e511ce8a0 1638 // Button scan interrupt handler. We call this periodically via
mjr 38:091e511ce8a0 1639 // a timer interrupt to scan the physical button states.
mjr 38:091e511ce8a0 1640 void scanButtons()
mjr 38:091e511ce8a0 1641 {
mjr 38:091e511ce8a0 1642 // scan all button input pins
mjr 38:091e511ce8a0 1643 ButtonState *bs = buttonState;
mjr 65:739875521aae 1644 for (int i = 0 ; i < nButtons ; ++i, ++bs)
mjr 38:091e511ce8a0 1645 {
mjr 53:9b2611964afc 1646 // if this logical button is connected to a physical input, check
mjr 53:9b2611964afc 1647 // the GPIO pin state
mjr 38:091e511ce8a0 1648 if (bs->di != NULL)
mjr 38:091e511ce8a0 1649 {
mjr 38:091e511ce8a0 1650 // Shift the new state into the debounce history. Note that
mjr 38:091e511ce8a0 1651 // the physical pin inputs are active low (0V/GND = ON), so invert
mjr 38:091e511ce8a0 1652 // the reading by XOR'ing the low bit with 1. And of course we
mjr 38:091e511ce8a0 1653 // only want the low bit (since the history is effectively a bit
mjr 38:091e511ce8a0 1654 // vector), so mask the whole thing with 0x01 as well.
mjr 53:9b2611964afc 1655 uint8_t db = bs->dbState;
mjr 38:091e511ce8a0 1656 db <<= 1;
mjr 38:091e511ce8a0 1657 db |= (bs->di->read() & 0x01) ^ 0x01;
mjr 53:9b2611964afc 1658 bs->dbState = db;
mjr 38:091e511ce8a0 1659
mjr 38:091e511ce8a0 1660 // if we have all 0's or 1's in the history for the required
mjr 38:091e511ce8a0 1661 // debounce period, the key state is stable - check for a change
mjr 38:091e511ce8a0 1662 // to the last stable state
mjr 38:091e511ce8a0 1663 const uint8_t stable = 0x1F; // 00011111b -> 5 stable readings
mjr 38:091e511ce8a0 1664 db &= stable;
mjr 38:091e511ce8a0 1665 if (db == 0 || db == stable)
mjr 53:9b2611964afc 1666 bs->physState = db & 1;
mjr 38:091e511ce8a0 1667 }
mjr 38:091e511ce8a0 1668 }
mjr 38:091e511ce8a0 1669 }
mjr 38:091e511ce8a0 1670
mjr 38:091e511ce8a0 1671 // Button state transition timer. This is used for pulse buttons, to
mjr 38:091e511ce8a0 1672 // control the timing of the logical key presses generated by transitions
mjr 38:091e511ce8a0 1673 // in the physical button state.
mjr 38:091e511ce8a0 1674 Timer buttonTimer;
mjr 12:669df364a565 1675
mjr 65:739875521aae 1676 // Count a button during the initial setup scan
mjr 72:884207c0aab0 1677 void countButton(uint8_t typ, uint8_t shiftTyp, bool &kbKeys)
mjr 65:739875521aae 1678 {
mjr 65:739875521aae 1679 // count it
mjr 65:739875521aae 1680 ++nButtons;
mjr 65:739875521aae 1681
mjr 67:c39e66c4e000 1682 // if it's a keyboard key or media key, note that we need a USB
mjr 67:c39e66c4e000 1683 // keyboard interface
mjr 72:884207c0aab0 1684 if (typ == BtnTypeKey || typ == BtnTypeMedia
mjr 72:884207c0aab0 1685 || shiftTyp == BtnTypeKey || shiftTyp == BtnTypeMedia)
mjr 65:739875521aae 1686 kbKeys = true;
mjr 65:739875521aae 1687 }
mjr 65:739875521aae 1688
mjr 11:bd9da7088e6e 1689 // initialize the button inputs
mjr 35:e959ffba78fd 1690 void initButtons(Config &cfg, bool &kbKeys)
mjr 11:bd9da7088e6e 1691 {
mjr 35:e959ffba78fd 1692 // presume we'll find no keyboard keys
mjr 35:e959ffba78fd 1693 kbKeys = false;
mjr 35:e959ffba78fd 1694
mjr 66:2e3583fbd2f4 1695 // presume no shift key
mjr 66:2e3583fbd2f4 1696 shiftButton.index = -1;
mjr 66:2e3583fbd2f4 1697
mjr 65:739875521aae 1698 // Count up how many button slots we'll need to allocate. Start
mjr 65:739875521aae 1699 // with assigned buttons from the configuration, noting that we
mjr 65:739875521aae 1700 // only need to create slots for buttons that are actually wired.
mjr 65:739875521aae 1701 nButtons = 0;
mjr 65:739875521aae 1702 for (int i = 0 ; i < MAX_BUTTONS ; ++i)
mjr 65:739875521aae 1703 {
mjr 65:739875521aae 1704 // it's valid if it's wired to a real input pin
mjr 65:739875521aae 1705 if (wirePinName(cfg.button[i].pin) != NC)
mjr 72:884207c0aab0 1706 countButton(cfg.button[i].typ, cfg.button[i].typ2, kbKeys);
mjr 65:739875521aae 1707 }
mjr 65:739875521aae 1708
mjr 65:739875521aae 1709 // Count virtual buttons
mjr 65:739875521aae 1710
mjr 65:739875521aae 1711 // ZB Launch
mjr 65:739875521aae 1712 if (cfg.plunger.zbLaunchBall.port != 0)
mjr 65:739875521aae 1713 {
mjr 65:739875521aae 1714 // valid - remember the live button index
mjr 65:739875521aae 1715 zblButtonIndex = nButtons;
mjr 65:739875521aae 1716
mjr 65:739875521aae 1717 // count it
mjr 72:884207c0aab0 1718 countButton(cfg.plunger.zbLaunchBall.keytype, BtnTypeNone, kbKeys);
mjr 65:739875521aae 1719 }
mjr 65:739875521aae 1720
mjr 65:739875521aae 1721 // Allocate the live button slots
mjr 65:739875521aae 1722 ButtonState *bs = buttonState = new ButtonState[nButtons];
mjr 65:739875521aae 1723
mjr 65:739875521aae 1724 // Configure the physical inputs
mjr 65:739875521aae 1725 for (int i = 0 ; i < MAX_BUTTONS ; ++i)
mjr 65:739875521aae 1726 {
mjr 65:739875521aae 1727 PinName pin = wirePinName(cfg.button[i].pin);
mjr 65:739875521aae 1728 if (pin != NC)
mjr 65:739875521aae 1729 {
mjr 65:739875521aae 1730 // point back to the config slot for the keyboard data
mjr 65:739875521aae 1731 bs->cfgIndex = i;
mjr 65:739875521aae 1732
mjr 65:739875521aae 1733 // set up the GPIO input pin for this button
mjr 65:739875521aae 1734 bs->di = new TinyDigitalIn(pin);
mjr 65:739875521aae 1735
mjr 65:739875521aae 1736 // if it's a pulse mode button, set the initial pulse state to Off
mjr 65:739875521aae 1737 if (cfg.button[i].flags & BtnFlagPulse)
mjr 65:739875521aae 1738 bs->pulseState = 1;
mjr 65:739875521aae 1739
mjr 66:2e3583fbd2f4 1740 // If this is the shift button, note its buttonState[] index.
mjr 66:2e3583fbd2f4 1741 // We have to figure the buttonState[] index separately from
mjr 66:2e3583fbd2f4 1742 // the config index, because the indices can differ if some
mjr 66:2e3583fbd2f4 1743 // config slots are left unused.
mjr 66:2e3583fbd2f4 1744 if (cfg.shiftButton == i+1)
mjr 66:2e3583fbd2f4 1745 shiftButton.index = bs - buttonState;
mjr 66:2e3583fbd2f4 1746
mjr 65:739875521aae 1747 // advance to the next button
mjr 65:739875521aae 1748 ++bs;
mjr 65:739875521aae 1749 }
mjr 65:739875521aae 1750 }
mjr 65:739875521aae 1751
mjr 53:9b2611964afc 1752 // Configure the virtual buttons. These are buttons controlled via
mjr 53:9b2611964afc 1753 // software triggers rather than physical GPIO inputs. The virtual
mjr 53:9b2611964afc 1754 // buttons have the same control structures as regular buttons, but
mjr 53:9b2611964afc 1755 // they get their configuration data from other config variables.
mjr 53:9b2611964afc 1756
mjr 53:9b2611964afc 1757 // ZB Launch Ball button
mjr 65:739875521aae 1758 if (cfg.plunger.zbLaunchBall.port != 0)
mjr 11:bd9da7088e6e 1759 {
mjr 65:739875521aae 1760 // Point back to the config slot for the keyboard data.
mjr 66:2e3583fbd2f4 1761 // We use a special extra slot for virtual buttons,
mjr 66:2e3583fbd2f4 1762 // so we also need to set up the slot data by copying
mjr 66:2e3583fbd2f4 1763 // the ZBL config data to our virtual button slot.
mjr 65:739875521aae 1764 bs->cfgIndex = ZBL_BUTTON_CFG;
mjr 65:739875521aae 1765 cfg.button[ZBL_BUTTON_CFG].pin = PINNAME_TO_WIRE(NC);
mjr 65:739875521aae 1766 cfg.button[ZBL_BUTTON_CFG].typ = cfg.plunger.zbLaunchBall.keytype;
mjr 65:739875521aae 1767 cfg.button[ZBL_BUTTON_CFG].val = cfg.plunger.zbLaunchBall.keycode;
mjr 65:739875521aae 1768
mjr 66:2e3583fbd2f4 1769 // advance to the next button
mjr 65:739875521aae 1770 ++bs;
mjr 11:bd9da7088e6e 1771 }
mjr 12:669df364a565 1772
mjr 38:091e511ce8a0 1773 // start the button scan thread
mjr 38:091e511ce8a0 1774 buttonTicker.attach_us(scanButtons, 1000);
mjr 38:091e511ce8a0 1775
mjr 38:091e511ce8a0 1776 // start the button state transition timer
mjr 12:669df364a565 1777 buttonTimer.start();
mjr 11:bd9da7088e6e 1778 }
mjr 11:bd9da7088e6e 1779
mjr 67:c39e66c4e000 1780 // Media key mapping. This maps from an 8-bit USB media key
mjr 67:c39e66c4e000 1781 // code to the corresponding bit in our USB report descriptor.
mjr 67:c39e66c4e000 1782 // The USB key code is the index, and the value at the index
mjr 67:c39e66c4e000 1783 // is the report descriptor bit. See joystick.cpp for the
mjr 67:c39e66c4e000 1784 // media descriptor details. Our currently mapped keys are:
mjr 67:c39e66c4e000 1785 //
mjr 67:c39e66c4e000 1786 // 0xE2 -> Mute -> 0x01
mjr 67:c39e66c4e000 1787 // 0xE9 -> Volume Up -> 0x02
mjr 67:c39e66c4e000 1788 // 0xEA -> Volume Down -> 0x04
mjr 67:c39e66c4e000 1789 // 0xB5 -> Next Track -> 0x08
mjr 67:c39e66c4e000 1790 // 0xB6 -> Previous Track -> 0x10
mjr 67:c39e66c4e000 1791 // 0xB7 -> Stop -> 0x20
mjr 67:c39e66c4e000 1792 // 0xCD -> Play / Pause -> 0x40
mjr 67:c39e66c4e000 1793 //
mjr 67:c39e66c4e000 1794 static const uint8_t mediaKeyMap[] = {
mjr 67:c39e66c4e000 1795 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 00-0F
mjr 67:c39e66c4e000 1796 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 10-1F
mjr 67:c39e66c4e000 1797 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 20-2F
mjr 67:c39e66c4e000 1798 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 30-3F
mjr 67:c39e66c4e000 1799 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 40-4F
mjr 67:c39e66c4e000 1800 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 50-5F
mjr 67:c39e66c4e000 1801 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 60-6F
mjr 67:c39e66c4e000 1802 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 70-7F
mjr 67:c39e66c4e000 1803 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 80-8F
mjr 67:c39e66c4e000 1804 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 90-9F
mjr 67:c39e66c4e000 1805 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // A0-AF
mjr 67:c39e66c4e000 1806 0, 0, 0, 0, 0, 8, 16, 32, 0, 0, 0, 0, 0, 0, 0, 0, // B0-BF
mjr 67:c39e66c4e000 1807 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 64, 0, 0, // C0-CF
mjr 67:c39e66c4e000 1808 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // D0-DF
mjr 67:c39e66c4e000 1809 0, 0, 1, 0, 0, 0, 0, 0, 0, 2, 4, 0, 0, 0, 0, 0, // E0-EF
mjr 67:c39e66c4e000 1810 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 // F0-FF
mjr 67:c39e66c4e000 1811 };
mjr 67:c39e66c4e000 1812
mjr 67:c39e66c4e000 1813
mjr 38:091e511ce8a0 1814 // Process the button state. This sets up the joystick, keyboard, and
mjr 38:091e511ce8a0 1815 // media control descriptors with the current state of keys mapped to
mjr 38:091e511ce8a0 1816 // those HID interfaces, and executes the local effects for any keys
mjr 38:091e511ce8a0 1817 // mapped to special device functions (e.g., Night Mode).
mjr 53:9b2611964afc 1818 void processButtons(Config &cfg)
mjr 35:e959ffba78fd 1819 {
mjr 35:e959ffba78fd 1820 // start with an empty list of USB key codes
mjr 35:e959ffba78fd 1821 uint8_t modkeys = 0;
mjr 35:e959ffba78fd 1822 uint8_t keys[7] = { 0, 0, 0, 0, 0, 0, 0 };
mjr 35:e959ffba78fd 1823 int nkeys = 0;
mjr 11:bd9da7088e6e 1824
mjr 35:e959ffba78fd 1825 // clear the joystick buttons
mjr 36:b9747461331e 1826 uint32_t newjs = 0;
mjr 35:e959ffba78fd 1827
mjr 35:e959ffba78fd 1828 // start with no media keys pressed
mjr 35:e959ffba78fd 1829 uint8_t mediakeys = 0;
mjr 38:091e511ce8a0 1830
mjr 38:091e511ce8a0 1831 // calculate the time since the last run
mjr 53:9b2611964afc 1832 uint32_t dt = buttonTimer.read_us();
mjr 18:5e890ebd0023 1833 buttonTimer.reset();
mjr 66:2e3583fbd2f4 1834
mjr 66:2e3583fbd2f4 1835 // check the shift button state
mjr 66:2e3583fbd2f4 1836 if (shiftButton.index != -1)
mjr 66:2e3583fbd2f4 1837 {
mjr 66:2e3583fbd2f4 1838 ButtonState *sbs = &buttonState[shiftButton.index];
mjr 66:2e3583fbd2f4 1839 switch (shiftButton.state)
mjr 66:2e3583fbd2f4 1840 {
mjr 66:2e3583fbd2f4 1841 case 0:
mjr 66:2e3583fbd2f4 1842 // Not shifted. Check if the button is now down: if so,
mjr 66:2e3583fbd2f4 1843 // switch to state 1 (shift button down, no key pressed yet).
mjr 66:2e3583fbd2f4 1844 if (sbs->physState)
mjr 66:2e3583fbd2f4 1845 shiftButton.state = 1;
mjr 66:2e3583fbd2f4 1846 break;
mjr 66:2e3583fbd2f4 1847
mjr 66:2e3583fbd2f4 1848 case 1:
mjr 66:2e3583fbd2f4 1849 // Shift button down, no key pressed yet. If the button is
mjr 66:2e3583fbd2f4 1850 // now up, it counts as an ordinary button press instead of
mjr 66:2e3583fbd2f4 1851 // a shift button press, since the shift function was never
mjr 66:2e3583fbd2f4 1852 // used. Return to unshifted state and start a timed key
mjr 66:2e3583fbd2f4 1853 // pulse event.
mjr 66:2e3583fbd2f4 1854 if (!sbs->physState)
mjr 66:2e3583fbd2f4 1855 {
mjr 66:2e3583fbd2f4 1856 shiftButton.state = 0;
mjr 66:2e3583fbd2f4 1857 shiftButton.pulse = 1;
mjr 66:2e3583fbd2f4 1858 shiftButton.pulseTime = 50000+dt; // 50 ms left on the key pulse
mjr 66:2e3583fbd2f4 1859 }
mjr 66:2e3583fbd2f4 1860 break;
mjr 66:2e3583fbd2f4 1861
mjr 66:2e3583fbd2f4 1862 case 2:
mjr 66:2e3583fbd2f4 1863 // Shift button down, other key was pressed. If the button is
mjr 66:2e3583fbd2f4 1864 // now up, simply clear the shift state without sending a key
mjr 66:2e3583fbd2f4 1865 // press for the shift button itself to the PC. The shift
mjr 66:2e3583fbd2f4 1866 // function was used, so its ordinary key press function is
mjr 66:2e3583fbd2f4 1867 // suppressed.
mjr 66:2e3583fbd2f4 1868 if (!sbs->physState)
mjr 66:2e3583fbd2f4 1869 shiftButton.state = 0;
mjr 66:2e3583fbd2f4 1870 break;
mjr 66:2e3583fbd2f4 1871 }
mjr 66:2e3583fbd2f4 1872 }
mjr 38:091e511ce8a0 1873
mjr 11:bd9da7088e6e 1874 // scan the button list
mjr 18:5e890ebd0023 1875 ButtonState *bs = buttonState;
mjr 65:739875521aae 1876 for (int i = 0 ; i < nButtons ; ++i, ++bs)
mjr 11:bd9da7088e6e 1877 {
mjr 66:2e3583fbd2f4 1878 // Check the button type:
mjr 66:2e3583fbd2f4 1879 // - shift button
mjr 66:2e3583fbd2f4 1880 // - pulsed button
mjr 66:2e3583fbd2f4 1881 // - regular button
mjr 66:2e3583fbd2f4 1882 if (shiftButton.index == i)
mjr 66:2e3583fbd2f4 1883 {
mjr 66:2e3583fbd2f4 1884 // This is the shift button. Its logical state for key
mjr 66:2e3583fbd2f4 1885 // reporting purposes is controlled by the shift buttton
mjr 66:2e3583fbd2f4 1886 // pulse timer. If we're in a pulse, its logical state
mjr 66:2e3583fbd2f4 1887 // is pressed.
mjr 66:2e3583fbd2f4 1888 if (shiftButton.pulse)
mjr 66:2e3583fbd2f4 1889 {
mjr 66:2e3583fbd2f4 1890 // deduct the current interval from the pulse time, ending
mjr 66:2e3583fbd2f4 1891 // the pulse if the time has expired
mjr 66:2e3583fbd2f4 1892 if (shiftButton.pulseTime > dt)
mjr 66:2e3583fbd2f4 1893 shiftButton.pulseTime -= dt;
mjr 66:2e3583fbd2f4 1894 else
mjr 66:2e3583fbd2f4 1895 shiftButton.pulse = 0;
mjr 66:2e3583fbd2f4 1896 }
mjr 66:2e3583fbd2f4 1897
mjr 66:2e3583fbd2f4 1898 // the button is logically pressed if we're in a pulse
mjr 66:2e3583fbd2f4 1899 bs->logState = shiftButton.pulse;
mjr 66:2e3583fbd2f4 1900 }
mjr 66:2e3583fbd2f4 1901 else if (bs->pulseState != 0)
mjr 18:5e890ebd0023 1902 {
mjr 38:091e511ce8a0 1903 // if the timer has expired, check for state changes
mjr 53:9b2611964afc 1904 if (bs->pulseTime > dt)
mjr 18:5e890ebd0023 1905 {
mjr 53:9b2611964afc 1906 // not expired yet - deduct the last interval
mjr 53:9b2611964afc 1907 bs->pulseTime -= dt;
mjr 53:9b2611964afc 1908 }
mjr 53:9b2611964afc 1909 else
mjr 53:9b2611964afc 1910 {
mjr 53:9b2611964afc 1911 // pulse time expired - check for a state change
mjr 53:9b2611964afc 1912 const uint32_t pulseLength = 200000UL; // 200 milliseconds
mjr 38:091e511ce8a0 1913 switch (bs->pulseState)
mjr 18:5e890ebd0023 1914 {
mjr 38:091e511ce8a0 1915 case 1:
mjr 38:091e511ce8a0 1916 // off - if the physical switch is now on, start a button pulse
mjr 53:9b2611964afc 1917 if (bs->physState)
mjr 53:9b2611964afc 1918 {
mjr 38:091e511ce8a0 1919 bs->pulseTime = pulseLength;
mjr 38:091e511ce8a0 1920 bs->pulseState = 2;
mjr 53:9b2611964afc 1921 bs->logState = 1;
mjr 38:091e511ce8a0 1922 }
mjr 38:091e511ce8a0 1923 break;
mjr 18:5e890ebd0023 1924
mjr 38:091e511ce8a0 1925 case 2:
mjr 38:091e511ce8a0 1926 // transitioning off to on - end the pulse, and start a gap
mjr 38:091e511ce8a0 1927 // equal to the pulse time so that the host can observe the
mjr 38:091e511ce8a0 1928 // change in state in the logical button
mjr 38:091e511ce8a0 1929 bs->pulseState = 3;
mjr 38:091e511ce8a0 1930 bs->pulseTime = pulseLength;
mjr 53:9b2611964afc 1931 bs->logState = 0;
mjr 38:091e511ce8a0 1932 break;
mjr 38:091e511ce8a0 1933
mjr 38:091e511ce8a0 1934 case 3:
mjr 38:091e511ce8a0 1935 // on - if the physical switch is now off, start a button pulse
mjr 53:9b2611964afc 1936 if (!bs->physState)
mjr 53:9b2611964afc 1937 {
mjr 38:091e511ce8a0 1938 bs->pulseTime = pulseLength;
mjr 38:091e511ce8a0 1939 bs->pulseState = 4;
mjr 53:9b2611964afc 1940 bs->logState = 1;
mjr 38:091e511ce8a0 1941 }
mjr 38:091e511ce8a0 1942 break;
mjr 38:091e511ce8a0 1943
mjr 38:091e511ce8a0 1944 case 4:
mjr 38:091e511ce8a0 1945 // transitioning on to off - end the pulse, and start a gap
mjr 38:091e511ce8a0 1946 bs->pulseState = 1;
mjr 38:091e511ce8a0 1947 bs->pulseTime = pulseLength;
mjr 53:9b2611964afc 1948 bs->logState = 0;
mjr 38:091e511ce8a0 1949 break;
mjr 18:5e890ebd0023 1950 }
mjr 18:5e890ebd0023 1951 }
mjr 38:091e511ce8a0 1952 }
mjr 38:091e511ce8a0 1953 else
mjr 38:091e511ce8a0 1954 {
mjr 38:091e511ce8a0 1955 // not a pulse switch - the logical state is the same as the physical state
mjr 53:9b2611964afc 1956 bs->logState = bs->physState;
mjr 38:091e511ce8a0 1957 }
mjr 35:e959ffba78fd 1958
mjr 38:091e511ce8a0 1959 // carry out any edge effects from buttons changing states
mjr 53:9b2611964afc 1960 if (bs->logState != bs->prevLogState)
mjr 38:091e511ce8a0 1961 {
mjr 38:091e511ce8a0 1962 // check for special key transitions
mjr 53:9b2611964afc 1963 if (cfg.nightMode.btn == i + 1)
mjr 35:e959ffba78fd 1964 {
mjr 53:9b2611964afc 1965 // Check the switch type in the config flags. If flag 0x01 is set,
mjr 53:9b2611964afc 1966 // it's a persistent on/off switch, so the night mode state simply
mjr 53:9b2611964afc 1967 // follows the current state of the switch. Otherwise, it's a
mjr 53:9b2611964afc 1968 // momentary button, so each button push (i.e., each transition from
mjr 53:9b2611964afc 1969 // logical state OFF to ON) toggles the current night mode state.
mjr 53:9b2611964afc 1970 if (cfg.nightMode.flags & 0x01)
mjr 53:9b2611964afc 1971 {
mjr 69:cc5039284fac 1972 // on/off switch - when the button changes state, change
mjr 53:9b2611964afc 1973 // night mode to match the new state
mjr 53:9b2611964afc 1974 setNightMode(bs->logState);
mjr 53:9b2611964afc 1975 }
mjr 53:9b2611964afc 1976 else
mjr 53:9b2611964afc 1977 {
mjr 66:2e3583fbd2f4 1978 // Momentary switch - toggle the night mode state when the
mjr 53:9b2611964afc 1979 // physical button is pushed (i.e., when its logical state
mjr 66:2e3583fbd2f4 1980 // transitions from OFF to ON).
mjr 66:2e3583fbd2f4 1981 //
mjr 66:2e3583fbd2f4 1982 // In momentary mode, night mode flag 0x02 makes it the
mjr 66:2e3583fbd2f4 1983 // shifted version of the button. In this case, only
mjr 66:2e3583fbd2f4 1984 // proceed if the shift button is pressed.
mjr 66:2e3583fbd2f4 1985 bool pressed = bs->logState;
mjr 66:2e3583fbd2f4 1986 if ((cfg.nightMode.flags & 0x02) != 0)
mjr 66:2e3583fbd2f4 1987 {
mjr 66:2e3583fbd2f4 1988 // if the shift button is pressed but hasn't been used
mjr 66:2e3583fbd2f4 1989 // as a shift yet, mark it as used, so that it doesn't
mjr 66:2e3583fbd2f4 1990 // also generate its own key code on release
mjr 66:2e3583fbd2f4 1991 if (shiftButton.state == 1)
mjr 66:2e3583fbd2f4 1992 shiftButton.state = 2;
mjr 66:2e3583fbd2f4 1993
mjr 66:2e3583fbd2f4 1994 // if the shift button isn't even pressed
mjr 66:2e3583fbd2f4 1995 if (shiftButton.state == 0)
mjr 66:2e3583fbd2f4 1996 pressed = false;
mjr 66:2e3583fbd2f4 1997 }
mjr 66:2e3583fbd2f4 1998
mjr 66:2e3583fbd2f4 1999 // if it's pressed (even after considering the shift mode),
mjr 66:2e3583fbd2f4 2000 // toggle night mode
mjr 66:2e3583fbd2f4 2001 if (pressed)
mjr 53:9b2611964afc 2002 toggleNightMode();
mjr 53:9b2611964afc 2003 }
mjr 35:e959ffba78fd 2004 }
mjr 38:091e511ce8a0 2005
mjr 38:091e511ce8a0 2006 // remember the new state for comparison on the next run
mjr 53:9b2611964afc 2007 bs->prevLogState = bs->logState;
mjr 38:091e511ce8a0 2008 }
mjr 38:091e511ce8a0 2009
mjr 53:9b2611964afc 2010 // if it's pressed, physically or virtually, add it to the appropriate
mjr 53:9b2611964afc 2011 // key state list
mjr 53:9b2611964afc 2012 if (bs->logState || bs->virtState)
mjr 38:091e511ce8a0 2013 {
mjr 70:9f58735a1732 2014 // Get the key type and code. Start by assuming that we're
mjr 70:9f58735a1732 2015 // going to use the normal unshifted meaning.
mjr 65:739875521aae 2016 ButtonCfg *bc = &cfg.button[bs->cfgIndex];
mjr 70:9f58735a1732 2017 uint8_t typ = bc->typ;
mjr 70:9f58735a1732 2018 uint8_t val = bc->val;
mjr 70:9f58735a1732 2019
mjr 70:9f58735a1732 2020 // If the shift button is down, check for a shifted meaning.
mjr 70:9f58735a1732 2021 if (shiftButton.state)
mjr 66:2e3583fbd2f4 2022 {
mjr 70:9f58735a1732 2023 // assume there's no shifted meaning
mjr 70:9f58735a1732 2024 bool useShift = false;
mjr 66:2e3583fbd2f4 2025
mjr 70:9f58735a1732 2026 // If the button has a shifted meaning, use that. The
mjr 70:9f58735a1732 2027 // meaning might be a keyboard key or joystick button,
mjr 70:9f58735a1732 2028 // but it could also be as the Night Mode toggle.
mjr 70:9f58735a1732 2029 //
mjr 70:9f58735a1732 2030 // The condition to check if it's the Night Mode toggle
mjr 70:9f58735a1732 2031 // is a little complicated. First, the easy part: our
mjr 70:9f58735a1732 2032 // button index has to match the Night Mode button index.
mjr 70:9f58735a1732 2033 // Now the hard part: the Night Mode button flags have
mjr 70:9f58735a1732 2034 // to be set to 0x01 OFF and 0x02 ON: toggle mode (not
mjr 70:9f58735a1732 2035 // switch mode, 0x01), and shift mode, 0x02. So AND the
mjr 70:9f58735a1732 2036 // flags with 0x03 to get these two bits, and check that
mjr 70:9f58735a1732 2037 // the result is 0x02, meaning that only shift mode is on.
mjr 70:9f58735a1732 2038 if (bc->typ2 != BtnTypeNone)
mjr 70:9f58735a1732 2039 {
mjr 70:9f58735a1732 2040 // there's a shifted key assignment - use it
mjr 70:9f58735a1732 2041 typ = bc->typ2;
mjr 70:9f58735a1732 2042 val = bc->val2;
mjr 70:9f58735a1732 2043 useShift = true;
mjr 70:9f58735a1732 2044 }
mjr 70:9f58735a1732 2045 else if (cfg.nightMode.btn == i+1
mjr 70:9f58735a1732 2046 && (cfg.nightMode.flags & 0x03) == 0x02)
mjr 70:9f58735a1732 2047 {
mjr 70:9f58735a1732 2048 // shift+button = night mode toggle
mjr 70:9f58735a1732 2049 typ = BtnTypeNone;
mjr 70:9f58735a1732 2050 val = 0;
mjr 70:9f58735a1732 2051 useShift = true;
mjr 70:9f58735a1732 2052 }
mjr 70:9f58735a1732 2053
mjr 70:9f58735a1732 2054 // If there's a shifted meaning, advance the shift
mjr 70:9f58735a1732 2055 // button state from 1 to 2 if applicable. This signals
mjr 70:9f58735a1732 2056 // that we've "consumed" the shift button press as the
mjr 70:9f58735a1732 2057 // shift button, so it shouldn't generate its own key
mjr 70:9f58735a1732 2058 // code event when released.
mjr 70:9f58735a1732 2059 if (useShift && shiftButton.state == 1)
mjr 66:2e3583fbd2f4 2060 shiftButton.state = 2;
mjr 66:2e3583fbd2f4 2061 }
mjr 66:2e3583fbd2f4 2062
mjr 70:9f58735a1732 2063 // We've decided on the meaning of the button, so process
mjr 70:9f58735a1732 2064 // the keyboard or joystick event.
mjr 66:2e3583fbd2f4 2065 switch (typ)
mjr 53:9b2611964afc 2066 {
mjr 53:9b2611964afc 2067 case BtnTypeJoystick:
mjr 53:9b2611964afc 2068 // joystick button
mjr 53:9b2611964afc 2069 newjs |= (1 << (val - 1));
mjr 53:9b2611964afc 2070 break;
mjr 53:9b2611964afc 2071
mjr 53:9b2611964afc 2072 case BtnTypeKey:
mjr 67:c39e66c4e000 2073 // Keyboard key. The USB keyboard report encodes regular
mjr 67:c39e66c4e000 2074 // keys and modifier keys separately, so we need to check
mjr 67:c39e66c4e000 2075 // which type we have. Note that past versions mapped the
mjr 67:c39e66c4e000 2076 // Keyboard Volume Up, Keyboard Volume Down, and Keyboard
mjr 67:c39e66c4e000 2077 // Mute keys to the corresponding Media keys. We no longer
mjr 67:c39e66c4e000 2078 // do this; instead, we have the separate BtnTypeMedia for
mjr 67:c39e66c4e000 2079 // explicitly using media keys if desired.
mjr 67:c39e66c4e000 2080 if (val >= 0xE0 && val <= 0xE7)
mjr 53:9b2611964afc 2081 {
mjr 67:c39e66c4e000 2082 // It's a modifier key. These are represented in the USB
mjr 67:c39e66c4e000 2083 // reports with a bit mask. We arrange the mask bits in
mjr 67:c39e66c4e000 2084 // the same order as the scan codes, so we can figure the
mjr 67:c39e66c4e000 2085 // appropriate bit with a simple shift.
mjr 53:9b2611964afc 2086 modkeys |= (1 << (val - 0xE0));
mjr 53:9b2611964afc 2087 }
mjr 53:9b2611964afc 2088 else
mjr 53:9b2611964afc 2089 {
mjr 67:c39e66c4e000 2090 // It's a regular key. Make sure it's not already in the
mjr 67:c39e66c4e000 2091 // list, and that the list isn't full. If neither of these
mjr 67:c39e66c4e000 2092 // apply, add the key to the key array.
mjr 53:9b2611964afc 2093 if (nkeys < 7)
mjr 53:9b2611964afc 2094 {
mjr 57:cc03231f676b 2095 bool found = false;
mjr 53:9b2611964afc 2096 for (int j = 0 ; j < nkeys ; ++j)
mjr 53:9b2611964afc 2097 {
mjr 53:9b2611964afc 2098 if (keys[j] == val)
mjr 53:9b2611964afc 2099 {
mjr 53:9b2611964afc 2100 found = true;
mjr 53:9b2611964afc 2101 break;
mjr 53:9b2611964afc 2102 }
mjr 53:9b2611964afc 2103 }
mjr 53:9b2611964afc 2104 if (!found)
mjr 53:9b2611964afc 2105 keys[nkeys++] = val;
mjr 53:9b2611964afc 2106 }
mjr 53:9b2611964afc 2107 }
mjr 53:9b2611964afc 2108 break;
mjr 67:c39e66c4e000 2109
mjr 67:c39e66c4e000 2110 case BtnTypeMedia:
mjr 67:c39e66c4e000 2111 // Media control key. The media keys are mapped in the USB
mjr 67:c39e66c4e000 2112 // report to bits, whereas the key codes are specified in the
mjr 67:c39e66c4e000 2113 // config with their USB usage numbers. E.g., the config val
mjr 67:c39e66c4e000 2114 // for Media Next Track is 0xB5, but we encode this in the USB
mjr 67:c39e66c4e000 2115 // report as bit 0x08. The mediaKeyMap[] table translates
mjr 67:c39e66c4e000 2116 // from the USB usage number to the mask bit. If the key isn't
mjr 67:c39e66c4e000 2117 // among the subset we support, the mapped bit will be zero, so
mjr 67:c39e66c4e000 2118 // the "|=" will have no effect and the key will be ignored.
mjr 67:c39e66c4e000 2119 mediakeys |= mediaKeyMap[val];
mjr 67:c39e66c4e000 2120 break;
mjr 53:9b2611964afc 2121 }
mjr 18:5e890ebd0023 2122 }
mjr 11:bd9da7088e6e 2123 }
mjr 36:b9747461331e 2124
mjr 36:b9747461331e 2125 // check for joystick button changes
mjr 36:b9747461331e 2126 if (jsButtons != newjs)
mjr 36:b9747461331e 2127 jsButtons = newjs;
mjr 11:bd9da7088e6e 2128
mjr 35:e959ffba78fd 2129 // Check for changes to the keyboard keys
mjr 35:e959ffba78fd 2130 if (kbState.data[0] != modkeys
mjr 35:e959ffba78fd 2131 || kbState.nkeys != nkeys
mjr 35:e959ffba78fd 2132 || memcmp(keys, &kbState.data[2], 6) != 0)
mjr 35:e959ffba78fd 2133 {
mjr 35:e959ffba78fd 2134 // we have changes - set the change flag and store the new key data
mjr 35:e959ffba78fd 2135 kbState.changed = true;
mjr 35:e959ffba78fd 2136 kbState.data[0] = modkeys;
mjr 35:e959ffba78fd 2137 if (nkeys <= 6) {
mjr 35:e959ffba78fd 2138 // 6 or fewer simultaneous keys - report the key codes
mjr 35:e959ffba78fd 2139 kbState.nkeys = nkeys;
mjr 35:e959ffba78fd 2140 memcpy(&kbState.data[2], keys, 6);
mjr 35:e959ffba78fd 2141 }
mjr 35:e959ffba78fd 2142 else {
mjr 35:e959ffba78fd 2143 // more than 6 simultaneous keys - report rollover (all '1' key codes)
mjr 35:e959ffba78fd 2144 kbState.nkeys = 6;
mjr 35:e959ffba78fd 2145 memset(&kbState.data[2], 1, 6);
mjr 35:e959ffba78fd 2146 }
mjr 35:e959ffba78fd 2147 }
mjr 35:e959ffba78fd 2148
mjr 35:e959ffba78fd 2149 // Check for changes to media keys
mjr 35:e959ffba78fd 2150 if (mediaState.data != mediakeys)
mjr 35:e959ffba78fd 2151 {
mjr 35:e959ffba78fd 2152 mediaState.changed = true;
mjr 35:e959ffba78fd 2153 mediaState.data = mediakeys;
mjr 35:e959ffba78fd 2154 }
mjr 11:bd9da7088e6e 2155 }
mjr 11:bd9da7088e6e 2156
mjr 5:a70c0bce770d 2157 // ---------------------------------------------------------------------------
mjr 5:a70c0bce770d 2158 //
mjr 5:a70c0bce770d 2159 // Customization joystick subbclass
mjr 5:a70c0bce770d 2160 //
mjr 5:a70c0bce770d 2161
mjr 5:a70c0bce770d 2162 class MyUSBJoystick: public USBJoystick
mjr 5:a70c0bce770d 2163 {
mjr 5:a70c0bce770d 2164 public:
mjr 35:e959ffba78fd 2165 MyUSBJoystick(uint16_t vendor_id, uint16_t product_id, uint16_t product_release,
mjr 35:e959ffba78fd 2166 bool waitForConnect, bool enableJoystick, bool useKB)
mjr 35:e959ffba78fd 2167 : USBJoystick(vendor_id, product_id, product_release, waitForConnect, enableJoystick, useKB)
mjr 5:a70c0bce770d 2168 {
mjr 54:fd77a6b2f76c 2169 sleeping_ = false;
mjr 54:fd77a6b2f76c 2170 reconnectPending_ = false;
mjr 54:fd77a6b2f76c 2171 timer_.start();
mjr 54:fd77a6b2f76c 2172 }
mjr 54:fd77a6b2f76c 2173
mjr 54:fd77a6b2f76c 2174 // show diagnostic LED feedback for connect state
mjr 54:fd77a6b2f76c 2175 void diagFlash()
mjr 54:fd77a6b2f76c 2176 {
mjr 54:fd77a6b2f76c 2177 if (!configured() || sleeping_)
mjr 54:fd77a6b2f76c 2178 {
mjr 54:fd77a6b2f76c 2179 // flash once if sleeping or twice if disconnected
mjr 54:fd77a6b2f76c 2180 for (int j = isConnected() ? 1 : 2 ; j > 0 ; --j)
mjr 54:fd77a6b2f76c 2181 {
mjr 54:fd77a6b2f76c 2182 // short red flash
mjr 54:fd77a6b2f76c 2183 diagLED(1, 0, 0);
mjr 54:fd77a6b2f76c 2184 wait_us(50000);
mjr 54:fd77a6b2f76c 2185 diagLED(0, 0, 0);
mjr 54:fd77a6b2f76c 2186 wait_us(50000);
mjr 54:fd77a6b2f76c 2187 }
mjr 54:fd77a6b2f76c 2188 }
mjr 5:a70c0bce770d 2189 }
mjr 5:a70c0bce770d 2190
mjr 5:a70c0bce770d 2191 // are we connected?
mjr 5:a70c0bce770d 2192 int isConnected() { return configured(); }
mjr 5:a70c0bce770d 2193
mjr 54:fd77a6b2f76c 2194 // Are we in sleep mode? If true, this means that the hardware has
mjr 54:fd77a6b2f76c 2195 // detected no activity on the bus for 3ms. This happens when the
mjr 54:fd77a6b2f76c 2196 // cable is physically disconnected, the computer is turned off, or
mjr 54:fd77a6b2f76c 2197 // the connection is otherwise disabled.
mjr 54:fd77a6b2f76c 2198 bool isSleeping() const { return sleeping_; }
mjr 54:fd77a6b2f76c 2199
mjr 54:fd77a6b2f76c 2200 // If necessary, attempt to recover from a broken connection.
mjr 54:fd77a6b2f76c 2201 //
mjr 54:fd77a6b2f76c 2202 // This is a hack, to work around an apparent timing bug in the
mjr 54:fd77a6b2f76c 2203 // KL25Z USB implementation that I haven't been able to solve any
mjr 54:fd77a6b2f76c 2204 // other way.
mjr 54:fd77a6b2f76c 2205 //
mjr 54:fd77a6b2f76c 2206 // The issue: when we have an established connection, and the
mjr 54:fd77a6b2f76c 2207 // connection is broken by physically unplugging the cable or by
mjr 54:fd77a6b2f76c 2208 // rebooting the PC, the KL25Z sometimes fails to reconnect when
mjr 54:fd77a6b2f76c 2209 // the physical connection is re-established. The failure is
mjr 54:fd77a6b2f76c 2210 // sporadic; I'd guess it happens about 25% of the time, but I
mjr 54:fd77a6b2f76c 2211 // haven't collected any real statistics on it.
mjr 54:fd77a6b2f76c 2212 //
mjr 54:fd77a6b2f76c 2213 // The proximate cause of the failure is a deadlock in the SETUP
mjr 54:fd77a6b2f76c 2214 // protocol between the host and device that happens around the
mjr 54:fd77a6b2f76c 2215 // point where the PC is requesting the configuration descriptor.
mjr 54:fd77a6b2f76c 2216 // The exact point in the protocol where this occurs varies slightly;
mjr 54:fd77a6b2f76c 2217 // it can occur a message or two before or after the Get Config
mjr 54:fd77a6b2f76c 2218 // Descriptor packet. No matter where it happens, the nature of
mjr 54:fd77a6b2f76c 2219 // the deadlock is the same: the PC thinks it sees a STALL on EP0
mjr 54:fd77a6b2f76c 2220 // from the device, so it terminates the connection attempt, which
mjr 54:fd77a6b2f76c 2221 // stops further traffic on the cable. The KL25Z USB hardware sees
mjr 54:fd77a6b2f76c 2222 // the lack of traffic and triggers a SLEEP interrupt (a misnomer
mjr 54:fd77a6b2f76c 2223 // for what should have been called a BROKEN CONNECTION interrupt).
mjr 54:fd77a6b2f76c 2224 // Both sides simply stop talking at this point, so the connection
mjr 54:fd77a6b2f76c 2225 // is effectively dead.
mjr 54:fd77a6b2f76c 2226 //
mjr 54:fd77a6b2f76c 2227 // The strange thing is that, as far as I can tell, the KL25Z isn't
mjr 54:fd77a6b2f76c 2228 // doing anything to trigger the STALL on its end. Both the PC
mjr 54:fd77a6b2f76c 2229 // and the KL25Z are happy up until the very point of the failure
mjr 54:fd77a6b2f76c 2230 // and show no signs of anything wrong in the protocol exchange.
mjr 54:fd77a6b2f76c 2231 // In fact, every detail of the protocol exchange up to this point
mjr 54:fd77a6b2f76c 2232 // is identical to every successful exchange that does finish the
mjr 54:fd77a6b2f76c 2233 // whole setup process successfully, on both the KL25Z and Windows
mjr 54:fd77a6b2f76c 2234 // sides of the connection. I can't find any point of difference
mjr 54:fd77a6b2f76c 2235 // between successful and unsuccessful sequences that suggests why
mjr 54:fd77a6b2f76c 2236 // the fateful message fails. This makes me suspect that whatever
mjr 54:fd77a6b2f76c 2237 // is going wrong is inside the KL25Z USB hardware module, which
mjr 54:fd77a6b2f76c 2238 // is a pretty substantial black box - it has a lot of internal
mjr 54:fd77a6b2f76c 2239 // state that's inaccessible to the software. Further bolstering
mjr 54:fd77a6b2f76c 2240 // this theory is a little experiment where I found that I could
mjr 54:fd77a6b2f76c 2241 // reproduce the exact sequence of events of a failed reconnect
mjr 54:fd77a6b2f76c 2242 // attempt in an *initial* connection, which is otherwise 100%
mjr 54:fd77a6b2f76c 2243 // reliable, by inserting a little bit of artifical time padding
mjr 54:fd77a6b2f76c 2244 // (200us per event) into the SETUP interrupt handler. My
mjr 54:fd77a6b2f76c 2245 // hypothesis is that the STALL event happens because the KL25Z
mjr 54:fd77a6b2f76c 2246 // USB hardware is too slow to respond to a message. I'm not
mjr 54:fd77a6b2f76c 2247 // sure why this would only happen after a disconnect and not
mjr 54:fd77a6b2f76c 2248 // during the initial connection; maybe there's some reset work
mjr 54:fd77a6b2f76c 2249 // in the hardware that takes a substantial amount of time after
mjr 54:fd77a6b2f76c 2250 // a disconnect.
mjr 54:fd77a6b2f76c 2251 //
mjr 54:fd77a6b2f76c 2252 // The solution: the problem happens during the SETUP exchange,
mjr 54:fd77a6b2f76c 2253 // after we've been assigned a bus address. It only happens on
mjr 54:fd77a6b2f76c 2254 // some percentage of connection requests, so if we can simply
mjr 54:fd77a6b2f76c 2255 // start over when the failure occurs, we'll eventually succeed
mjr 54:fd77a6b2f76c 2256 // simply because not every attempt fails. The ideal would be
mjr 54:fd77a6b2f76c 2257 // to get the success rate up to 100%, but I can't figure out how
mjr 54:fd77a6b2f76c 2258 // to fix the underlying problem, so this is the next best thing.
mjr 54:fd77a6b2f76c 2259 //
mjr 54:fd77a6b2f76c 2260 // We can detect when the failure occurs by noticing when a SLEEP
mjr 54:fd77a6b2f76c 2261 // interrupt happens while we have an assigned bus address.
mjr 54:fd77a6b2f76c 2262 //
mjr 54:fd77a6b2f76c 2263 // To start a new connection attempt, we have to make the *host*
mjr 54:fd77a6b2f76c 2264 // try again. The logical connection is initiated solely by the
mjr 54:fd77a6b2f76c 2265 // host. Fortunately, it's easy to get the host to initiate the
mjr 54:fd77a6b2f76c 2266 // process: if we disconnect on the device side, it effectively
mjr 54:fd77a6b2f76c 2267 // makes the device look to the PC like it's electrically unplugged.
mjr 54:fd77a6b2f76c 2268 // When we reconnect on the device side, the PC thinks a new device
mjr 54:fd77a6b2f76c 2269 // has been plugged in and initiates the logical connection setup.
mjr 54:fd77a6b2f76c 2270 // We have to remain disconnected for a macroscopic interval for
mjr 54:fd77a6b2f76c 2271 // this to happen - 5ms seems to do the trick.
mjr 54:fd77a6b2f76c 2272 //
mjr 54:fd77a6b2f76c 2273 // Here's the full algorithm:
mjr 54:fd77a6b2f76c 2274 //
mjr 54:fd77a6b2f76c 2275 // 1. In the SLEEP interrupt handler, if we have a bus address,
mjr 54:fd77a6b2f76c 2276 // we disconnect the device. This happens in ISR context, so we
mjr 54:fd77a6b2f76c 2277 // can't wait around for 5ms. Instead, we simply set a flag noting
mjr 54:fd77a6b2f76c 2278 // that the connection has been broken, and we note the time and
mjr 54:fd77a6b2f76c 2279 // return.
mjr 54:fd77a6b2f76c 2280 //
mjr 54:fd77a6b2f76c 2281 // 2. In our main loop, whenever we find that we're disconnected,
mjr 54:fd77a6b2f76c 2282 // we call recoverConnection(). The main loop's job is basically a
mjr 54:fd77a6b2f76c 2283 // bunch of device polling. We're just one more device to poll, so
mjr 54:fd77a6b2f76c 2284 // recoverConnection() will be called soon after a disconnect, and
mjr 54:fd77a6b2f76c 2285 // then will be called in a loop for as long as we're disconnected.
mjr 54:fd77a6b2f76c 2286 //
mjr 54:fd77a6b2f76c 2287 // 3. In recoverConnection(), we check the flag we set in the SLEEP
mjr 54:fd77a6b2f76c 2288 // handler. If set, we wait until 5ms has elapsed from the SLEEP
mjr 54:fd77a6b2f76c 2289 // event time that we noted, then we'll reconnect and clear the flag.
mjr 54:fd77a6b2f76c 2290 // This gives us the required 5ms (or longer) delay between the
mjr 54:fd77a6b2f76c 2291 // disconnect and reconnect, ensuring that the PC will notice and
mjr 54:fd77a6b2f76c 2292 // will start over with the connection protocol.
mjr 54:fd77a6b2f76c 2293 //
mjr 54:fd77a6b2f76c 2294 // 4. The main loop keeps calling recoverConnection() in a loop for
mjr 54:fd77a6b2f76c 2295 // as long as we're disconnected, so if the new connection attempt
mjr 54:fd77a6b2f76c 2296 // triggered in step 3 fails, the SLEEP interrupt will happen again,
mjr 54:fd77a6b2f76c 2297 // we'll disconnect again, the flag will get set again, and
mjr 54:fd77a6b2f76c 2298 // recoverConnection() will reconnect again after another suitable
mjr 54:fd77a6b2f76c 2299 // delay. This will repeat until the connection succeeds or hell
mjr 54:fd77a6b2f76c 2300 // freezes over.
mjr 54:fd77a6b2f76c 2301 //
mjr 54:fd77a6b2f76c 2302 // Each disconnect happens immediately when a reconnect attempt
mjr 54:fd77a6b2f76c 2303 // fails, and an entire successful connection only takes about 25ms,
mjr 54:fd77a6b2f76c 2304 // so our loop can retry at more than 30 attempts per second.
mjr 54:fd77a6b2f76c 2305 // In my testing, lost connections almost always reconnect in
mjr 54:fd77a6b2f76c 2306 // less than second with this code in place.
mjr 54:fd77a6b2f76c 2307 void recoverConnection()
mjr 54:fd77a6b2f76c 2308 {
mjr 54:fd77a6b2f76c 2309 // if a reconnect is pending, reconnect
mjr 54:fd77a6b2f76c 2310 if (reconnectPending_)
mjr 54:fd77a6b2f76c 2311 {
mjr 54:fd77a6b2f76c 2312 // Loop until we reach 5ms after the last sleep event.
mjr 54:fd77a6b2f76c 2313 for (bool done = false ; !done ; )
mjr 54:fd77a6b2f76c 2314 {
mjr 54:fd77a6b2f76c 2315 // If we've reached the target time, reconnect. Do the
mjr 54:fd77a6b2f76c 2316 // time check and flag reset atomically, so that we can't
mjr 54:fd77a6b2f76c 2317 // have another sleep event sneak in after we've verified
mjr 54:fd77a6b2f76c 2318 // the time. If another event occurs, it has to happen
mjr 54:fd77a6b2f76c 2319 // before we check, in which case it'll update the time
mjr 54:fd77a6b2f76c 2320 // before we check it, or after we clear the flag, in
mjr 54:fd77a6b2f76c 2321 // which case it will reset the flag and we'll do another
mjr 54:fd77a6b2f76c 2322 // round the next time we call this routine.
mjr 54:fd77a6b2f76c 2323 __disable_irq();
mjr 54:fd77a6b2f76c 2324 if (uint32_t(timer_.read_us() - lastSleepTime_) > 5000)
mjr 54:fd77a6b2f76c 2325 {
mjr 54:fd77a6b2f76c 2326 connect(false);
mjr 54:fd77a6b2f76c 2327 reconnectPending_ = false;
mjr 54:fd77a6b2f76c 2328 done = true;
mjr 54:fd77a6b2f76c 2329 }
mjr 54:fd77a6b2f76c 2330 __enable_irq();
mjr 54:fd77a6b2f76c 2331 }
mjr 54:fd77a6b2f76c 2332 }
mjr 54:fd77a6b2f76c 2333 }
mjr 5:a70c0bce770d 2334
mjr 5:a70c0bce770d 2335 protected:
mjr 54:fd77a6b2f76c 2336 // Handle a USB SLEEP interrupt. This interrupt signifies that the
mjr 54:fd77a6b2f76c 2337 // USB hardware module hasn't seen any token traffic for 3ms, which
mjr 54:fd77a6b2f76c 2338 // means that we're either physically or logically disconnected.
mjr 54:fd77a6b2f76c 2339 //
mjr 54:fd77a6b2f76c 2340 // Important: this runs in ISR context.
mjr 54:fd77a6b2f76c 2341 //
mjr 54:fd77a6b2f76c 2342 // Note that this is a specialized sense of "sleep" that's unrelated
mjr 54:fd77a6b2f76c 2343 // to the similarly named power modes on the PC. This has nothing
mjr 54:fd77a6b2f76c 2344 // to do with suspend/sleep mode on the PC, and it's not a low-power
mjr 54:fd77a6b2f76c 2345 // mode on the KL25Z. They really should have called this interrupt
mjr 54:fd77a6b2f76c 2346 // DISCONNECT or BROKEN CONNECTION.)
mjr 54:fd77a6b2f76c 2347 virtual void sleepStateChanged(unsigned int sleeping)
mjr 54:fd77a6b2f76c 2348 {
mjr 54:fd77a6b2f76c 2349 // note the new state
mjr 54:fd77a6b2f76c 2350 sleeping_ = sleeping;
mjr 54:fd77a6b2f76c 2351
mjr 54:fd77a6b2f76c 2352 // If we have a non-zero bus address, we have at least a partial
mjr 54:fd77a6b2f76c 2353 // connection to the host (we've made it at least as far as the
mjr 54:fd77a6b2f76c 2354 // SETUP stage). Explicitly disconnect, and the pending reconnect
mjr 54:fd77a6b2f76c 2355 // flag, and remember the time of the sleep event.
mjr 54:fd77a6b2f76c 2356 if (USB0->ADDR != 0x00)
mjr 54:fd77a6b2f76c 2357 {
mjr 54:fd77a6b2f76c 2358 disconnect();
mjr 54:fd77a6b2f76c 2359 lastSleepTime_ = timer_.read_us();
mjr 54:fd77a6b2f76c 2360 reconnectPending_ = true;
mjr 54:fd77a6b2f76c 2361 }
mjr 54:fd77a6b2f76c 2362 }
mjr 54:fd77a6b2f76c 2363
mjr 54:fd77a6b2f76c 2364 // is the USB connection asleep?
mjr 54:fd77a6b2f76c 2365 volatile bool sleeping_;
mjr 54:fd77a6b2f76c 2366
mjr 54:fd77a6b2f76c 2367 // flag: reconnect pending after sleep event
mjr 54:fd77a6b2f76c 2368 volatile bool reconnectPending_;
mjr 54:fd77a6b2f76c 2369
mjr 54:fd77a6b2f76c 2370 // time of last sleep event while connected
mjr 54:fd77a6b2f76c 2371 volatile uint32_t lastSleepTime_;
mjr 54:fd77a6b2f76c 2372
mjr 54:fd77a6b2f76c 2373 // timer to keep track of interval since last sleep event
mjr 54:fd77a6b2f76c 2374 Timer timer_;
mjr 5:a70c0bce770d 2375 };
mjr 5:a70c0bce770d 2376
mjr 5:a70c0bce770d 2377 // ---------------------------------------------------------------------------
mjr 5:a70c0bce770d 2378 //
mjr 5:a70c0bce770d 2379 // Accelerometer (MMA8451Q)
mjr 5:a70c0bce770d 2380 //
mjr 5:a70c0bce770d 2381
mjr 5:a70c0bce770d 2382 // The MMA8451Q is the KL25Z's on-board 3-axis accelerometer.
mjr 5:a70c0bce770d 2383 //
mjr 5:a70c0bce770d 2384 // This is a custom wrapper for the library code to interface to the
mjr 6:cc35eb643e8f 2385 // MMA8451Q. This class encapsulates an interrupt handler and
mjr 6:cc35eb643e8f 2386 // automatic calibration.
mjr 5:a70c0bce770d 2387 //
mjr 5:a70c0bce770d 2388 // We install an interrupt handler on the accelerometer "data ready"
mjr 6:cc35eb643e8f 2389 // interrupt to ensure that we fetch each sample immediately when it
mjr 6:cc35eb643e8f 2390 // becomes available. The accelerometer data rate is fiarly high
mjr 6:cc35eb643e8f 2391 // (800 Hz), so it's not practical to keep up with it by polling.
mjr 6:cc35eb643e8f 2392 // Using an interrupt handler lets us respond quickly and read
mjr 6:cc35eb643e8f 2393 // every sample.
mjr 5:a70c0bce770d 2394 //
mjr 6:cc35eb643e8f 2395 // We automatically calibrate the accelerometer so that it's not
mjr 6:cc35eb643e8f 2396 // necessary to get it exactly level when installing it, and so
mjr 6:cc35eb643e8f 2397 // that it's also not necessary to calibrate it manually. There's
mjr 6:cc35eb643e8f 2398 // lots of experience that tells us that manual calibration is a
mjr 6:cc35eb643e8f 2399 // terrible solution, mostly because cabinets tend to shift slightly
mjr 6:cc35eb643e8f 2400 // during use, requiring frequent recalibration. Instead, we
mjr 6:cc35eb643e8f 2401 // calibrate automatically. We continuously monitor the acceleration
mjr 6:cc35eb643e8f 2402 // data, watching for periods of constant (or nearly constant) values.
mjr 6:cc35eb643e8f 2403 // Any time it appears that the machine has been at rest for a while
mjr 6:cc35eb643e8f 2404 // (about 5 seconds), we'll average the readings during that rest
mjr 6:cc35eb643e8f 2405 // period and use the result as the level rest position. This is
mjr 6:cc35eb643e8f 2406 // is ongoing, so we'll quickly find the center point again if the
mjr 6:cc35eb643e8f 2407 // machine is moved during play (by an especially aggressive bout
mjr 6:cc35eb643e8f 2408 // of nudging, say).
mjr 5:a70c0bce770d 2409 //
mjr 5:a70c0bce770d 2410
mjr 17:ab3cec0c8bf4 2411 // I2C address of the accelerometer (this is a constant of the KL25Z)
mjr 17:ab3cec0c8bf4 2412 const int MMA8451_I2C_ADDRESS = (0x1d<<1);
mjr 17:ab3cec0c8bf4 2413
mjr 17:ab3cec0c8bf4 2414 // SCL and SDA pins for the accelerometer (constant for the KL25Z)
mjr 17:ab3cec0c8bf4 2415 #define MMA8451_SCL_PIN PTE25
mjr 17:ab3cec0c8bf4 2416 #define MMA8451_SDA_PIN PTE24
mjr 17:ab3cec0c8bf4 2417
mjr 17:ab3cec0c8bf4 2418 // Digital in pin to use for the accelerometer interrupt. For the KL25Z,
mjr 17:ab3cec0c8bf4 2419 // this can be either PTA14 or PTA15, since those are the pins physically
mjr 17:ab3cec0c8bf4 2420 // wired on this board to the MMA8451 interrupt controller.
mjr 17:ab3cec0c8bf4 2421 #define MMA8451_INT_PIN PTA15
mjr 17:ab3cec0c8bf4 2422
mjr 17:ab3cec0c8bf4 2423
mjr 6:cc35eb643e8f 2424 // accelerometer input history item, for gathering calibration data
mjr 6:cc35eb643e8f 2425 struct AccHist
mjr 5:a70c0bce770d 2426 {
mjr 6:cc35eb643e8f 2427 AccHist() { x = y = d = 0.0; xtot = ytot = 0.0; cnt = 0; }
mjr 6:cc35eb643e8f 2428 void set(float x, float y, AccHist *prv)
mjr 6:cc35eb643e8f 2429 {
mjr 6:cc35eb643e8f 2430 // save the raw position
mjr 6:cc35eb643e8f 2431 this->x = x;
mjr 6:cc35eb643e8f 2432 this->y = y;
mjr 6:cc35eb643e8f 2433 this->d = distance(prv);
mjr 6:cc35eb643e8f 2434 }
mjr 6:cc35eb643e8f 2435
mjr 6:cc35eb643e8f 2436 // reading for this entry
mjr 5:a70c0bce770d 2437 float x, y;
mjr 5:a70c0bce770d 2438
mjr 6:cc35eb643e8f 2439 // distance from previous entry
mjr 6:cc35eb643e8f 2440 float d;
mjr 5:a70c0bce770d 2441
mjr 6:cc35eb643e8f 2442 // total and count of samples averaged over this period
mjr 6:cc35eb643e8f 2443 float xtot, ytot;
mjr 6:cc35eb643e8f 2444 int cnt;
mjr 6:cc35eb643e8f 2445
mjr 6:cc35eb643e8f 2446 void clearAvg() { xtot = ytot = 0.0; cnt = 0; }
mjr 6:cc35eb643e8f 2447 void addAvg(float x, float y) { xtot += x; ytot += y; ++cnt; }
mjr 6:cc35eb643e8f 2448 float xAvg() const { return xtot/cnt; }
mjr 6:cc35eb643e8f 2449 float yAvg() const { return ytot/cnt; }
mjr 5:a70c0bce770d 2450
mjr 6:cc35eb643e8f 2451 float distance(AccHist *p)
mjr 6:cc35eb643e8f 2452 { return sqrt(square(p->x - x) + square(p->y - y)); }
mjr 5:a70c0bce770d 2453 };
mjr 5:a70c0bce770d 2454
mjr 5:a70c0bce770d 2455 // accelerometer wrapper class
mjr 3:3514575d4f86 2456 class Accel
mjr 3:3514575d4f86 2457 {
mjr 3:3514575d4f86 2458 public:
mjr 3:3514575d4f86 2459 Accel(PinName sda, PinName scl, int i2cAddr, PinName irqPin)
mjr 3:3514575d4f86 2460 : mma_(sda, scl, i2cAddr), intIn_(irqPin)
mjr 3:3514575d4f86 2461 {
mjr 5:a70c0bce770d 2462 // remember the interrupt pin assignment
mjr 5:a70c0bce770d 2463 irqPin_ = irqPin;
mjr 5:a70c0bce770d 2464
mjr 5:a70c0bce770d 2465 // reset and initialize
mjr 5:a70c0bce770d 2466 reset();
mjr 5:a70c0bce770d 2467 }
mjr 5:a70c0bce770d 2468
mjr 5:a70c0bce770d 2469 void reset()
mjr 5:a70c0bce770d 2470 {
mjr 6:cc35eb643e8f 2471 // clear the center point
mjr 6:cc35eb643e8f 2472 cx_ = cy_ = 0.0;
mjr 6:cc35eb643e8f 2473
mjr 6:cc35eb643e8f 2474 // start the calibration timer
mjr 5:a70c0bce770d 2475 tCenter_.start();
mjr 5:a70c0bce770d 2476 iAccPrv_ = nAccPrv_ = 0;
mjr 6:cc35eb643e8f 2477
mjr 5:a70c0bce770d 2478 // reset and initialize the MMA8451Q
mjr 5:a70c0bce770d 2479 mma_.init();
mjr 6:cc35eb643e8f 2480
mjr 6:cc35eb643e8f 2481 // set the initial integrated velocity reading to zero
mjr 6:cc35eb643e8f 2482 vx_ = vy_ = 0;
mjr 3:3514575d4f86 2483
mjr 6:cc35eb643e8f 2484 // set up our accelerometer interrupt handling
mjr 6:cc35eb643e8f 2485 intIn_.rise(this, &Accel::isr);
mjr 5:a70c0bce770d 2486 mma_.setInterruptMode(irqPin_ == PTA14 ? 1 : 2);
mjr 3:3514575d4f86 2487
mjr 3:3514575d4f86 2488 // read the current registers to clear the data ready flag
mjr 6:cc35eb643e8f 2489 mma_.getAccXYZ(ax_, ay_, az_);
mjr 3:3514575d4f86 2490
mjr 3:3514575d4f86 2491 // start our timers
mjr 3:3514575d4f86 2492 tGet_.start();
mjr 3:3514575d4f86 2493 tInt_.start();
mjr 3:3514575d4f86 2494 }
mjr 3:3514575d4f86 2495
mjr 9:fd65b0a94720 2496 void get(int &x, int &y)
mjr 3:3514575d4f86 2497 {
mjr 3:3514575d4f86 2498 // disable interrupts while manipulating the shared data
mjr 3:3514575d4f86 2499 __disable_irq();
mjr 3:3514575d4f86 2500
mjr 3:3514575d4f86 2501 // read the shared data and store locally for calculations
mjr 6:cc35eb643e8f 2502 float ax = ax_, ay = ay_;
mjr 6:cc35eb643e8f 2503 float vx = vx_, vy = vy_;
mjr 5:a70c0bce770d 2504
mjr 6:cc35eb643e8f 2505 // reset the velocity sum for the next run
mjr 6:cc35eb643e8f 2506 vx_ = vy_ = 0;
mjr 3:3514575d4f86 2507
mjr 3:3514575d4f86 2508 // get the time since the last get() sample
mjr 38:091e511ce8a0 2509 float dt = tGet_.read_us()/1.0e6f;
mjr 3:3514575d4f86 2510 tGet_.reset();
mjr 3:3514575d4f86 2511
mjr 3:3514575d4f86 2512 // done manipulating the shared data
mjr 3:3514575d4f86 2513 __enable_irq();
mjr 3:3514575d4f86 2514
mjr 6:cc35eb643e8f 2515 // adjust the readings for the integration time
mjr 6:cc35eb643e8f 2516 vx /= dt;
mjr 6:cc35eb643e8f 2517 vy /= dt;
mjr 6:cc35eb643e8f 2518
mjr 6:cc35eb643e8f 2519 // add this sample to the current calibration interval's running total
mjr 6:cc35eb643e8f 2520 AccHist *p = accPrv_ + iAccPrv_;
mjr 6:cc35eb643e8f 2521 p->addAvg(ax, ay);
mjr 6:cc35eb643e8f 2522
mjr 5:a70c0bce770d 2523 // check for auto-centering every so often
mjr 48:058ace2aed1d 2524 if (tCenter_.read_us() > 1000000)
mjr 5:a70c0bce770d 2525 {
mjr 5:a70c0bce770d 2526 // add the latest raw sample to the history list
mjr 6:cc35eb643e8f 2527 AccHist *prv = p;
mjr 5:a70c0bce770d 2528 iAccPrv_ = (iAccPrv_ + 1) % maxAccPrv;
mjr 6:cc35eb643e8f 2529 p = accPrv_ + iAccPrv_;
mjr 6:cc35eb643e8f 2530 p->set(ax, ay, prv);
mjr 5:a70c0bce770d 2531
mjr 5:a70c0bce770d 2532 // if we have a full complement, check for stability
mjr 5:a70c0bce770d 2533 if (nAccPrv_ >= maxAccPrv)
mjr 5:a70c0bce770d 2534 {
mjr 5:a70c0bce770d 2535 // check if we've been stable for all recent samples
mjr 6:cc35eb643e8f 2536 static const float accTol = .01;
mjr 6:cc35eb643e8f 2537 AccHist *p0 = accPrv_;
mjr 6:cc35eb643e8f 2538 if (p0[0].d < accTol
mjr 6:cc35eb643e8f 2539 && p0[1].d < accTol
mjr 6:cc35eb643e8f 2540 && p0[2].d < accTol
mjr 6:cc35eb643e8f 2541 && p0[3].d < accTol
mjr 6:cc35eb643e8f 2542 && p0[4].d < accTol)
mjr 5:a70c0bce770d 2543 {
mjr 6:cc35eb643e8f 2544 // Figure the new calibration point as the average of
mjr 6:cc35eb643e8f 2545 // the samples over the rest period
mjr 6:cc35eb643e8f 2546 cx_ = (p0[0].xAvg() + p0[1].xAvg() + p0[2].xAvg() + p0[3].xAvg() + p0[4].xAvg())/5.0;
mjr 6:cc35eb643e8f 2547 cy_ = (p0[0].yAvg() + p0[1].yAvg() + p0[2].yAvg() + p0[3].yAvg() + p0[4].yAvg())/5.0;
mjr 5:a70c0bce770d 2548 }
mjr 5:a70c0bce770d 2549 }
mjr 5:a70c0bce770d 2550 else
mjr 5:a70c0bce770d 2551 {
mjr 5:a70c0bce770d 2552 // not enough samples yet; just up the count
mjr 5:a70c0bce770d 2553 ++nAccPrv_;
mjr 5:a70c0bce770d 2554 }
mjr 6:cc35eb643e8f 2555
mjr 6:cc35eb643e8f 2556 // clear the new item's running totals
mjr 6:cc35eb643e8f 2557 p->clearAvg();
mjr 5:a70c0bce770d 2558
mjr 5:a70c0bce770d 2559 // reset the timer
mjr 5:a70c0bce770d 2560 tCenter_.reset();
mjr 39:b3815a1c3802 2561
mjr 39:b3815a1c3802 2562 // If we haven't seen an interrupt in a while, do an explicit read to
mjr 39:b3815a1c3802 2563 // "unstick" the device. The device can become stuck - which is to say,
mjr 39:b3815a1c3802 2564 // it will stop delivering data-ready interrupts - if we fail to service
mjr 39:b3815a1c3802 2565 // one data-ready interrupt before the next one occurs. Reading a sample
mjr 39:b3815a1c3802 2566 // will clear up this overrun condition and allow normal interrupt
mjr 39:b3815a1c3802 2567 // generation to continue.
mjr 39:b3815a1c3802 2568 //
mjr 39:b3815a1c3802 2569 // Note that this stuck condition *shouldn't* ever occur - if it does,
mjr 39:b3815a1c3802 2570 // it means that we're spending a long period with interrupts disabled
mjr 39:b3815a1c3802 2571 // (either in a critical section or in another interrupt handler), which
mjr 39:b3815a1c3802 2572 // will likely cause other worse problems beyond the sticky accelerometer.
mjr 39:b3815a1c3802 2573 // Even so, it's easy to detect and correct, so we'll do so for the sake
mjr 39:b3815a1c3802 2574 // of making the system more fault-tolerant.
mjr 39:b3815a1c3802 2575 if (tInt_.read() > 1.0f)
mjr 39:b3815a1c3802 2576 {
mjr 39:b3815a1c3802 2577 float x, y, z;
mjr 39:b3815a1c3802 2578 mma_.getAccXYZ(x, y, z);
mjr 39:b3815a1c3802 2579 }
mjr 5:a70c0bce770d 2580 }
mjr 5:a70c0bce770d 2581
mjr 6:cc35eb643e8f 2582 // report our integrated velocity reading in x,y
mjr 6:cc35eb643e8f 2583 x = rawToReport(vx);
mjr 6:cc35eb643e8f 2584 y = rawToReport(vy);
mjr 5:a70c0bce770d 2585
mjr 6:cc35eb643e8f 2586 #ifdef DEBUG_PRINTF
mjr 6:cc35eb643e8f 2587 if (x != 0 || y != 0)
mjr 6:cc35eb643e8f 2588 printf("%f %f %d %d %f\r\n", vx, vy, x, y, dt);
mjr 6:cc35eb643e8f 2589 #endif
mjr 3:3514575d4f86 2590 }
mjr 29:582472d0bc57 2591
mjr 3:3514575d4f86 2592 private:
mjr 6:cc35eb643e8f 2593 // adjust a raw acceleration figure to a usb report value
mjr 6:cc35eb643e8f 2594 int rawToReport(float v)
mjr 5:a70c0bce770d 2595 {
mjr 6:cc35eb643e8f 2596 // scale to the joystick report range and round to integer
mjr 6:cc35eb643e8f 2597 int i = int(round(v*JOYMAX));
mjr 5:a70c0bce770d 2598
mjr 6:cc35eb643e8f 2599 // if it's near the center, scale it roughly as 20*(i/20)^2,
mjr 6:cc35eb643e8f 2600 // to suppress noise near the rest position
mjr 6:cc35eb643e8f 2601 static const int filter[] = {
mjr 6:cc35eb643e8f 2602 -18, -16, -14, -13, -11, -10, -8, -7, -6, -5, -4, -3, -2, -2, -1, -1, 0, 0, 0, 0,
mjr 6:cc35eb643e8f 2603 0,
mjr 6:cc35eb643e8f 2604 0, 0, 0, 0, 1, 1, 2, 2, 3, 4, 5, 6, 7, 8, 10, 11, 13, 14, 16, 18
mjr 6:cc35eb643e8f 2605 };
mjr 6:cc35eb643e8f 2606 return (i > 20 || i < -20 ? i : filter[i+20]);
mjr 5:a70c0bce770d 2607 }
mjr 5:a70c0bce770d 2608
mjr 3:3514575d4f86 2609 // interrupt handler
mjr 3:3514575d4f86 2610 void isr()
mjr 3:3514575d4f86 2611 {
mjr 3:3514575d4f86 2612 // Read the axes. Note that we have to read all three axes
mjr 3:3514575d4f86 2613 // (even though we only really use x and y) in order to clear
mjr 3:3514575d4f86 2614 // the "data ready" status bit in the accelerometer. The
mjr 3:3514575d4f86 2615 // interrupt only occurs when the "ready" bit transitions from
mjr 3:3514575d4f86 2616 // off to on, so we have to make sure it's off.
mjr 5:a70c0bce770d 2617 float x, y, z;
mjr 5:a70c0bce770d 2618 mma_.getAccXYZ(x, y, z);
mjr 3:3514575d4f86 2619
mjr 3:3514575d4f86 2620 // calculate the time since the last interrupt
mjr 39:b3815a1c3802 2621 float dt = tInt_.read();
mjr 3:3514575d4f86 2622 tInt_.reset();
mjr 6:cc35eb643e8f 2623
mjr 6:cc35eb643e8f 2624 // integrate the time slice from the previous reading to this reading
mjr 6:cc35eb643e8f 2625 vx_ += (x + ax_ - 2*cx_)*dt/2;
mjr 6:cc35eb643e8f 2626 vy_ += (y + ay_ - 2*cy_)*dt/2;
mjr 3:3514575d4f86 2627
mjr 6:cc35eb643e8f 2628 // store the updates
mjr 6:cc35eb643e8f 2629 ax_ = x;
mjr 6:cc35eb643e8f 2630 ay_ = y;
mjr 6:cc35eb643e8f 2631 az_ = z;
mjr 3:3514575d4f86 2632 }
mjr 3:3514575d4f86 2633
mjr 3:3514575d4f86 2634 // underlying accelerometer object
mjr 3:3514575d4f86 2635 MMA8451Q mma_;
mjr 3:3514575d4f86 2636
mjr 5:a70c0bce770d 2637 // last raw acceleration readings
mjr 6:cc35eb643e8f 2638 float ax_, ay_, az_;
mjr 5:a70c0bce770d 2639
mjr 6:cc35eb643e8f 2640 // integrated velocity reading since last get()
mjr 6:cc35eb643e8f 2641 float vx_, vy_;
mjr 6:cc35eb643e8f 2642
mjr 3:3514575d4f86 2643 // timer for measuring time between get() samples
mjr 3:3514575d4f86 2644 Timer tGet_;
mjr 3:3514575d4f86 2645
mjr 3:3514575d4f86 2646 // timer for measuring time between interrupts
mjr 3:3514575d4f86 2647 Timer tInt_;
mjr 5:a70c0bce770d 2648
mjr 6:cc35eb643e8f 2649 // Calibration reference point for accelerometer. This is the
mjr 6:cc35eb643e8f 2650 // average reading on the accelerometer when in the neutral position
mjr 6:cc35eb643e8f 2651 // at rest.
mjr 6:cc35eb643e8f 2652 float cx_, cy_;
mjr 5:a70c0bce770d 2653
mjr 5:a70c0bce770d 2654 // timer for atuo-centering
mjr 5:a70c0bce770d 2655 Timer tCenter_;
mjr 6:cc35eb643e8f 2656
mjr 6:cc35eb643e8f 2657 // Auto-centering history. This is a separate history list that
mjr 6:cc35eb643e8f 2658 // records results spaced out sparesely over time, so that we can
mjr 6:cc35eb643e8f 2659 // watch for long-lasting periods of rest. When we observe nearly
mjr 6:cc35eb643e8f 2660 // no motion for an extended period (on the order of 5 seconds), we
mjr 6:cc35eb643e8f 2661 // take this to mean that the cabinet is at rest in its neutral
mjr 6:cc35eb643e8f 2662 // position, so we take this as the calibration zero point for the
mjr 6:cc35eb643e8f 2663 // accelerometer. We update this history continuously, which allows
mjr 6:cc35eb643e8f 2664 // us to continuously re-calibrate the accelerometer. This ensures
mjr 6:cc35eb643e8f 2665 // that we'll automatically adjust to any actual changes in the
mjr 6:cc35eb643e8f 2666 // cabinet's orientation (e.g., if it gets moved slightly by an
mjr 6:cc35eb643e8f 2667 // especially strong nudge) as well as any systematic drift in the
mjr 6:cc35eb643e8f 2668 // accelerometer measurement bias (e.g., from temperature changes).
mjr 5:a70c0bce770d 2669 int iAccPrv_, nAccPrv_;
mjr 5:a70c0bce770d 2670 static const int maxAccPrv = 5;
mjr 6:cc35eb643e8f 2671 AccHist accPrv_[maxAccPrv];
mjr 6:cc35eb643e8f 2672
mjr 5:a70c0bce770d 2673 // interurupt pin name
mjr 5:a70c0bce770d 2674 PinName irqPin_;
mjr 5:a70c0bce770d 2675
mjr 5:a70c0bce770d 2676 // interrupt router
mjr 5:a70c0bce770d 2677 InterruptIn intIn_;
mjr 3:3514575d4f86 2678 };
mjr 3:3514575d4f86 2679
mjr