Program/Hardware Design

Software Design
The bulk of our design was to get several different components to work together to form one coherent system. Each component was designed, coded and tested individually before being integrated. Furthermore, since there are two distinct tasks Server or client, 2 different codebases are needed.


The server uses the Verify, Commit and Crashrecovery functions to maintain correct state on the machine. He server is continously running listening on its TWI bus. Once the server has been addressed, it stores the data in a temporary buffer, once the entire message has been recieved it uses verify to determine that the ID number has not been used allready, and sets a flag. The server only uses commit to store this data once the, the protocal has sent a response back to client and has confirmed with and acknowledgement on the TWI bus.


This code segment is for our commit function, and works hand in hand with crash recovery. All the backup datatypes are stored in EEPROM memory, this memory will survive a crash. The ID are stored as long variable and take up 4 bytes this means that an access to them could be interrupted and the ID not written correctly. The multiple Backup varialbes are used to determine when a crash occured. Since each of these varaibles are char, I am guaranted that they either either correct or incorrect. If A, B and C are equal that means the system is in a coherent state. By using the relations between these 3 varaibles we can determine where the error occured and correct the voting list. However without error correcting codes there is no way to recover the actual voter data or votes register. That is why each machine has a paper trail.

The TWI interface has a build in state machine. Each interrupt from the TWI inteface provides a status flag, this status flag represent the sate of the TWI bus and the current machine. The application only has to create responses to these states. The only state that is needed are flag to notify when buffers are empty to stop transmission of data.


The client machines output to the TV. The TV code has been reworked from having a raster based display to that of ascii decoder. The old raster display would output one char, one bit at a time in 5 cycles. Since the code was not fast enough all the bytes had to be preloaded and then sent out. The base simplification to save time was that the entire port was dedicated for video display. This means that no other pins on the port can be used for output. This reduced the number of operations to ouput from 5 to 2. These 3 additional cycles where used to load and process the next output. The output is limited to 5x7 chacters with a blank line between characters(vertically), thus the display is 5x8 characters. The characters are stored as regular ASCII text. Flash memory contains the bitmaps for charcters 0-127, with character 10 (newline) being special. While outputting one character, the code loads in the next chacter by looking up that character in flash. Another feture is that the code automatically checks for a newline and proceds to the next line. Previously a screen occupied 1600 bytes in memory, the same output of pure text only costs 200~300 bytes. This was necesarry since the large amount of text display. The only thing the code needs is a char pointer. By setting Page Start to any character array. This also mean that redrawing the screen is very fast.


Our design is comprised of 6 main parts: identification, input, output, verification, storage and communication. Each of these parts were designed and tested independently before being combined into the final system.


For identification, magnetic card readers were used. Magnetic stripe cards are commonly available and are in widespread use. Most states provide identification cards that contain some information on a magnetic strip. At Cornell, every student is issued a Cornell ID which has a stripe. The card communicates raw bit data serially to the microcontroller for processing. The microcontroller then decides if the card is a valid Cornell ID. The Card readers used were TTL chips, that provided a clock, data, and card present. These where used in conjuction with the Serial Peripheral Interface ehich matches up nicely. The SPI has serial clcok, serial data and slave select. Reciving the bitstream from the card was not difficult except for buffer overrun errors and variable speed clock (dependent on the swipe speed).


Input to the voting machine is very simple. The user chooses from a list of options from a menu, and moves between different ballot questions via four pushbuttons. The buttons represent “Go Back a Page”, “Select Up”, “Select Down” and “OK”.


The user interface is displayed via a television monitor. Since TV screens are widely available, they can easily be replaced. The output of the microcontroller is in NTSC format black and white. The TV output is actually a matrix of 14 by 25 ASCII characters (instead of a full raster). This implementation is extremely memory efficient, since each character requires one byte to store. For example, a blank screen requires only 14 bytes to store, since each line only contains a new-line character.


The votes are stored in multiple places. All the selections made on the ballet are initially stored in volatile SRAM memory until the vote is committed. Once the vote is committed to the server, the votes are moved from SRAM to the longer lasting EEPROM and are also printed out to provide a hard copy. Additionally, the server keeps a running tally after the verification step.


The communication between the server and clients are using and addressable serial interface called TWI. This interface allows for each component to have a specific address when in the network. Each voting machine knowns the address of the Server machine and sends a request to that address and waits for a response. This interface requires an external pull up resister network and that all chips connect to. If any of the devices are not on, the serial communication will not function, even if its not the intented reciever.
The Server also uses the USART interface to connect to a computer and provide terminal commands.