Author Archives: Allen Huffman

About Allen Huffman

Co-founder of Sub-Etha Software.

Arduino USB joystick to iCade converter

  • 2014/03/16 Update: The source code to this is now on GitHub. Check the Arduino link at the top of each page of this site.
  • 2013/02/22 Update: WordPress seems to love to chew up source code, so the sources pasted in are not working properly. I will try to find a solution. Sometimes it works great, other times not at all.
IMG_0649
Arduino Leonardo and USB Host shield acting as USB Joystick to iCade converter.

Today, I picked up my Circuits@Home USB Host adapter from the post office. Now I could finally try to put together a converter that would read from a standard USB joystick and send out iCade formatted keyboard characters to my iPad. Since I had never worked with USB before, I was amazed it only took about 30 minutes to figure out. This is a testament to the work done by the folks responsible for the USB Host library code. The inclusion of functioning sample code allowed me to make quick modifications to do what I wanted.

I will post full details soon, but right now, here are some highlights.

For this project, I am using an Arduino Leonardo. Unlike the UNO and most other Arduinos, the Leonardo is capable of acting as a USB HID (human interface device) so it can appear to be a mouse or keyboard to the computer it is plugged in to. In my case, the computer would be an iPad via Apple’s Camera Connector Kit USB port adapter, and the Leonardo would be acting like a keyboard to send iCade keys,

I had previously downloaded the Arduino USB library from GitHub and extracted it in to my Arduino IDE library folder. I discussed my first experience with Arduino libraries in an earlier article when I was trying to get the iTead Studios USB shield to work.

I was able to test the USB by running various example programs that came with the library, specifically USBHidJoystick. Here is an example of that program’s output as I moved the joystick and pressed some buttons:

This example program shows values coming back from the USB joystick. The joystick and buttons seem to be contained in the Z bytes (Z1 and Z2).
This example program shows values coming back from the USB joystick. The joystick and buttons seem to be contained in the Z bytes (Z1 and Z2).

The joystick I am using is a “Playtech Pro Arcade Fighting Stick” sold on Amazon.com. (As of this posting, the price is $32, but it was about $26 back in December.) Moving the joystick around seemed to change bits in the Z1 value. The four arcade buttons changed bits in Z2. This joystick has a row of seven small control buttons on the top, and four of those buttons (marked Select, Start, L3 and R3) toggled the remaining four bits in Z1.

I do not know how standard USB joysticks are, but I would hope at least the joystick directions and primary buttons would be standardized. The four buttons that were different colors and labeled like Playstation controllers (triangle, circle, X, square) were the high bits of Z2, and the grey surrounding buttons (L1, L2, R1 and R2) were the lower four bits. Perhaps these grey buttons map to the front edge buttons found on console gamepads?

The iCade has a joystick and eight buttons, so I would need to figure out which of the USB buttons I would need to use.

This sample program would be the basis of my experiment. It was made of an Arduino sketch called USBHIDJoystick.pde, and two C++ files — hidjoystickrptparser.cpp and hidjoystickrptparser.h. It seemed the sketch would initialize the USB library, and specify the name of a custom function which would parse the USB data and pull out the joystick related bits. Inside the main loop() was just a call to a task handler function in the library, which I assume is the code responsible for polling and processing incoming USB data.

Inside the hidjoystickrptparser.cpp file, there was a function called OnGamePadChanged() which would print out various values. I planned to comment the print lines out, and just have it call my own button processing code which would parse the set bits rather than read digital input pins. I would just stick the Z1 and Z2 bytes together as a 16-bit integer:

void JoystickEvents::OnGamePadChanged(const GamePadEventData *evt)
{
  // Call our joystick handler...
  // We are going to combine the two Z1 and Z2 bytes in to a 16-bit value
  // for easier parsing...
  handleJoystick( (unsigned int)(evt->Z1< <8)|(evt->Z2) );

The GamePadEventData structure, defined in the .h file, contains five byte variables:

uint8_t X, Y, Z1, Z2, Rz;

I would just take the Z1, shift it to the left 8 bits, and OR in the Z2 value, creating a new 16-bit value that held both. In hex, it would look like this: 0xAABB, where AA is Z1 and BB is Z1. Now, inside my new handleJoystick() routine, I could look for those bits rather than scan digital I/O pins.

Instead of using the example sketch, I planned to just merge the USB specific items in to my existing teensy_icade sketch. This would be including some header files, and declaring some variables. The following code was lifted directly from the sample sketch:

// Header files, taken from USBHIDJoystick example.

#include
#include
 #include
 #include
 #include <usb_ch9 .h>
 #include
 #include
 #include
 #include</pre>
 <address>#include
 #include

#include "hidjoystickrptparser.h"

#include #include
 #include
 #include
 // Define some C++ stuff.
 USB Usb;
 USBHub Hub(&Usb);
 HIDUniversal Hid(&Usb);
 JoystickEvents JoyEvents;
 JoystickReportParser Joy(&JoyEvents);

Inside my setup(), I would need to include the USB specific items. Since I have not found any documentation on the USB library, I can only assume what these functions do. Usb.Init() seems clear enough (though this code still attempts to run even if it fails, which is bad), and the Hid.SetReportParser() seems to be where the calling program passes in a structure containing the handling functions that the USB code will call when it gets a joystick packet. Or something.

  // USB initialization stuff.
  if (Usb.Init() == -1)
      Serial.println("OSC did not start.");

  delay( 200 );

  if (!Hid.SetReportParser(0, &Joy))
       ErrorMessage<uint8_t>(PSTR("SetReportParser"), 1);

After this, the only other bit of code I would be borrowing was to put a call to the USB task handler inside my loop():

  // Handle USB
  Usb.Task();

Now all I needed to do was pull out my pin reading code from the loop, and make it a separate function which would now be called, not by my loop, but when the USB handler had data to process.

Since my original code used an array of bytes, each representing what pin should be read to indicate the specific direction/button was active, I decided to use the same approach with this. I would use the same button mappings, but alter the defines so that instead of containing a byte value representing a pin number, each one would be a 16-bit value representing which bit was the one for the button. It looks like this:

// We will be treating joystick as a 16-bit value.
// Extra Buttons:
#define SELECT_USB  (1< <8)  // Z1:0x0100 - Select
#define L3_USB      (1<<9)  // Z1:0x0200 - L3
#define R3_USB      (1<<10) // Z1:0x0400 - R3
#define START_USB   (1<<11) // Z1:0x0800 - Start
// Joystick:
#define UP_USB      (1<<12) // Z1:0x1000 - Up
#define RIGHT_USB   (1<<13) // Z1:0x2000 - Right
#define DOWN_USB    (1<<14) // Z1:0x4000 - Down
#define LEFT_USB    (1<<15) // Z1:0x8000 - Left
// Grey/Front Buttons:
#define BTN1_USB    (1<<0)  // Z2:0x0001 - L2
#define BTN2_USB    (1<<1)  // Z2:0x0002 - R2
#define BTN3_USB    (1<<2)  // Z2:0x0004 - L1
#define BTN4_USB    (1<<3)  // Z2:0x0008 - R1
// Primary Buttons:
#define BTN5_USB    (1<<4)  // Z2:0x0010 - "Triangle"
#define BTN6_USB    (1<<5)  // Z2:0x0020 - "Circle"
#define BTN7_USB    (1<<6)  // Z2:0x0040 - "X"
#define BTN8_USB    (1<<7)  // Z2:0x0080 - "Square"

In my original code, I called them “BTN1_PIN” or “RIGHT_PIN”, but I wanted to change the names to be more clear, and also so a future version might mix both capabilities in the same source code. My array of these items would be updated to hold 16-bit values (instead of bytes), and use the renamed defines:

// Each of these items is a 16-bit value, where the bits represent the 12
// iCade buttons.
unsigned int myPins[USB_BTN_COUNT] =
  {UP_USB, DOWN_USB, LEFT_USB, RIGHT_USB,
  BTN1_USB, BTN2_USB, BTN3_USB, BTN4_USB,
  BTN5_USB, BTN6_USB, BTN7_USB, BTN8_USB};

You can see that I also renamed a count #define to be “USB_BTN_COUNT” instead of “DI_PIN_COUNT”. The other defines I used in the original were removed, since they were just used to error check the user in case they tried to build a version using pins outside of the allowed range.

My iCade array remains the same, though it will need to be customized to map the eight USB buttons to the proper iCade buttons once I figure out what they should be.

Now the real work could begin. I ripped out the entire loop that went through the myPins[] array and made only a few changes. Instead of reading the status of a digital pin in the array, I already knew the status since I was being passed in the bit value. I would just set status to that specific bit:

void handleJoystick(unsigned int buttonMask)
{
  /*-------------------------------------------------------------------------*/
  // Loop through each Digital Input pin.
  for (int thisPin=0; thisPin < USB_BTN_COUNT; thisPin++ )
  {
    // Read the pin's current status.
    unsigned int status = (buttonMask & myPins[thisPin]);

For digital pins, you read each pin and got a LOW or HIGH value. For this, I assume multiple bits could be set at the same time (?), so I wanted to take the buttonMask passed in from the USB code and just test the specific bit pattern for the button in question. I was still looping through all 12 buttons, but now I would be checking the status of a bit pattern to a bit mask in an array, rather than reading a digital pin and storing the status of that pin.

Now status would no longer be LOW or HIGH (0 or 1), but instead would either be 0x0000 or have a specific bit set like 0x0200 or 0x8000. Instead of comparing “status==LOW” I needed to simply check against it being 0. (My Teensy wiring used “active low” so LOW meant the button was pressed, and here the bit pattern being HIGH mean it was pressed.) That change looked like this:

            // If pin is Active LOW,
            if (status!=0)
            {

(I still need to clean up the comments.)

I believe those were the only changes I needed to make, but my first test did not work. It seems my debounce code was causing some kind of issue. Since I assumed the joystick should already be doing denounce before sending out a USB packet with the button status, I tried just commenting out my debounce check and that got everything working. Almost.

The Teensy 2.0 had to be told what kind of USB device it was at compile time. A menu setting would toggle it between USB Serial, or USB Keyboard. With the Leonardo, that option did not appear in the IDE. A quick search revealed I needed to turn on the USB keyboard support in setup():

   Keyboard.begin();

Once done, I could open up a text editor (so the “typing” from the Arduino had a place to show up) and move the joystick around and see the results on the screen:

iCade keys generated by the USB joystick.
iCade keys generated by the USB joystick.

“lv” represents BTN8 pressed then released. “hr” is BTN5. “we” is UP. It worked!

Testing on the iPad was next. Unlike the Teensy 2.0, which could run from the tiny 20mah of power the iPad USB port provided, the Leonardo and USB Host shield would be more demanding. I was not sure what the rules were with using an external power supply on an Arduino — didn’t I read somewhere that you had to change something to prevent problems if it was also connected to a computer’s USB port at the same time?

To be safe, I decided to use a powered USB hub. For testing, my setup looked like this:

JOYSTICK -> Leonardo -> USB Hub -> Mac

I figured all I would have to do is unplug the hub cable from the Mac, and plug it in to the iPad using the Apple Camera Connector kit.

It worked just fine, and I soon found myself testing it on Atari’s Greatest Hits (the first official app to support the iCade) as well as Gridlee (a free arcade game which runs on the MAME emulator).

The buttons were not where they needed to be, so I will need to fix that next.

But for now, I wanted to share my initial progress. I will clean up the code and post it soon.

Part 2: From pressure mats to serial output.

See also: Part 1, Part 1b, Part 2, and Part 3.

In Part 1: How I got started with Arduino, I discussed a bit of my background and how I came to experiment with an Arduino to solve a particular problem in a haunted house attraction. We were needing something that was capable of reading a switch (like a push button), and sending out a serial message to the COM: port of a PC. Since the $200 Wal-Mart netbooks we were using were modern and had no RS232 ports, the device needed to speak USB or else we would have to use a USB to RS232 adapter, like the FTDI one I used for programming BASIC Stamps.

After a quick experiment with a coworkers Arduino, I discovered it was capable of sending out serial data via the USB port. The device appeared to the host PC as if it was a COM: port, and all one had to do was write a message out in the Arduino code:

Serial.println("Hello, world!");

My initial research about reading switches/buttons on an Arduino led me to a button tutorial on the official Arduino website. It showed that all I needed was a switch (like the pressure mats folks would step on inside the haunted house) and a 10K resistor. I was able to borrow such a resistor from our hardware lab.

Using the diagram on the tutorial site, I stuck one end of the resistor in to the GND header pin socket on the Arduino, then wrapped a wire around the other end and connected it to Pin 2. I wrapped a second wire on the same end, and then, to simulate a switch, I would plug and unplug the end of that wire in to the 5V header pin socket. Their sample code was able to read it as a switch!

During this research, I discovered that the Arduino didn’t actually need the resistor to do this. It had “pull up” resistors built in, and they could be enabled in software. A tutorial on the Digital Pins would explain this to me. Basically, you chose a pin and set it to input, then used a digitalWrite() call to enable the pullup resistor:

pinMode(pin, INPUT);     // set pin to input
digitalWrite(pin, HIGH); // turn on pullup resistor

With this, I could simple put a switch between GND and the PIN and it would work with no extra resistors needed. In fact, it looked as if we could just wire all the mat switches up to various Digital Input pins and be set.

Unfortunately, the early experimental code (see Part 1) had some issues. I will dissect it and explain:

First, I defined the range of Digital Input pins I would be using. Pins 0 and 1 were reserved for talking to the serial port (TX, transmit, and RX, receive), leaving pins 2 through 14 available. I used #define macros so I could change these pin numbers in one place without having to touch the code. I also needed the number of how many pins were in use, so I made a second macro that just subtracted the END from START to get that number:

#define DI_PIN_START 2
#define DI_PIN_END   14
#define DI_PIN_COUNT (DI_PIN_END - DI_PIN_START)

Next, I needed to know the status of each pin so I could tell if it changed. I created an array of integers to hold the status values:

int pinStatus[DI_PIN_COUNT];

For the setup routine, I would initialize each pin for input, then read the status of each pin and store it in the array. I would also initialize the serial port, based on examples from the Arduino site:

void setup()
{
  // Initialize the pins and pinStatus array.
  for (int thisPin=0; thisPin &amp;lt; DI_PIN_COUNT; thisPin++ )
  {
    pinMode(thisPin+DI_PIN_START, INPUT_PULLUP);
    pinStatus[thisPin] = digitalRead(thisPin);
  }
 
  // Initialize the serial port.
  Serial.begin(9600);
 
  while(!Serial) {
    ;
  }
}

The main loop of the program would be very simple. I would loop through each pin and read its current status. If the status was different from the saved status, I knew it changed (button pressed, or button released). Since I wanted to send out serial data to represent the pins, I chose a simple single character, with UPPERCASE meaning “button pressed” and lowercase meaning “button released”. Since I had learned that the pin status was either a 0 or 1, I used that to determine if I should print UPPERCASE or lowercase. As I looped through the pins (0 through Max), I would print the character “A” (char 65) plus the pin number (thus, 0 would be A, 1 would be B, etc.). To tell if it was upper or lower, I took the status and multiplied it by 32. In the ASCII character set, 65 is where the uppercase alphabet starts, and 97 (32 higher) is where the lowercase alphabet starts. If status was 1, I would be adding 32 to the number (status*32). If status was 0, I would be adding 0 to the number (0*32) leaving it uppercase.

It was a quick and dirty way to do it, and it looked like this:

void loop()
{
  int status = -1;

  for (int thisPin=0; thisPin &amp;lt; DI_PIN_COUNT; thisPin++ )
  {
    status = digitalRead(thisPin+DI_PIN_START);
    // Is pin status different from last time we read it?
    if (pinStatus[thisPin]!=status)
    {
      pinStatus[thisPin] = status;
      Serial.println(char((97+thisPin)-(status*32)));
    }
  }
}

This would indeed print out a series of characters based on which pin was connected. Going through all of them might produce:

AaBbCcDdEe


But, it seemed the action of making the connection would sometimes cause many characters to emit:

AaAaAaAaBbBbCcCcCc

Only if I was very quick with the connection could I prevent that. I was familiar with this problem, thanks to getting started with home computers in the early 1980s. The keyboard of my TRS-80 Color Computer was a matrix of switches, and it contained code in the BASIC ROM to do “denouncing”. Basically, it wouldn’t report that a switch was connected until it had been connected for some small amount of time. Thus, these jitters as the connection was being made would be smoothed out, and not detected.

I would need to add debounce code to my DItoSerial routine.

Until the next part, here is the Arduino tutorial on Debouncing switches. I will discuss how I did it in an upcoming posting.

Until then…

Arduino, iTead Studio USB Host shield, and libraries…

Thanks to my day job, I got my first exposure to Arduino (as well as other similar devices, like the $4.30 TI 430 Launchpad). From time to time, I will post little tidbits of things I have learned.

This is one of those times. (I post this mostly so it will end up in Google search results and maybe save someone the time I wasted trying to figure this out on my own ;-)

There is a USB Host Shield sold by iTead Studio in China. Their product retails for $24.00 (currently $21.60) and it allows the Arduino to act as a “host” and read from other USB devices such as mice, keyboards, etc.

For those unfamiliar with how USB works, there are two types of USB things… USB “device” mode is for something you would plug to a computer so the computer could use it. A printer or thumb drive supports USB device mode. The computer acts as the host, so it has a USB host port. In the 90s, when I was working for Microware, we were bringing USB support to our OS-9 embedded operating system, but initially were only doing device mode. This would let a gadget running OS-9 hook up to a PC so it could talk to it. It did not let you hook up USB devices to OS-9 (though later, this support was added for flash drives and such).

But I digress.

Why would one want a USB host shield when the Arduino already has a USB port? The USB Host shield’s USB port is a “host” port, and is different than the USB “device” port found on the Arduino. The USB port on most Arduinos is just a serial device for loading programs and input/output. It makes the Arduino appear as a serial “device” to the “host” PC. There are some boards, like the Teensy 2.0 and Arduino Leonardo, that do have USB ports than can switch between device and host mode to act be seen as a USB HID (human interface device) such as a keyboard, mouse or joystick.

As part of my expansion of the iCade joystick experiment, I wanted to get a USB Host shield that would let the Arduino read a standard USB joystick (like the $14 arcade controllers found on Amazon) and then convert that in to iCade USB keyboard messages which would be sent out a the Arduino’s built-in port, configured to appear as a USB HID keyboard. This would require an Arduino that can act as a USB HID device (Leonardo), The joystick would plug in to the USB Host shield, then the USB port of the Arduino would go to the iPad.

As mentioned, the Arduino Leonardo provides USB HID support, similar to the Teensy 2.0 I previously experimented with. Unfortunately, the iTead USB Host shield will not work with the Leonardo due to some pins being moved around. The iTead Host Shield communicates over SPI, which is a communication protocol standard. The Arduino UNO has the SPI pins mixed in with the normal digital pins, but the Leonardo moves the SPI pins to a separate small header block (2×3, if I recall) located at the center edge of the board. Thus, the Leonardo does not connect those pins to the iTead Shield.

There is a Circuits at Home USB Host shield that does have this connection, so it should work with the Leonardo. This will be discussed at a later time. For now, my Arduino UNO can hook up to the iTead shield for testing and creating the program that would ultimately need to run on a Leonardo. (Or, for a few dollars and some time, there seems to be a project that lets you hook a USB port to the Arduino and use a special library that allows it to send keyboard commands.)

For now, I will just share a few things I wondered and learned…

Arduino programs are called “sketches” and they are very C-like. The ones I see have are files that use the extension .ino.

There are also Libraries that appear to be written as C or C++ files, ending with typical .c, .h, and .cpp extensions. The iTead Studio USB Host shield came with a .zip file of a USB implementation like this, but absolutely no documentation on what to do with it.

I was not sure how to compile C code, and casual searches didn’t prove helpful. The IDE refused to open a .c file, but would let you drag-and-drop one in to the editor. Building it didn’t work.

I was able to find a more current version of the USB Host library on github.com, but still didn’t know what to do with it.

Last night, after reading a reference on how to add a Library to the Arduino, I apparently figured it out. It seems all I had to do was drag the USB Host source directory in to the “library” folder of the Arduino IDE. (On a Mac, it was in ~/Documents/Arduino/library). Once I did this, I could open the included USB example sketches (.pde extension, for some reason) and build them… There were some minor problems along the way, like having to remove any spaces or special characters from the library folder name (how quaint), and then some conflicts with having the iTead library files installed (I ended up removing them), but the end result was building the test USB code and getting to try it out on an Arduino UNO using the iTead shield.

Wow. That was easy.

To be continued…

Part 1b: A few more notes…

See also: Part 1, Part 1b, Part 2, and Part 3.

In an earlier post, I shared some source code for a Teensy 2.0 that would use digital input pins to read an Atari 2600 joystick and output USB keyboard characters in iCade format. You may notice that this source code is vastly different than the simple “first thing I ever wrote on an Arduino” I just posted. The current source code incorporates debouncing, statistics, and is easily configurable from some defines and arrays.

Over the next few posts on this subject, I will share the two versions of source that connect my first trial to the current Teensy iCade source code. I have installed a code formatting plug in to this blog which should make the code display a bit nicer. I have even gone back and hand edited the previous posts to clean up the existing source, and fix some HTML nastiness that the software I am using wasn’t smart enough to prevent.

I should also note that, while I am new with Arduino, I am not new with programming embedded devices. I used to work for a company called Microware that made an embedded, multi-user, real-time operating system called OS-9. Before I began work there in 1995, I spent my youth programming 8-bit home computers like the Tandy/Radio Shack TRS-80 Color Computer. After all these years of feeling like technology has passed me by, I suddenly find myself back in a world where a tiny micro like the Arduino (or the TI MSP430s I program on at my day job) feels right at home.

Maybe one day I will learn how to program Android and iOS apps, but until then, there are still plenty of unused bits in these tiny computers to exploit.

More to come…

Part 1: How I got started with Arduino.

See also: Part 1, Part 1b, Part 2, and Part 3.

I remember hearing about some open-source hardware platform with a weird name a few years ago, but at the time I had little interest. I thought my hardware days were behind me, and even when they weren’t, I was never really in to hardware that much beyond soldering cables and making simple circuits. This is the story of how all this changed.

But first, allow me to regress…

In September 2012, I was helping out at a local haunted house at Sleepy Hollow Sports Park in Des Moines, Iowa. My association with them began in 2004 when they were starting to work with Festivals International to build the permanent home of the Des Moines Renaissance Faire. When they found out I was a “computer guy,” I was asked if I knew much about electronics and automation. This led me to building prop controller boxes (based on the EFX-TEK Basic Stamp Prop-1 boards) for their haunted houses.

My little boxes, built using as much off-the-shelf RadioShack stuff as possible (to allow for quick local repairs if needed), would trigger 12V solenoids that controlled pneumatic pistons to move various props or figures. We built a motion-activated gas chamber prop (complete with gas, lights, and several animations including standing up), and several other pop-up type figures. The first test-run of the gas chamber prop can be found on YouTube:

It was a great learning experience, and I wrote a BasicStamp program that allowed multitasking two (or more) prop sequences in the same box. I later found out this was written about by Jon Williams in an article found in Nuts and Volts magazine (available here as a PDF file, though he misspells my name). If there is ever any interest in BasicStamp programming, I would be happy to share more on those projects as well.

Anyway, I didn’t really do anything again with hardware until last year, instead focusing more on audio and video effects. In 2011, Sleepy Hollow brought on a local hauntrepenuer named Nathaniel who had been doing very elaborate backyard haunts in Urbandale, Iowa for years. Nathaniel introduced us to PC-based show control systems. We tested out his system by converting the “Torture Chamber” museum at the Renaissance Faire in to a computer controlled light and sound tour… And suddenly had lines never seen before at the attraction. A pre-opening test video can be found on YouTube:

The wiring of lights and speakers in the torture chamber was just the beginning. We continued to wire up the entire haunted castle (which was not open during the Renaissance Faire) and had our own Haunted Mansion style experience that October, complete with a ghostly narrator that followed guests from room to room. A duplicate computer system was used to run a pre show and some lighting effects at a new laser tag zombie shootout attraction. It was a ton of work, but a great learning experience.

And that’s where the Arduino came in. Or would, a year later.

In 2012, we did further upgrades to the torture chamber, haunted castle, and zombie shootout, and even added an all-new haunted house. The hobbyist-grade software we were using was already having difficulties keeping up. We had encountered several issues with it the past season, so we began to explore various other options. We even evaluated some high end professional products like Venue Magic. Unfortunately, there wasn’t a budget for something like that so we had to make due with cheap netbooks and whatever we could cobble together.

However, during our evaluation of Venue Magic (initially in a trial “runs forever, but cannot save” mode), I started exploring how it handled inputs. It did not support any of the input hardware we already had, so we looked in to some other solutions (in the $150 price range). They all seemed expensively complex for our needs. The cheap interfaces we had acted like simple USB serial devices, sending serial data when a switch was triggered… which gave me an idea.

At work, someone had an old Arduino Duemilanove. I borrowed it over lunch and found that it could easily act as a USB serial device, and quickly had something hacked together that would read the status of the digital input pins and emit a letter for each pin triggered. My original code looked something like this:

#define DI_PIN_START  2
#define DI_PIN_END    14
#define DI_PIN_COUNT  (DI_PIN_END-DI_PIN_START)

int pinStatus[DI_PIN_COUNT];

void setup()
{
  // Initialize the pins and pinStatus array.
  for (int thisPin=0; thisPin < DI_PIN_COUNT; thisPin++ )
  {
    pinMode(thisPin+DI_PIN_START, INPUT_PULLUP);
    pinStatus[thisPin] = digitalRead(thisPin);
  }

  // Initialize the serial port.
  Serial.begin(9600);

  while(!Serial) {
    ;
  }
}

void loop()
{
  int status = -1;

  for (int thisPin=0; thisPin < DI_PIN_COUNT; thisPin++)
  {
    status = digitalRead(thisPin+DI_PIN_START);
    // Is pin status different from last time we read it?
    if (pinStatus[thisPin]!=status)
    {
      pinStatus[thisPin] = status;
      Serial.println(char((97+thisPin)-(status*32)));
    }
  }
}

On startup, it would read and store the current state of each pin, then in a loop, if a pin changed, it would print either an UPPPERCASE or lowercase letter, based on the pin. Pressing and releasing the first pin would send “A” then “a”, for example. This proof-of-concept showed it would work, and I went down to Radio Shack and purchased my own Arduino Duo to begin experimenting.

I will share more code in future posts, and explain how that simple bit of code turned into something much more elegant.

To be continued…

Fix a 1998 Furby that won’t wake up or start up (without disassembly)

  • 12/2014 Update: I keep planning to take some pics of the “screw thing” to post with this, but keep forgetting. Sorry about that.
  • 11/2015 Update: This is the most viewed article on my site. Who knew there were so many folks out there with bad Furbys!
  • 12/2016 Update: A year later, and folks are still finding this article. There were about 300 views of it on Christmas day. Retro presents, I guess?
  • 01/24/2017 Update: Commenter Samuel submitted a photo of the gear. It doesn’t look like the spiral gear I remember, so either there is another gear I missed, or there was a variation of the Furby
  • 3/5/2026 Update: Today I shut down my old appleause.com blog and moved the content here. Welcome, Furby rescuers!

If your old Furby won’t wake up or won’t start up and appears dead, you may be able to fix it in a few seconds without having to take it apart.

I recently tried to get my original 1998 Furby to work, and found that it was dead. I spent some time doing unsuccessful web searches, with none of the tips (“try new batteries”, “press the reset button”) helping. A second Furby has the same issue, and it looked like it might be related to a jammed motor, per this tutorial:

http://www.instructables.com/id/Push-Start-a-Comatose-Furby/

This procedure involved all kinds of disassembly, sewing things back together and hot glue. A similar YouTube video shed more light on the problem off the stuck motor:

http://youtu.be/fNaNM4_fKTo

I suspected you could just get to the motor using a small screwdriver and going in around the eye or beak, and indeed, it works. I was able to use a tiny flathead screwdriver, inserted above the beak and in to the left to gently rotate the corkscrew spiral connected to the motor a few times and within seconds, the Furby was alive again. Both units were fixed this easy, with no disassembly required.

Update: Thanks to Samuel (http://twitter.com/samsearight), we now have a photo. On my Furby, there is a corkscrew spiral gear I moved, and not this normal gear. I don’t know if the gear is also in mine or if this is a different revision. It looks easier to work with than the gear I found in mine. Thanks, Samuel!

Teensy 2.0 iCade source code

(Edited on 02/12/2013 to fix the source code formatting, and to add a photo.)

NOTE: There is a native method of compiling code for the Teensy, using a C compiler, but this source code was built using the Teensyduino add-on. It enables the standard Arduino IDE GUI to build code for the Teensy. You have to install the Arduino IDE first, then you install the Teensyduino add-on on top of it.

“As seen on the Teensy Project Page.”

Teensy 2.0 as an Atari 2600 joystick interface for iOS

This is my source code for the Teensy 2.0 iCade/Atari joystick interface. It could easily be made to work on an Arduino that has USB HID support (Arduino Leonardo, Esplora) and enough digital I/O pins. It is a bit bulky because I emit various status messages for testing, but I will at some point provide a stripped down version. I also have a version that uses the Debounce library which appears even smaller, but I like completely self-contained code where possible.

I have not got back to clean this up, so it includes some items commented out and such, but I wanted to provide this for those asking about it.

Or, this code could be modified to run on the new Arduino Esplora, which already has joystick buttons on it and USB HID output to act like a keyboard/mouse to whatever it’s hooked up to:

http://www.radioshack.com/product/index.jsp?productId=18450286#

Keep in mind, the Teensy 2.0 is a low power device and it seems the 20mah of the iPad is enouhg to power it (running in low power mode, no LEDs, etc.). This may not be the case with an Arduino, and they may require hooking up via a powered hub before connecting to the iPad.

//*-----------------------------------------------------------------------------

Teensy iCade Input
by Allen C. Huffman (alsplace@pobox.com)

Monitor digital inputs, then emit a USB keyboard character mapped to an iCade
button depending on the pin status. The character will be the "hold" character
for pin connected (N.O. button push) and "release" character for pin
disconnected (N.O. button released).

Pin 11 is reserved for blinking the onboard LED as a heartbeat "we are alive"
indicator.

This software was written to allow a Teensy 2.0 to interface between arcade
buttons and an iPad via USB and Camera Connector Kit.

2012-12-04 0.0 allenh - Initial version, based on my ArduinoAIDI code.

-----------------------------------------------------------------------------*/
#define VERSION "0.0"
#define LED_OFF

//#include <eeprom .h>
//#include <avr/wdt.h>

/*
iCade keyboard mappings.
See developer doc at: http://www.ionaudio.com/products/details/icade

WE     YT UF IM OG
AQ< -->DC
XZ     HR JN KP LV

Atari joystick port, looking at the male DB9 on the Atari.
See: http://old.pinouts.ru/Inputs/JoystickAtari2600_pinout.shtml

1 2 3 4 5/  Up Dn Lt Rt PA
6 7 8 9/    Bt +5  Gd PB
*/

/*
The following I/O pins will be used as digital inputs
for each specific iCade function.
*/
#define UP_PIN 0
#define DOWN_PIN 1
#define LEFT_PIN 2
#define RIGHT_PIN 3
#define BTN1_PIN 4
#define BTN2_PIN 5
#define BTN3_PIN 6
#define BTN4_PIN 7
#define BTN5_PIN 8
#define BTN6_PIN 9
#define BTN7_PIN 10
#define BTN8_PIN 12

/*
The following keys are the iCade sequence (hold, release)
for each function. Send "W" to indicate UP, and "E" when
UP is released.
*/
#define UP_KEYS "we"
#define DOWN_KEYS "xz"
#define LEFT_KEYS "aq"
#define RIGHT_KEYS "dc"
#define BTN1_KEYS "yt"
#define BTN2_KEYS "uf"
#define BTN3_KEYS "im"
#define BTN4_KEYS "og"
#define BTN5_KEYS "hr"
#define BTN6_KEYS "jn"
#define BTN7_KEYS "kp"
#define BTN8_KEYS "lv"

#define DI_PIN_COUNT 12 // 12 pins used.
#define DI_PIN_START 1  // First I/O pin.
#define DI_PIN_END 20   // Last I/O pin.

byte myPins[DI_PIN_COUNT] =
{UP_PIN, DOWN_PIN, LEFT_PIN, RIGHT_PIN,
BTN1_PIN, BTN2_PIN, BTN3_PIN, BTN4_PIN,
BTN5_PIN, BTN6_PIN, BTN7_PIN, BTN8_PIN};

char iCadeKeymap[][DI_PIN_COUNT] =
    {UP_KEYS, DOWN_KEYS, LEFT_KEYS, RIGHT_KEYS,
     BTN1_KEYS, BTN2_KEYS, BTN3_KEYS, BTN4_KEYS,
     BTN5_KEYS, BTN6_KEYS, BTN7_KEYS, BTN8_KEYS};

char iCadeDesc[][DI_PIN_COUNT] =
    {"Up", "Down", "Left", "Right",
     "Btn1", "Btn2", "Btn3", "Btn4",
     "Btn5", "Btn6", "Btn7", "Btn8"};

/* We want a very short debounce delay for an arcade controller. */
#define DI_DEBOUNCE_MS 10 // 100ms (1/10th second)

#define LED_PIN 11
#define LEDBLINK_MS 1000

/*---------------------------------------------------------------------------*/

/* For I/O pin status and debounce. */
unsigned int digitalStatus[DI_PIN_COUNT];        // Last set PIN mode.
unsigned long digitalDebounceTime[DI_PIN_COUNT]; // Debounce time.
// unsigned long digitalCounter[DI_PIN_COUNT];         // Times button pressed.
unsigned int digitalDebounceRate = DI_DEBOUNCE_MS; // Debounce rate.

/* For the blinking LED (heartbeat). */
unsigned int ledStatus = LOW;            // Last set LED mode.
unsigned long ledBlinkTime = 0;          // LED blink time.
unsigned int ledBlinkRate = LEDBLINK_MS; // LED blink rate.

unsigned int pinsOn = 0;

/*---------------------------------------------------------------------------*/

void setup()
{
    // Just in case it was left on...
    // wdt_disable();

    // Initialize the serial port.
    Serial.begin(9600);

    // Docs say this isn't necessary for Uno.
    // while(!Serial) { }

    showHeader();

    // Initialize watchdog timer for 2 seconds.
    // wdt_enable(WDTO_4S);

    // LOW POWER MODE!
    // Pins default to INPUT mode. To save power, turn them all to OUTPUT
    // initially, so only those being used will be turn on. See:
    // http://www.pjrc.com/teensy/low_power.html
    for (int thisPin = 0; thisPin < DI_PIN_COUNT; thisPin++)
    {
        pinMode(thisPin, OUTPUT);
    }

    // Disable Unused Peripherals
    ADCSRA = 0;

    // Initialize the pins and digitalPin array.
    for (int thisPin = 0; thisPin < DI_PIN_COUNT; thisPin++)
    {
        // Set pin to be digital input using pullup resistor.
        pinMode(myPins[thisPin], INPUT_PULLUP);
        // Set the current initial pin status.
        digitalStatus[thisPin] = HIGH; // digitalRead(thisPin+DI_PIN_START);
        // Clear debounce time.
        digitalDebounceTime[thisPin] = 0;
        // digitalCounter[thisPin] = 0;
    }

    // Set LED pin to output, since it has an LED we can use.
    pinMode(LED_PIN, OUTPUT);

    Serial.println("Ready.");
}

/*---------------------------------------------------------------------------*/

void loop()
{
    // Tell the watchdog timer we are still alive.
    // wdt_reset();

#ifndef LED_OFF
    // LED blinking heartbeat. Yes, we are alive.
    if ((long)(millis() - ledBlinkTime) >= 0)
    {
        // Toggle LED.
        if (ledStatus == LOW) // If LED is LOW...
        {
            ledStatus = HIGH; // ...make it HIGH.
        }
        else
        {
            ledStatus = LOW; // ...else, make it LOW.
        }
        // Set LED pin status.
        if (pinsOn == 0)
            digitalWrite(LED_PIN, ledStatus);
        // Reset "next time to toggle" time.
        ledBlinkTime = millis() + ledBlinkRate;
    }
#endif

    // Check for serial data.
    if (Serial.available() > 0)
    {
        // If data ready, read a byte.
        int incomingByte = Serial.read();
        // Parse the byte we read.
        switch (incomingByte)
        {
        case '?':
            showStatus();
            break;
        default:
            break;
        }
    }

    /*-------------------------------------------------------------------------*/

    // Loop through each Digital Input pin.
    for (int thisPin = 0; thisPin < DI_PIN_COUNT; thisPin++)
    {
        // Read the pin's current status.
        unsigned int status = digitalRead(myPins[thisPin]);

        // In pin status has changed from our last toggle...
        if (status != digitalStatus[thisPin])
        {
            // Remember when it changed, starting debounce mode.
            // If not currently in debounce mode,
            if (digitalDebounceTime[thisPin] == 0)
            {
                // Set when we can accept this as valid (debounce is considered
                // done if the time gets to this point with the status still the same).
                digitalDebounceTime[thisPin] = millis() + digitalDebounceRate;
            }

            // Check to see if we are in debounce detect mode.
            if (digitalDebounceTime[thisPin] > 0)
            {
                // Yes we are. Have we delayed long enough yet?
                if ((long)(millis() - digitalDebounceTime[thisPin]) >= 0)
                {
                    // Yes, so consider it switched.
                    // If pin is Active LOW,
                    if (status == LOW)
                    {
                        // Emit BUTTON PRESSED string.
                        Serial.print(iCadeDesc[thisPin]);
                        Serial.print(" pressed  (sending ");
                        Serial.print(iCadeKeymap[thisPin][0]);
                        Serial.println(" to iCade).");
                        Keyboard.print(iCadeKeymap[thisPin][0]);
                        // digitalCounter[thisPin]++;
                        pinsOn++;
#ifndef LED_OFF
                        digitalWrite(LED_PIN, HIGH);
#endif
                    }
                    else
                    {
                        // Emit BUTTON RELEASED string.
                        Serial.print(iCadeDesc[thisPin]);
                        Serial.print(" released (sending ");
                        Serial.print(iCadeKeymap[thisPin][1]);
                        Serial.println(" to iCade).");
                        Keyboard.print(iCadeKeymap[thisPin][1]);
                        if (pinsOn > 0)
                            pinsOn--;
                        if (pinsOn == 0)
                            digitalWrite(LED_PIN, LOW);
                    }
                    // Remember current (last set) status for this pin.
                    digitalStatus[thisPin] = status;
                    // Reset debounce time (disable, not looking any more).
                    digitalDebounceTime[thisPin] = 0;
                } // End of if ( (long)(millis()-digitalDebounceTime[thisPin]) >= 0 )

            } // End of if (digitalDebounceTime[thisPin]>0)
        }
        else // No change? Flag no change.
        {
            // If we were debouncing, we are no longer debouncing.
            digitalDebounceTime[thisPin] = 0;
        }
    } // End of (int thisPin=0; thisPin < DI_PIN_COUNT; thisPin++ )
}

/*---------------------------------------------------------------------------*/

void showHeader()
{
    int i;
    // Emit some startup stuff to the serial port.
    Serial.print("iCadeTeensy ");
    Serial.print(VERSION);
    Serial.println(" by Allen C. Huffman (alsplace@pobox.com)");
    Serial.print(DI_PIN_COUNT);
    Serial.print(" DI Pins (");
    for (i = 0; i < DI_PIN_COUNT; i++)
    {
        Serial.print(myPins[i]);
        Serial.print("=");
        Serial.print(iCadeDesc[i]);
        Serial.print(" ");
    }
    Serial.print("), ");
    Serial.print(digitalDebounceRate);
    Serial.println("ms Debounce.");
}

/*---------------------------------------------------------------------------*/

void showStatus()
{
    showDigitalInputStatus();
}

/*---------------------------------------------------------------------------*/

void showDigitalInputStatus()
{
    Serial.print("DI: ");

    for (int thisPin = 0; thisPin < DI_PIN_COUNT; thisPin++)
    {
        // Read the pin's current status.
        Serial.print(iCadeDesc[thisPin]);
        Serial.print("=");
        Serial.print(digitalRead(myPins[thisPin]));
        Serial.print(" ");
        // Serial.print(" (");
        // Serial.print(digitalCounter[thisPin]);
        // Serial.print(") ");
    }
    Serial.println("");
}

/*---------------------------------------------------------------------------*/

// End of file.

Apple Maps: Your milage may vary.

I just read a reference to Apple’s “struggling” map software. Like many things that get “reported” in the blogosphere, they are often repeating the echo chamber of things observed or researched by others, or they are sharing one tiny sliver of experience as fact as if everyone experiences it the same way.

When it comes to Apple Maps on iOS 6, I must say, I am quite impressed. You see, there is a small connecting road on the East side of Des Moines that my 2005 Toyota Prius navigation system never knew about. It would always route many blocks out of the way to go around it.

My 2007 navigation system, likewise, also did not know about. And neither did an additional map update I purchased for it at great cost.

My 2010 3rd generation Prius navigation system also does not seem to think it exists, nor did a map update for it.

Two TomTom models, years apart, do not know it exists, even after being reported with the community “suggest corrections” feature TomTom brags about.

I believe I even tested a Magellan navigation unit to find it also did not know about this road.

Surprisingly, to me, the one map that did have it was OpenStreetMaps – the open source wikipedia of maps. Amazing that they knew about this road, while Google, Navtec, TomTom, etc. did not seem to believe that it existed — even though it had been there for ages.

Google, today, does show this section of the road, but I believe that was not the case a few years ago.

And Apple Maps also shows it. Not only that, but Apple Maps can correctly navigate me from my housing area to the Main Street without jumping me through the forest nearby like everything else does. None of the systems I have used had the connecting driveway that links my area with the road, so they often jump to the closest pavement they can find, which is over the river and through the woods.

Apple Maps is the first map software I have used that correctly pinpoints where I live, and knows how to get there without just getting close.

So from my perspective, it’s a huge improvement over many other maps I have used and reviewed over the years.

But your milage may vary.

20130102-122209.jpg

Hook an Atari 2600 joystick up to an iPad, thanks to Teensy 2.0

  • 2014/03/16 Update: The source code to this is now on GitHub. Check the Arduino link at the top of each page of this site.

“As seen on the Teensy Project Page.”

I recently gained some experience using Arduinos to control inputs in a local haunted house attraction, and that has opened up quite a world of projects. During my research, I learned about the Teensy 2.0, a cheap (starting at $16, http://www.pjrc.com/teensy/index.html) controller that is similar to Arduino, but had more I/O pins than the Arduino Uno, plus had the ability to act like a USB keyboard or mouse. This enables it to send keystrokes or mouse movements/clicks to a computer, as if it were receiving them from an input device.

So, using the $19 version of Teensy 2.0 (that has header pins) and some wires, I was able to connect my Atari Flashback 2 joystick to an iPad via the USB adapter. I wrote a small program that reads the I/O pins of the Teensy 2.0, then sends out USB keyboard commands that emulate the iCade arcade controller.

My project was noted on the Teensy 2.0 project page:

http://www.pjrc.com/teensy/projects.html

I will be posting full notes and the code as soon as I have a moment to work on it.

Teensy 2.0 as an Atari 2600 joystick interface for iOS