CU Organizer

CU Organizer

 

Introduction:

One of the newest and fastest growing additions to the digital age in the 1990s has been the handheld personal computer. Given a little flash memory and a good LCD, anything is possible and commercial products like the 3Com PalmPilot� and IBM Workpad� are flourishing. But as these products expand their functionality so does their price. Last year, a more downscaled device Frankin Rex� card sold very well because it offered a small portable data unit at a minimal cost.
In fact, it only served as a data display device for the data that was transferred from the PC, and it functions using just a few buttons rather than using a more expensive LCD that can accept input using a pen-like device which is detected when pushed on the screen. This year they have improved the card in the Rex Pro� version to take input using additional buttons to scroll through alphanumeric characters. In this project we attempted to produce a similarly functioning device using an Atmel AT90S8535 microcontroller, its Atmel evaluation board, and an Optrex 4x20 LCD. In addition, we also attempted to include an infrared communication interface on the prototypes which is used for downloading/uploading data to the PC, as well as for messaging between two devices, which is only a recent addition to the high-end handhelds like the 3Com Palm III�. This IR message transfer ability has been especially appreciated by users who enjoy not having to physically connect the devices to their PC hardware (in a PCMCIA slot for example), and corporate users have found it useful as a way to silently communicate across a room or even just across the table at a boring meeting.
Given this hardware, we had to decide how to create a useful interface for the user on both the PC and handheld ends. For the PC, we created a Java interface that can browse and edit the data, which is stored logically in a contacts database and a memo database and physically in a file which can be loaded using the standard Windows file selection interface. The interface provides for browsing both databases one entry at a time, saving the data to the file, and sending or receiving to synchronize data with a handheld device. Each contact entry provides space for a first name, last name, address, and phone number, while memo entries allow space for a date to accompany each memo. The handheld interface relies on the buttons provided on the evaluation board to browse through the menu options to view/edit the data, synchronize data with the PC, and send messages to another device. Data or message entry and editing is performed by using the buttons to scroll through the characters and moving to the next character space using left/right buttons.

High Level Design:
The most significant portion of the project design was in the development of the user interface in Java for the PC and in assembly code for the handheld prototype. The challenge was to create a useful interface while maintaining a relatively easy data-handling scheme that could easily be ported between the two. The reasoning behind the use of a Java application on the PC as a way to perform data entry was twofold. First, it offers the user the standard Windows PC data entry interface that they are accustomed to using, which is much quicker and easier to use since it has a full keyboard for input. Secondly, it provides a large data storage capability for data entry that is not always necessary for downloading to the handheld which is a more permanent storage space for the data to be backlogged on if required. The handheld on the other hand, is designed largely just for viewing the data. The data entry done by scrolling through the different available characters is more time-consuming than when done on a full keyboard, which is obviously an impractical addition to the pocket-sized device. Even adding a small keypad would not help to the degree necessary to justify its inclusion. A 16-key input would only about double the amount of available key inputs and even these are nothing comparable to a keyboard that users are often either formally or through time and experience trained to use rapidly.

When synchronizing the data between devices, it needed to be organized in a fashion that would allow for finite storage in SRAM on the handheld's mcu and provide terminating characters on the handheld for ease of handling when displaying them on the LCD.
On the PC side, this led to the Java interface allowing a finite number of characters in each database entry field, which then allows the mcu to be able to count on only having to store characters counts corresponding to the field in the entry. These limits were as follows:

• Contacts Database Character Counts

1. first name of 10
2. last name of 10
3. address lines (1 & 2) of 20 each
4. phone number of 10 (12 including dashes but they are parsed out when sent to the handheld)

• Memos Database Character Counts

1. date of 8 (10 including slashes but they are also parsed out)
2. memo line (3) of 20 each

Therefore when the handheld is receiving data from the PC, it can trust it to send only as much data as it is able to store per contact. The PC is allowed to send more data than the handheld has SRAM storage available to hold, but this case is handled by limiting the number of each databases' entries that are accepted by the handheld during a receive operation. All extra entries are just disregarded by the handheld. This was very necessary with our device prototype because the 8535 mcu limited the storage in SRAM to 512B. Another portion of the data communication protocol design between PC and handheld is that when one is that the receiver dumps its past data and only stores the new data from the sender. This requirement simplified the data exchange because doing it otherwise would have necessitated a data comparison with something along the lines of numeric contact and memo id specifiers. This also allows the user to accumulate data on the PC end in its plentiful storage while only storing the necessary information in the handheld's limited storage.
The last portion of the interface design was in the message exchange between handheld devices. The devices were designed to simply take the message entered and send it to the receiving device. The receiver meanwhile is set to wait for all of the data to be received then displays the message in its entirety. The messages are not stored, however because we consider them to be temporary entries which are not worth storing in SRAM because of the space that would be taken away from the main data in the contacts and memos databases. Also worth noting here is that the message send and receive is driven by the user, as is the synchronization. The handheld and Java operating programs are designed not to accept or send data transmissions unless it they instructed by the user to do so. This means that in order to synchronize data with the PC, the user must set one to receive then direct the other send the data. To send messages, the other handheld must be instructed by the other user to receive an incoming message.

Program/Hardware Design:
The handheld program is centered around its menu driven interface. The options available on the handheld were too numerous to all be available immediately on start-up so they are accessed through successive drill-down selections. Therefore the current menu state determines the functionality of the buttons and the device. On reset, the program naturally begins at the main menu where the user can select the contacts and memos databases' menu, the message center for handheld-to-handheld communication, or the synchronization mode for PC-to-handheld communication. Every menu is headed on line one with its respective title and the remaining three lines are used for the three options. Each of these subsequent menus then provides two options with the third being a return to the main menu. All of the menu titles and options are stored in and displayed from the 8535 mcu's flash memory as shown below:

The initial menu/main menu allows selection between contacts and memos database browsing/editing, entering message center menu, or entering the synchronization menu. From the contacts and memos menu, you can select to load up and browse either the contacts database or the memos database. Once within the contacts database browse mode, you have these options:

• Pin0: Return to Contacts and Memos menu
• Pin1: Add Contact
• Pin2: Delete Contact
• Pin3: Edit Contact
• Pin4: Move Up (by one display row)
• Pin5: Move Down (by one display row)
• Pin6: Browse Left one Contact Entry
• Pin7: Browse Right one Contact Entry

Note that the exact same button functionality exists in the Memos database browse mode. The Add and Delete functions complement each other in that they only allow the number of contacts to stay at or below the initial programmed value according to the device's SRAM constraints (in this case it was 2 contacts and 3 memos). The Delete function will allow all entries to be deleted and once that happens, the user is returned to the Contacts and Memos menu. The Add function detects an attempt to add an entry when the database is full and simply ignores the request. When there are initially no entries in the database, then selecting either contacts or memos browsing creates one new blank entry that is displayed for the user.
A secondary mode to browsing is editing which is accessed by button 3, and it switches the button functionality as follows:

• Pin0: Exit back to browse mode
• Pin1,2,3: (none)
• Pin4: Character select up
• Pin5: Character select down
• Pin6: Move Left one character slot
• Pin7: Move Right one character slot

Here the character selection proceeds as follows: a-z, A-Z, 0-9, _(space), punctuation, and then parentheses/brackets. There is a line character count which limits the space available per line depending on the data input for the line (i.e. 8 characters for the date, 10 for the phone number, etc.).
The second option from the Main Menu is the Message Center, which allows messages to be sent and received from another handheld device. The first option is to place the device in Receive Mode where it waits for another device to send it a message while displaying a waiting message "Receive Ready" and then it displays the incoming message once the receive is complete. Pin0 allows you to exit the mode after reading the message. The second option is to send a message. In this case the display is blank and you edit the message before hitting Pin1 to send it with Pin0 exiting. The editing is done through the same Pin configuration as in contacts and memos editing functionality.
The third option from the Main Menu is the Synchronization Mode, which allows the contacts and memos databases to be loaded from the PC or uploaded to the PC. Option 1 is to receive the data. The device program waits for the PC to send the data headed by 0x01 then 0x04 then 0x05 followed by all of the data for both the contacts and memos with each terminated by a 0x01. Once the receive is finished, "Receive Done" is displayed for a few seconds then the Sync Menu reappears. The second option of Send Info, sends the data out to the PC with the same data header and terminators as it is received from the PC, which is done in both cases to achieve a much greater probability of accurate data being received.
The hardware used for the sending and receiving was the RS232 interface on the Atmel evaluation board and the COM2 serial port on the PC. The interface was intended to be done through the infrared transmitter and receiver pairs that we attempted to use, but the transmission media ended up having to be the serial cable between the handheld and PC and a null modem cable between devices (for connecting female to female adapters). We were also attempting to use the AT90S4414 mcu initially, but we ran out of flash memory to program with because it only provides 4K of flash. The AT90S8535 also provides twice as much SRAM at 512B than the 4414, which became very useful once we determined that we needed at least 2 contacts and 2 memos to demonstrate the full functionality of the handheld device. Once switching to the 8535, we encountered a switch connection problem where a button push was not able to be detected on PortB so we switched the connections to PortA, which left the LCD power (PortB0) and ground being taken from PortB. Note that rather than change all of our code to reflect this, we switched the declarations of the two ports as shown in our 8535def.inc file (listed with all files at the end of this document). The connections not listed on the schematic below are as follows (also note that PortD0 and PortD1 are taken as RS232 data pins):

• Pin 0 >> Gnd (C8)
• Pin 1 >> Vdd (C9)
• Pin 2 >> Trimpot single-side output w/ double side inputs to Vdd and Gnd
• Pin 3 >> C6
• Pin 4 >> C5
• Pin 5 >> C4
• Pin 10 >> C0
• Pin 11 >> C1
• Pin 12 >> C2
• Pin 13 >> C3

The JAVA program provides a user-friendly interface where data can be entered and manipulated in a plethora of ways. Some of the functions of the GUI interface are:

• add contact
• delete contact
• add memo
• delete memo
• scroll left and right through the contacts and memos
• save the current information in the program
• load information from a file into the program

The following is a screen shot of the program after loading a file:

The JAVA program provides a user-friendly interface where data can be entered and manipulated in a plethora of ways. Some of the functions of the GUI interface are:

• add contact
• delete contact
• add memo
• delete memo
• scroll left and right through the contacts and memos
• save the current information in the program
• load information from a file into the program

The following is a screen shot of the program after loading a file:
Appendix A:

• Frametest.java (GUI interface with data transmission)
• Reader409.java (file input---borrowed from Prof. Paul Chew from CS409 Spring 1999)
• Info.dat (sample input file)
• Hheld485.asm (main file with memory declarations, reset code, all menuing, messaging, send/receive)
• Hheldin1.asm (Editchar procedure for line editing)
• Hheldin2.asm (all ISRs and subroutines necessary for UART data transfer and button deboucing)
• Contacts.asm (all contacts browsing, editing, adding, and deleting)
• Memos.asm (all memos browsing, editing, adding, and deleting)
• 8535def.inc (modified to switch PortA and PortB declarations)

Appendix B:
See the schematic with listed connections in Program/Hardware Design section.