The board design for the SNES wireless controller project is proceeding nicely. I recently finished the main controller schematic, after running into multiple difficulties about how exactly to implement its electronics. Next up: laying out the circuit board. This presented its own set of challenges, which eventually led to me developing a powerful tool for simplifying the layout of complicated circuit boards.

One of the problems we faced when designing the schematic for the wireless SNES controller, is whether to leave the original PCB in, or fabricate a complete replacement. Implementing the controller on a smaller circuit board would make it cheaper to manufacure: most PCB prototyping companies bill by the square inch. However, using a smaller board would result in an extremely cramped layout, and might require physical modification of the plastic supports on the inside of the circuit board. Instead, we decided to replace the entire PCB. As we had already decided this project was for fun, money was no object. Also, the larger amount of space on the bigger board makes it easer to route the circuit. Unfortunately, there is one more downside to the full PCB approach: the replacement PCB must fit exactly into the space left by the older board. This led to another issue: the PCB will only fit in a single brand of SNES Controller.

Many classic arcade and console video games can be played with a D-pad. While one can use modern controllers with these programs, they lack the elegance of the older designs. However, if one uses one of these older controllers with a USB adapter, one is forced to be tethered to the computer.

Wireless SNES controllers have been done before. However, they usually don't pay close attention to power usage, and none support multiple controllers using a single interface.

The purpose of this project then, is to develop a low latency, ultra-low power device to interface with the original SNES hardware, and connect it to a modern PC. This device must be relatively cheap to manufacture, use components that are currently being manufactured, support multiple devices without interference, and must minimally modify the hardware. Additionally, it should use techniques developed for packet radio to allow for multiple transmitters on the same channel.

Suppose you have an old joystick that you want to use to control your latest micro-controller project. These joysticks use a DB-15 connector with a readily available pinout. A Game Port style joystick consists of digital buttons, and analog axes. In this post, I will go over how to optimally interface the axes of these types of joysticks with your microcontroller.

Inside of the joystick, mounted at right angles are potentiometers, one for each axis:

Recently I took a class on Embedded Systems at Portand State University, and was required to program a bare metal ARM development board. This is a continuation of my notes on how to program the board. You can read the first part here.

In order for this development environment to work, we need to implement the syscalls that newlib will use for the C standard library. Most of the required syscalls are necessary in order to access abstractions that wont make sense on the development board. For example, with a concept of a process, there is no need for the fork() system call. In fact, the only system call we really need to implement is sbrk().