Progress update: Screen, SD and config loading/saving (Reply)

I made a lot of progress on the Teensy 3.0 upgrade/rewrite of my right-handed programmable game keypad over the weekend. It's still not ready to replace the Teensy 2++ control board yet - and has a *long* way to go - but the new hardware is mainly connected and functioning.

Watch on YouTube

The video shows the initial startup process (with a few delays so I could capture it in video). On startup, it loads the keymaps from an ini file stored on the SD Card. A progess bar is shown for how many keymaps have been loaded. Later on I'll add text to it as well, but I'm currently sorting out what string processing commands are available for use - at present the Teensy 3.0 arduino-based compiler is disabling things like snprintf which is complicating matters a little. Edit: Hmm... sprintf is there, but snprintf and strcasecmp are not. I have already worked around strcasecmp being missing, and I can use sprintf instead of snprintf though I would normally prefer the length-restricted version to prevent buffer overflows. Edit 2: This got fixed in Teensy beta 10 (I think it was), so all the expected string processing functions are now available for use.

For the purposes of testing, the load process then loops through each of the keymaps loaded from the config file, showing their keycodes (currently blank if they are unassigned), and highlighting one key (at random) to test the ability to highlight a chosen key for use in key remapping menus later. The keymaps themselves specify their foreground/background colours, a bitmap file path (also stored on the SD card) to use as a logo (and to help make them quickly-identifiable), and their title. The top 4 rows map to a bank of 24 keys under my fingers, the 3x3 section to a digital thumb switch (8-direction+centre push), and the final single key below those maps to a foot switch that I use mainly for push-to-talk voice communications like mummble while gaming. The diagonals on the thumb switch can be either mapped to a key individually, or specified as activating the two cardinal directions that they're between (i.e. top-right/NE acts as having pressed both up/N and right/E).

At the end I zoomed out just to show the testbed complete with a rats nest of wiring (it's not that messy, just that there's a lot of wires and over time they get squished around a bit). This has meant I could change pins around easily without having to ask my husband to resolder stuff (while I can solder stuff, I haven't got any experience with surface mount and the tighter spacing on these, though the Teensy itself doesn't have many connections that are...teensy...to solder). The block of pins on the right are connected to the Teensy 3.0's pads underneath (24-33, 3.3V, GND, A12/13). Bringing these out for use was essential because the tft screen uses a 16-bit parallel data bus, and there just isn't enough pins to do the data and have the SPI interfaces + the keyboard's shift registers/latch reset pins available at the same time without those pins.

The Teensy 2++ version of the keyboard was a little more rudimentary - storage of keymaps was done using the on-board EEPROM as direct byte/uint/char storage, and the screen was a 64x128 Monochrome GLCD. The EEPROM proved to be problematical - when I added the foot switch it invalidated the keymaps in the EEPROM because I'd kept the storage too simple, and trying to reload them crashed the Teensy until I worked out what was happening and cleared them out to start over. Then at a later date I accidently uploaded an old version of the code and crashed things again, and ended up deleting them another time. Losing my keymaps - after spending a few months building up muscle memory for where the keys were - is something I don't want to get stuck with again, which is why I'm moving to the config file format with the keys stored by NAME rather than by PIN NUMBER (so if the key is moved the associated keycode is loaded into the new place by default, or if a key is added it just gets initialised to unassigned if it's not defined in the keymap - and so that I can back the keymaps up!) The keys themselves are shaped to fit my right hand (because I mouse on the left):

The keys are Cherry Blacks, and the keycaps come from WASD Keyboards in the US. The Cherry Blacks are a delight to game on - I didn't notice just how much of a difference they made to things lke accuracy in jumping puzzles in the game I'm playing at present (Guild Wars 2) until I had the accident uploading the old code to the teensy and killed it for a day leaving me with a standard keyboard again...it wasn't fun going back.

I originally started on this when I simply couldn't find gaming peripherals designed for left-hand mouse/right-hand keyboard use in games where you needed access to a lot of keys at once (i.e. MMOs/RPGs). And no, I'm not normally left-handed, but I've got some RSI damage in my right shoulder and cannot use a mouse on the right any more. It annoyed me when people's normal reaction to looking for what amounted to "left-handed" peripherals was "learn to use the mouse right-handed and get a Naga" and/or "if you can't be bothered to learn to use it right handed like everyone else, suck it up"...and I decided that I liked neither option.

I haven't tried connecting the touch panel at all yet, but it's there for future expansion - and there's enough pins still available to connect it later (shared SPI + chip select + interupt + busy). Ideally, the whole control board will end up fitting inside the current box that holds the keys in the photo above, with the screen mounted at the back of it. I'm currently concentrating on getting the menus and configuration stuff worked out now, since I've already done the keyboard part previously (so I have patches for adding the NKRO stuff I'm using on the Teensy 2++ version) that I should be able to port across without too much trouble.