Program Design
The program begins by using initialization code to set up state variables. Following that, Timer0 interrupts are utilized at 1 millisecond accuracy. The outputted clock is updated each second. Alarm and trouble pins are polled every quarter second that the clock is not updated. Additionally, input via the user terminal is updated once almost every 50 milliseconds. A glitch in the code allowed for extremely slow input to the system. It was found that the text was being polled every second, 50 milliseconds after the time was updated. This glitch was corrected and the code now runs smoothly.


Finite state machine diagram for user interface

EEPROM was utilized for the nonvolatile system settings (names, enable/disable states and the password). The very first time after MCU programming, initialization code is executed to initialize these EEPROM variables. It was found that standard C functions, such as printf could not utilize EEPROM strings and variables directly. This seemed to be the result of address space problems. Instead, an indirect method was created where strings were first copied into SRAM and then the SRAM variables were outputted to the interface. This indirect method was both more memory intensive and required additional programming, however it seemed to be the easiest and more reliable solution.

The VT100 standard was used to display the user interface. The standard allows for a variety of display commands and includes the ability to place text at different places on the screen, clear areas of the screen and change the way text is displayed (flashing text for example). This helped allowed us to have a clean, easy to read interface. Originally, Java had been considered for the user interface. This idea was abandoned due to software problems with the lab computers.

In order to produce clean, nearly artifact-free text display, the code had to be designed carefully and efficiently. The screen is only updated when required. Originally, this had not been the case and the cursor very visibly moved around the screen. This was solved by having flag variables and the like keep track of what needed to be updated on the screen, so that only those things would be updated; no unnecessary updates are made to the screen. This proved tricky at times and required careful coding. Displaying text to the interface was one of the most time consuming parts of this project.

A complier bug prevented the code from being properly linked and programmed to the chip. Unfortunately, when the compiler programs the chips for optimized speed, it can sometimes require a relative jump which is beyond the allowed PC. This happens when there are complex switch and if statements. This problem was corrected by recompiling the code with size, not speed optimized.