Software
The software needs to be able do three things:
- Read the touchscreen
- Output video
- Provide an user-interface
- Remember who drank what
Read the touchscreen
In its idle loop, the uC reads the touchscreen by making use of 2 A/D-channels
embedded in its core. If it measures a touch, the coordinates it's detected on should
be steady for a certain time before the routine accepts it. As soon as it's
accepted, the program converts it to the ID of the area touched and returns
it to the main program.
Output video
If not for this, the complete logic could have been implemented in a much less
powerful processor, e.g. an AVR. The microcontroller should output 640x480
pixels every 1/20 second to get a stable image, and even this 32-bit
uC running at 60MHz needs to have a hand-optimized video-output-routine
to be able to keep up. The video-routine is implemented as a timer-interrupt,
so the main program gets interrupted every so many cycles to output a line
of video. The video-routine itself implements a sort of MDA-card in software:
an ASCII-code is read from the video-RAM, the corresponding picture is looked
up in a character table in ROM and the resulting image is output to the screen.
That way, a program can just write characters to the video RAM and the rest
will be handled automagically by the video routines.
Provide an UI
The most important part, this makes sure the device 'just works'. Basically,
as an user, you walk up to the device and touch your name, or 'prev' or 'next'
if you're not on the screen. After that, you choose your beverage of choice and
the amount you'd like to take, all in a nice semi-graphic environment.
The UI
Remember who drank what
This is kept inside the 128-byte EEPROM on the prototyping board. I didn't
implemented network communications or wireless or whatever, cause this has
the least chance of failing. If I decide to calculate what everyone has to
pay, I just take the device to my computer, connect it to a serial port
and read out the values.