Issue 150 January 2003
GUI Interfacing
A Straightforward, Simple Solution

---

APPLICATION FLOW

Not many small microprocessors have multiple serial ports. In this case, two would work well. Bit banging a one-wire connection would be a cost-effective alternative to bit banging a second UART; however, I wanted to become familiar with the ’2480. So, I chose to create a software serial port for the iButton interface, leaving the hardware UART for the Amulet GUI connection (see Figure 3).

(Click here to enlarge)

Figure 3—This project’s schematic shows you how the microcontroller connects to the GUI interface through the hardware UART. A Dallas Semiconductor DS2480B interfaces a software serial port (port A) to the Blue Dot Receptor (iButton receptacle), eliminating the special timing requirements of the one-wire bus. In External mode, Timer 1 automatically accumulates pulses from the bill acceptor connected to T1CKI.

The primary communication channel to the GUI interface operates at 115 kbps. The secondary communication channel to the iButton runs at 9600 bps. The third piece of the puzzle—the credit pulses from the bill acceptor—is taken in via T1CKI, the external counter input for Timer 1. A rising edge on this input automatically increments the TMR1L and TMR1H registers, allowing for the counting of credits without any code execution. For security purposes, the counter is only enabled when bills are being inserted. 

Figure 4 shows the program flow that’s used in the microcontroller. Each dotted group of procedures and decisions represents the application code that will be executed for that specific HTML page.

(Click here to enlarge)

Figure 4—The microcontroller executes the procedures for each HTML page that’s displayed. The HTML pages use meta tags to request data from the microcontroller via the serial connection.

As the GUI displays most of the new pages, it will request a word variable from the microcontroller. The variable number that’s requested determines which procedure will be executed within the microcontroller’s application. If the microcontroller has not performed the requested procedure, it replies with an ACK. The GUI can make another request for the information or respond to user input (i.e., touching a function button on the LCD). The GUI interface is always in control, updating or displaying a new HTML page based on the response of either a word variable’s value (from the microcontroller) or a widget.

One of the requirements for GUI communications requests is a response of ACK or data within 200 ms. Some requests can take longer, so Timer 2 is used to indicate when it’s time to respond. Each procedure uses a flag to indicate that a response is ready. A Timer 2 match checks this flag. If it’s not ready, it automatically responds with an ACK. When a procedure is ready, it shuts off Timer 2 (to prevent an ACK) and responds with data.

At reset, the home page is displayed. You’re presented with two function buttons, Check Balance and Add Credit. When the Check Balance button is touched, the viewaccount page is displayed, which prompts you to touch the iButton tag to the receptacle or touch the Cancel button to return to the home page. 

When the iButton tag has been successfully read by the microcontroller, a value is sent to the GUI that directs it to display the balance page. The GUI asks for the balance, and the microcontroller responds with a word value. This value is formatted and displayed in a numeric field widget. The screen will continue to be displayed until you press the Done button, at which time the GUI will display the home page again.

When the Add Credit button is pressed, the addtowhichaccount page is displayed, which prompts you to touch the iButton tag to the receptacle or touch the Cancel button to return to the home page. When the iButton tag has been successfully read by the microcontroller, a value is sent to the GUI, which directs the GUI to display the addbills page. At this point, you can decide to touch the Cancel button or insert bills into the bill acceptor. 

The GUI interface asks the microcontroller to signal when the credit counter (from pulses received from an enabled bill acceptor on T1CKI) is no longer zero. After a bill is inserted and accepted by the bill acceptor, credit pulses are sent. Finding a nonzero count, the microcontroller responds. The GUI interface jumps to the addmorebills page where a display of accumulated credits is continuously updated until you touch the Finished button (see Photo 5).

(Click here to enlarge)

Photo 5—As bills are accepted, the AL4 outputs pulses, which are accumulated in the microcontroller. The number of pulses represents credits, and this value is sent to the GUI interface. You get credit feedback on the LCD for the paper money inserted into the bill acceptor.

At this point the GUI interface asks you to touch the iButton tag to the receptacle. The credits will be added only to the original iButton. If any are used except the original iButton, the credits aren’t added and a request to try again is issued. This assures you that the cash that’s inserted is added to the correct tag. A good tag match updates the tag and returns to the balance page to show you the new credit balance. In order for a tag to be recognized, it must have correct CRC values on each block of data, and the data must match a predetermined format. Bad tags are rejected.