Many of us have watched an employee from the power company come to read our power meter. He is collecting information in the field and storing it in a portable device. The trend is similar in the consumer market where people demand information anytime and anywhere. The pervasiveness of portable digital assistants (PDAs) combined with their wireless abilities can open new possibilities for microcontroller applications.

An interface all but few PDAs have in common is an infrared port. This enables wireless, two-way communication with any other device using the Infrared Data Association (IrDA) standard. Combining a microcontroller using the IrDA interface and almost any PDA—which already has the interface built-in—can speed the process of data acquisition and even simplify it.

This paper will discuss and examine possible hardware and software issues specific to such a microcontroller/PDA (mC/PDA) interface. The most notable challenge said interface will create is cross-platform compatibility. Microcontrollers (mCs) use assembly language specific to their manufacturer and the family of mC. Further, there is no standard PDA operating system (OS), which could create additional compatibility issues. By establishing hardware and software objectives, a strong focus on this new arena of mC/PDA applications can succeed.

RESEARCH OBJECTIVES

The serial computer interface (SCI) is a logical place to start examining the mC/PDA hardware interface. Starting here will establish a bit pattern for data transfer on, for example, the Motorola MC68HC11. For an external interface, the 68HC11 can support the RS-232 standard. Combined with a MAXIM MAX232, the voltage levels of the SCI signals can be augmented to the corresponding RS-232 signals.

The second logical step in hardware design is interfacing the microcontroller’s RS-232 port with an IrDA device. There are two options for accomplishing this level of integration and design resolution.

The retail version of an RS-232 to IrDA converter is available from Actisys, Inc. The Actisys IR2000L retails for approximately $175 USD. It has eight pins (IRTX, ITRX1, GND, Vcc, IRRX2, SEL1/ID1, SEL2/ID2, and ID3). This is a costly solution, but not prohibitive for smaller scale projects. The IR2000L accepts the standard serial port connectors and easily converts to and from the wireless IrDA standard.

The second option would be to create an IrDA device from the component level. The receiving components available for this are the IS1U60L or GP1U52X. Both of these are IR receivers but the transmission would require another chipset. To achieve a standard method of IrDA Tx/Rx necessitates further electrical design factors. This option has the advantage of cost. These are relatively inexpensive chips compared to the Actisys solution—a very important factor for large-scale production of an mC/PDA interface.

The hardware issues on the PDA side are moot. The IrDA Tx/Rx circuitry is already integrated into the PDA. Thus, half of the hardware design for this interface is complete. The greater issue at hand is the “code,” or communication standard these two devices should use to communicate bi-directionally. The 68HC11 is used as an example in this paper, but the ultimate goal is to create a standard state and/or process most microcontrollers could achieve to communicate with a PDA.

ANALYSIS

For an mC to perform operations (measurements, sensing, etc.) it must be autonomous until an IrDA signal is detected. This requires intuitive use of an interrupt. The PDA sends a “wake-up” signal to the mC, requesting communications. The 68HC11 has such a feature in the SCI receiver.

The wake-up feature would be one of several interrupts in a common code spoken by the PDA and mC. The other interrupts would be related to the TASK (see Figure 1) the mC is being used to execute. If the mC requires multiple interrupts (including the PDA), only one external interrupt is inadequate. In the 68HC11, the IRQ pin is available for an external interrupt. For any practical application, more than one interrupt would be useful. To remedy this, Abel Raymus, has recently published one possible solution in EDN magazine. He offers an inexpensive alternative to buying an mC that supports multiple external interrupts. The states of some interrupts are shown in Figure 1.

The state diagram is similar to that used by Mukaro and Carelse. For their Data Acquisition System the state is dictated by two major events: the RS-232 PC interface is connected and a data sensor is sending data to the microcontroller.

The mC/PDA design has a similar state, but the focus is on Tx/Rx between the microcontroller and PDA. This design assumes data will be sent from the mC to the PDA and instructions/data sent from the PDA to the mC. If instructions—in addition to data—can be sent to the mC, then TASK processes can have a much greater range of utility.

SIMULATION / PROGRAMMING

The standard used to ensure correct data transmission between the PDA and mC should be the same as Huang has outlined:

1. Data must be transferred character by character.
2. A character must consist of one start bit, seven or eight data bits, an optional parity bit, and one or two stop bits.
3. The start bit must be low.
4. The least significant bit must be transferred first, and the most significant bit must be transferred last.
5. The stop bit must be high.
6. A clock with frequency equal to sixteen times the data bit rate must be used to detect the arrival of the start bit and determine the value of each data bit.

These guidelines are intended to eliminate any ambiguity a programmer might encounter when deciding on a standard the PDA should use when transferring a bit stream. This also allows a receiver to synchronize a local clock to each new character.

A bit rate of 9600 baud should allow for ample bandwidth considering the limited storage space addressable by most mCs. For example, the 68HC11 is only expandable to 64 Kbytes. A complete transfer of memory would take very little time at 9600 baud. Even at a slower speed (by IrDA standards), an error correction scheme should be established—correcting for framing, receiver overrun, and parity errors.

Another example of serial-infrared conversion is provided by Wettroth. He notes that the 8051 microcontroller uses a UART that is not compatible with IrDA. Using a high quality IrDA module such as the HP- 1000 combined with the MAX3100 chip, driver code can be written to convert from RS-232 to IrDA and vice versa.

Indeed, if the mC/PDA design calls for instructions to be sent to the mC, then there must be some way of storing them. The EEPROM supports about 100,000 write-erase cycles for doing this. Assuming a program is uploaded to the EEPROM, the RxD and TxD pins must be tied together after reset—making the program run automatically.

The alternative to storing instructions is placing them into RAM. This is a volatile means of storing a program, and should only be done if a reliable, dependable power supply is available to the mC. After reset (in bootstrap mode only) the mC waits for data from the IrDA port. When the program is stored into RAM, the program begins execution. The instruction space is very limited by available RAM. The 68HC11 has 512 bytes of RAM. Other mCs will vary in storage space and the programmer should take this into consideration when coding assembly for the mC.

EXPECTED RESULTS

The final component of mC/PDA communication would be placed on the PDA itself. Once the protocol logistics have been establish, implementing them on the PDA would be the next logical step. There are several factors to consider when coding for a PDA.

The most distinctive feature separating various brands of PDA is the OS. The PDA OS should be selected based on the application best suited for it—not the opposite. The two most prominent OSes available today are Palm OS, by Palm Computing and Pocket PC, by Microsoft. The majority of PDA users have chosen the Palm OS based on simplicity. It is also fast and efficient. Pocket PC devices have a greater range of features and memory but this might be overkill for simple data collection or mC programming in the field. Most PDAs support IrDA speeds up to 115 kbaud, and have FLASH memory expandable to 128MB. This is ample transfer speed and storage space for an mC that can transfer at 9600 baud and store up to 64KB, as in the 68HC11.

FUTURE RESEARCH / APPLICATIONS

Additional research can be done to investigate the specifics of coding for each PDA OS. The viability of such an mC/PDA interface could be evaluated for a series of microcontrollers across manufacturers or isolating a specific family of microcontrollers within one manufacturer.

An mC/PDA interface doesn’t have to be restricted to corporate or private use. According to Walley and Amin, the future of automation in customer environments can offer an array of new applications for improved service. A customer could simply request information pertaining to a certain product or service and have that information downloaded to the PDA. The newest trend is in mobile commerce (m-commerce). Its objective is a wireless method for checkout and/or purchasing in retail stores. Rightly equipped, this is a very practical solution for automation and customer service.

CONCLUSION

The mC/PDA interface is a viable solution that can be applied to many applications. Considering the hardware and software available today, both platforms—Pocket PC and Palm OS—provide software development kits to program either OS. Off-the-shelf products such as the Actisys IR2000L can provide an immediate solution if hardware production time is the greatest factor to consider (and price is a lesser issue). On a larger scale of development, the individual IR components should be realized into a functioning circuit. Regardless of the IrDA implementation, the use of multiple interrupts is strongly recommended.