RGB Matrix Portable Handheld Gaming Console

Student: Alexander Thomas, Year 2

1.0 Introduction

The RGB Matrix project was created as an attempt to redesign the current ‘Pixel Gaming’ console, a small handheld gaming device used to teach PCB design to first year students at Manchester University EEE.

1.1 The Pixel Gaming Console

The existing Pixel Gaming Console consists of an 8*8 RGB LED screen for the game display, eight extra RG LEDs to store the current game status information such as the number of lives or a time remaining, makes use of a piezo-crystal sounder, is controlled by a PIC18F4520-I/PT microcontroller and is interfaced with via six button controls and/or an analogue accelerometer.

By using the PIC microcontroller, the Pixel Gaming Console is able to be reprogrammed and therefore students can build, test and create multiple games for the console. The reprogrammable nature of the PIC via the ICSP circuit allows the device to undergo a complete software change without being removed from the board. The device can also be connected to other games consoles using the USART (Universal Synchronous/Asynchronous Receiver-Transmitter) peripheral on the PIC for multiplayer gaming.

1.2 The Re-Design Concept

The existing Pixel Gaming Console design that the first year PCB design process utilises consists of a PCB approximately 103mm width by 115mm in height; the RGB LED screen used in the design is in fact only 60mm x 60mm. These differences in dimensions mean that once the screen is mounted onto the PCB, a lot of the board remains in plain view.

The initial idea of the redesign was to largely reduce the size of the device by fitting all of the components underneath the screen area. By reducing its size to this extent we would then make use of battery power to allow device portability (The existing design makes use of mains power at approximately 5VDC) and it will be used as a fascinating attraction on university open days to impress prospective students.

By seeing a fully functional compact gaming device that makes use of tilt sensing functionality similar to that used in iPhone games, that was created by a first year student at Manchester University, the amount of experience and high standard of teaching students receive at UoM EEE would be much more easily conveyed to prospective students. The final aspect of the re-design concept was to increase its ability as a ‘Pick up and play’ device.

It was decided that the device would make use of a tilt switch circuit to notify the PIC of when it was being picked up and then get it to spring to life out of sleep mode. This would not only act as a surprising and interesting feature but would also reduce power consumption as the battery charge would essentially only be drained when the device was being used, which would optimise the battery life of the device enormously.

2.0 Design Specification

2.1 Design Specification

Reproduce functional Pixel Gaming Console at a far reduced size.

Make use of the PIC18F4520 microcontroller for system control.

Must be a battery powered device.

Must limit power consumption wherever possible.

Must make use of through-hole and SMT components. (To show a good range of technology use).

Must be a ‘Pick up and play’ device.

2.2 Preliminary Design Choices

From very early on in the project it was clear that by trying to fit all of the components underneath the screen, it would be extremely difficult to fit them all onto a single PCB. To overcome this problem, the use of multiple PCBs, essentially separating the device into different layers, would be connected via PCB connectors. By stacking each layer on top of each other, all of the board circuitry would still remain hidden underneath the screen whilst also easing the routing and soldering process enormously.

The eight extra LEDs to keep score which were used on the original Pixel Gaming design would be removed for this project. This is because the only place that they could be mounted would be underneath the board; this means that the player would have to tilt the design in order to see their score which would either obscure the screen during game play or cause an accidental game action due to the accelerometer.

3.0 PCB Development

3.1 Layer 1

Each schematic has been separated into its respective layer; therefore the components depicted in these schematics are placed on a particular PCB and have established connections dependant on their PCB header pin connections.

This layer rests on top of the battery supply so firstly the voltage needed to be rectified in order to allow the circuit to function properly. The PIC microcontroller operates at 3.3V therefore I needed to use the correct voltage regulator which maintained this constant output voltage whilst also being able to compensate for the voltage swings the battery supply provides; as when fully charged the batteries can supply a maximum of 4.8V and at a minimum approximately 3.6V; so the voltage regulator U3 needed to function within these limits. You can also see that I have made use of capacitors in this circuit, these have been used to ensure enough charge can be delivered to the circuit during times of maximum operation.

Some special pre and post capacitors were used to ensure an appropriate level of voltage regulation (The 0.47uF and 33uF capacitors), whilst the smaller 100nF capacitors are used to ensure efficient quick charge delivery as explained earlier. These capacitors are optimum for this application as they have a very small time constant, although they cannot build up as much charge; this is why I have used a large amount.

I have also created two connection paths for voltage level for an unregulated and regulated supply of voltage to the circuit. As this is a portable device I needed to minimise power dissipation as much as possible, therefore by using the unregulated supply for circuit components which can function at voltages greater than 3.3V I have used a separate circuit connection path which will reduce the voltage drop over the voltage regulator. The voltage regulator chosen, the LM3940IT by National Semiconductor consisted of the perfect balance between low drop out voltage and voltage threshold between the battery supply limits.

Above you can also see the tilt switch circuit which emphasises the device’s ability for ‘Pick up and play’ responsiveness. The three tilt switches connected in series are actually separated by 120 degrees on the board, to detect a good range of movements. The tilt switches are normally connected and when the circuit is lifted and tilted in one of these directions greater than 15 degrees, the circuit is broken connecting the PIC interrupt pin to 3.3V.

By programming the PIC to go into sleep mode, were it only consumes nanowatts of power, we can allow the device to to ‘Wake up’ out of sleep mode when this pin is connected to 3.3V using interrupts, therefore eliminating the requirement for the PIC to poll this pin as the input will propagate through combinatorial logic. By using a large series resistor I’ve been able to reduce the current that flows through these devices to minimise wasted power whilst the device is in sleep mode.

I’ve also made use of a 330Ω resistor in series to the pin connection in order to prevent a damaging amount of current flow if the interrupt pin was actually set to output a voltage down through the very low connection path to ground rather than set as an input port to read the tilt switch states. As you can see from the diagram, these tilt switches would not be sufficient to use as control for the device as they do not indicate direction of tilt; even if these switches were used separately they still could not be used in place of the accelerometer as they do not indicate the amount of tilt the device is subject to.

This schematic also lies on the first layer of the device. All of the components shown here are used in the original Pixel Gaming design, however I have made use of a surface mount PIC18F4520-I/PT device to reduce space consumption; in the original device, the PIC18F4520-L/P is used which is a lot larger. You can see the connection paths I routed between PCB layers through the PCB connectors SK* to allow interaction with components on upper layers. The board also makes use of both a 10MHz crystal oscillator as well as a 32.768kHz oscillator, to allow the device to clock at both high speed and exactly one second respectively.

The ICSP circuit (Header P1A) is used to reprogram the firmware of the PIC microcontroller; this allows the PIC to be reprogrammed via a PICkit/In Circuit Debugger via a header on the first layer. The accelerometer circuit is connected through to the PIC via an ADC port pin, allowing the PIC to determine via an analogue voltage the extent to which it is being tilted. Each of these data paths are connected through 3n3F capacitors in order to smooth the input signals from the accelerometer to allow the gaming device to respond to cleaner signals to prevent a buggy response. Finally there is a sound circuit making use of a piezoelectric crystal sounder, using an NPN transistor in order to allow sufficient current flow to attain a loud enough sound when used.

3.2 Layer 2

This circuit represents half of the second layer of the games console redesign. Above are the three Maxim LED drivers, which take their data and control from the PCB connectors connected through to the PIC. I have shown above an example of one of the PCB connectors pin layout to demonstrate the connection ordering in order to properly interact with the layer below (See the previous schematic, SK4 connects to SK2).

These LED drivers output signals which connect through another set of PCB connectors to the top layer which holds the screen. By using three of these LED drivers in series, each with 8 output pins, a 24 bit value must be written to these LED drivers, 8 bits per driver, via the Din connection in order to define whether or not current can flow through a connection path or not; essentially by writing a logic 1/0 to an individual pin will inhibit/allow current flow by defining a particular potential difference or not across the LEDs.

As each individual LED on the screen actually contains three smaller LEDs, RED, GREEN and BLUE, the outputs from these drivers allow the user to program a range of different colours per LED including; OFF, WHITE, RED, YELLOW, GREEN, BLUE, CYAN, MAGENTA by using different bit patterns.

The clk, LEna and OEna signals are used to control operation of the drivers by defining latching operations and device speed. Again, numerous capacitors have been used here to allow sufficient currents to flow during intense device operation, including small time constant 100nF capacitors and a large 33uF capacitor which possesses a larger time constant which prevents it from quickly distributing charge, however it builds up a lot more charge which can help alleviate the workload of the quickly draining 100nF capacitors.

Above shows the connection paths from the PIC microcontroller to each row of LEDs (Only four paths have been shown out of the total eight). We can show individual colours for each LED depending on the driver pattern propagated through Din described earlier by multiplexing the screen. Therefore, only by assigning particular LED driver binary values to particular rows one at a time we can achieve a full RGB screen; each row of LEDs must be turned off except for one which has a potential difference across it, then the appropriate LED driver data is configured to create the correct colour pattern. The row is then turned off the next row is then configured. As the PIC operates at such a high speed, this multiplexing effect is imperceptible to the human eye which can only detect flashing at frequencies lower than approximately 60Hz, thus creating the illusion of a constantly lit screen.

Frequencies less than this and the viewer can begin to detect the flashing effect of the screen; therefore the multiplex rate is key for device operation. Through the connections to the LEDs themselves, I have produced a small complementary bipolar junction transistor circuit. Although the transistors provide power amplification, they were also required in order to allow the screens to turn off and on properly. As we are controlling the PIC from a regulated supply and the screen from an unregulated supply, the transistors would never be able to either off or on depending on their type due to one power supply being higher than the other. By using this complementary switching circuit, applying 0V to the PIC connection pin cuts off the NPN transistor which in turn prevents operation of the PNP transistor connected through to the unregulated supply, however by applying 3.3V to the pin allows both the NPN and PNP transistors to operate in their active regions and switch accordingly, whilst also providing enough power amplification to power the power hungry LED matrix.

3.2 Layer 3

This schematic for the final layer of the device, the top layer holding the LED matrix, shows the interactions between both the PIC row connections and the LED driver outputs. This should emphasise the method of operation of the matrix operation between the PIC complementary transistor circuit and the LED driver outputs.

4.0 Testing

I have been testing the final circuit firstly through simple voltage and current analysis and after I am convinced that the design works as I intended, I will then move on to programming the design with a few tilt based games such as Labyrinth, Snake and Frogger.

Overall I am very pleased with the outcome of this design; the only problem that I have come across so far is that even after spending all of this time trying to constrain to proper widths and heights of the components I never took into account that the ICSP connector may not be able to fit on to the board in this fashion (Shown below) and I have subsequently had to add an extension to the header.

5.0 Summary

I would like to thank Manchester University for giving me this fantastic opportunity to experience circuit design. The amount of experience I gained from this project was more than I could have ever imagined and I would like to thank Peter R. Green and all of the EEE staff who provided me with the support I needed, even during the darkest hours of rooting through seemingly endless component catalogues.