Let your code do the wiring


The image above shows two implementations of the same gaming system (ArcadeSlam). The display has a parallel data interface and the left hand version maps this interface to the 8 bits of a single I/O port on the MSP430 MCU.  A simple write to the port data register is sufficient to write a byte to the display.  From a programming perspective this is easy but, as you can see, the wiring is a little complex.

The version on the right makes use of the connections within the breadboard to connect the display data interface to the MSP430.  This greatly simplifies the wiring however it pushes this complexity back into the code.  The wiring looks like this:


The display data interface is spread across Ports 1 and 2.  Not only that, the bits are in reverse order.  Reversing bits at run-time represents a performance hit so, a lookup table was generated and the writing of the data bytes goes from this (for the left hand version)

P2OUT = data;


P1OUT &=0xc1;
P2OUT &=0xf8;
if (b)
{ // only write out bits if b is non zero to save time
P1OUT |= reverse_bits[ (b >> 3) ] >> 2;
P2OUT |= reverse_bits[ (b & 0x7) ] >> 5;

The lookup table reverse_bits was produced using the following python script (only a 5 bit table was necessary)

# Output the specified range of numbers with their
# bits reversed as a lookup table suitable for C
print "const uint8_t reverse_bits[]={ \\"
for n in range(32):
print int('{:08b}'.format(n)[::-1], 2),",\\"
print "};"

Performance is not obviously affected by this wiring change and full code can be downloaded over here on github.

More information can also be found on roboslam.com

MCU Invaders Part 2


This post follows up on the previous one and includes a description of the software involved in MCU Invaders.  Initially this project started out as a C++ project however I found it difficult to get the initialization “glue” sorted out.  It seems that C++ initialization procedures have changes since GCC 4.7 and I didn’t want to get diverted from the main goal figuring this out.  It was easier instead to convert to a C project while retaining the object oriented nature in spirit.

The project is made up of the following layers:



The SPI Layer
Communication with the ILI9341 display is carried out over the SPI bus.  This consists of 4 signals:
MOSI (Master Out Slave In).  This carries data from the LPC1114 to the ILI9341
MISO (Master In Slave Out).  This carries data from the ILI9341 to the LPC1114
SCK (Serial ClocK).  This is driven by the master and sets the pace for SPI Communications.
CSn or SSEL.  This line is driven by the LPC1114 and can be used to wake up the ILI9341 by driving it low. The LPC1114 is capable of generating this signal automatically when transfers are taking place.  This proved to be a problem in this case.  The ILI9341 is slow to respond to changes to this signal and this limited data rates to less than 1 Mbit/s.  This was not sufficient for the game.  I noticed however that if the SSEL (CS) line is kept low all of the time the SPI bus could be run at about 24MHz.  This of course means that the SPI bus is dedicated to this display which is not a problem in this case.

The Pixel Layer
This layer “understands” how to control the ILI9341.  It is used to initialize the display and contains the following low level graphical functions:
It also contains the macro RGBToWord which converts RGB colour values (1 byte per colour) into a 16 bit number that can be used by the ILI9341.

The Sprite Layer

typedef struct {
// Location of top left corner. 
 uint16_t x;
 uint16_t y;
// Dimensions of sprite
 uint16_t width;
 uint16_t height;
// The pixels for the sprite are stored at this location
 const uint16_t *SpriteImage;
 uint8_t visible;
} Sprite;
// Construction based on 2 D pixel array 
void initSprite(Sprite * sp,const uint16_t * InitArray, uint8_t Width, uint8_t Height, uint16_t x, uint16_t y);
// Show/hide the sprite 
void showSprite(Sprite * sp); // Put a sprite on the display
void hideSprite(Sprite * sp); // hide the sprite
void drawSprite(Sprite * sp); // show the sprite
// Move to the specified position
void moveSprite(Sprite * sp,uint16_t x, uint16_t y); // move sprite
// Does the sprite contain the given point
uint8_t withinSprite(Sprite * sp,uint16_t x, uint16_t y);

This layer is all about Sprites : Movable pictures on the display.  A sprite is defined by a data structure that specifies location, dimensions and a pointer to an array of data that contains the actual image.  The remaining functions are used to show/hide and move the sprite.  An additional function ‘withinSprite’ is used to test whether a given point is within the sprite.  This is used to detect whether missiles or invaders have hit a target.

The game layer (main)

This layer contains all of the game logic.  It also defines the shape of the various sprites used.  This layer also makes calls out to  the serial Communications layer allowing the developer to debug game play.  Dynamic memory allocation (new/malloc etc) is not used in this project.  Fixed length arrays are used for the invaders and missiles and these are enabled/disabled as necessary.  One implication of this is that there can be up to 5 missiles in flight at any one time.  There is still sufficient RAM available to increase this number should a developer wish to.

The video below shows the game in operation.

Code is available here on Github


MCU Invaders Part 1

Back in the 1980’s computers were a good deal simpler than they are now. This of course limited their capabilities but it also allowed people to fully understand what exactly was going on inside. Today, this is less easy as computers are extremely complex from a software and a hardware perspective. One area that still retains some of the innocence of the early days is embedded systems. Today’s low-end microcontrollers (MCU’s) are similar in specification and complexity to the home computers of the 1980’s. This makes them very attractive for re-inventing some of the classic programs of that time.
In a previous blog post I discussed a simple RPG called “MicroRealms”.
Here you will find a “Simon” lookalike.
This series of posts will describe a game inspired by Space Invaders and implemented on the LPC1114FN28 microcontroller. I will start with a description of the hardware platform and then later delve into the software and any problems encountered.

MCU Invaders hardware


The hardware consists of an LPC1114 MCU, a 320×240 colour LCD display, some buttons, resistors and finally a USB to serial interface to allow the MCU to be programmed.

The display is driven over the SPI bus and runs at approx 25MHz (this is beyond the official specification but it seems to work fine).  The buttons allow you move a defender left and right at the bottom of the screen and a “fire” button allow you launch missiles at the invader.

The MCU is programmed using ISP or IAP – i.e. programs are downloaded via its UART after it is reset into “ISP mode” (hold down Reset and ISP buttons, release Reset and then release ISP).  The completed circuit is shown in the picture below.

I got the display from dx.com and I note that it is now out of stock.  The original supplier ElecFreaks still has plenty of them available.

The next post will describe the code in detail bit in case you can’t wait that long you can find it over on github.