Start • System Overview • LCD • Analog • Software • Implementation • Hand that Feeds • Where to Now? • Sources and PDF

SOFTWARE

The software for driving the display is fairly simple. This makes up for the delicate operation of soldering the display to a PCB. There are a lot of efficiencies that could be incorporated, but the overall idea is to stimulate the sensor, read the sensor, process the returned values, and display the result.

A timer routine is called every 7 ms. This stimulates the sensor and performs the A/D conversions sampling the SENSE pin on the sensor. Then an interrupt routine calls the update display every 80 ms, which updates the video RAM with the new information that needs to be displayed. The main() routine monitors the bubble’s coordinates and sets the sound and an LED to indicate direction accordingly.

The first part of the project involved converting a font table to a format the Epson could use (see Figure 4). Years ago, I used the original font for a Game Boy project, but the screen format for the Epson is different. I didn’t fancy redoing an entire font table, so I wrote a routine to manipulate the font and reconstruct the font to a new header file with the new format. The font for the Epson display requires data to be written 8 bits at a time, starting at the top left of the screen and going top to bottom for eight pixels. The original font for the Game Boy was written from the top left going left to right for eight pixels. The Epson display is organized as eight pages of 8 × 121 pixels.

(Click here to enlarge)

Figure 4—I had an 8 × 8 character font from an old project that wasn’t compatible with the Epson display. Here you see the differences between the two look-up values required to create a character. I wrote a program to take the original font in the form of a header file and convert it into a header file suitable for the Epson display.

The register set has one interesting register called Display Start Line Set. Although I haven’t used it, it will give the appearance of a scrolling screen. It allows you to change the displayed order of one of eight pages. It might be good for the Text mode. You’d be able to scroll through a number of entries without having to update the entire screen.

The other area of interest is displaying the text and graphics on the screen. If a bit is set or cleared purely as a graphical operation, then an 8 × 8 character is written over the top as a separate operation. The original graphical bit will be written over by the font, losing the original graphical image. I got around this by creating three 1,056-byte video RAM areas.

This size came about because, although the screen is 121 × 64 (968 bytes) pixels, the controller’s RAM is 132 × 64, which is 1,056 bytes. The first area is for the graphics that aren’t altered. This constitutes the outer bubble vial. This allows for economy of processing time in only calculating the outer vial circles once. One area is for the text. The final one is for any animation (the bubble itself in this case). The result of these three ORed together creates the final screen image (see Listing 1).

As opposed to simply writing directly to the screen, following this approach allows for a lot more versatility and expandability because images can be overlaid on top of one another. It needn’t be limited to the calculated graphics I’m using. A conversion routine could be written to allow standard black and white bitmaps of 112 × 64 to be displayed. There is software to do this exact thing with the added benefit of converting them to a standard header file. The resultant header would almost certainly need to be converted to the E2202CKR’s screen format.

The sound files were generated from the example in the Keil package. A couple of modifications to suit my needs were added. I wanted to be able to call a certain sound on demand, not just through a cyclic loop. When the unit cycles through the two axes, the software determines which side of center the bubble is on and calls out front, back, left, right, or center. The software waits until the current sound has completed before changing to the alternate axis.

The other software areas capture data from the sensor and organize the assorted functions into a coherent unit. When the building blocks of the assorted requirements are in place, all the dots can be joined together to form a higher level of functionality.

I will continue to play with the code for this project. I will post my updates at http://users.chariot.net.au/~stefanm/.