The software needs to be able do three things:

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.

« Prev 4 Next »

© 2006-2016 Sprite_tm - Contact