Palm for embedded products? Admittedly, it is a niche solution, but there are special situations where it is very useful. Any application that acquires quantities of data at one or a few locations for processing at a different location and where a person will always be nearby is a candidate. It can also be a solution for control applications where the control features are hardly ever changed, and the operator interface is a disproportionate share of the hardware cost. An example of this is a sprinkler controller, which might go for months with no changes to the program. Palm for embedded applications generally rely on a Bluetooth radio link.

Palm handhelds advantages are low cost especially for small production volume or intermittent uses, a simple user interface intended specifically for non-technical users and comparatively rapid program development and debug. Palm handhelds have several major advantages over Pocket PCs. One is the much longer battery life. Another is that the Palm OS supports previous generation features so that programs don’t become obsolete every time a new generation of products is released. Also, since Palm has the majority market share for handhelds, the potential user is more likely to already have the required handheld.

The chief disadvantage to Palm handhelds is that the small screen size makes displaying large quantities of data impractical. Another is that the lack of a built-in keyboard makes local manual data entry tedious at best. Add-on keyboards do exist, but the average user doesn’t have one.

A perceived disadvantage is that the processor speed is slower than Pocket PCs and laptops. In the first place, this is changing because Palm is developing faster processors. Some of the latest Palm handhelds run at over 400 MHz. In the second place, neither a Palm handheld nor a Pocket PC is a satisfactory platform for data processing because neither has an adequate display. If the data is going to be moved to another platform for processing anyway, then the local processing speed is not as important.

Palm OS handhelds don’t have enough built-in hardware I/O to make embedded control practical. Applications must rely on external hardware to acquire and temporarily store the data, and send it to the Palm handheld through a serial interface of some sort. There are several ways to communicate with the Palm handheld. These are the cradle, which has USB or RS232 interfaces, the built-in infrared port, or a radio link such as Bluetooth or Wi-Fi.

Every Palm handheld comes with a cradle that connects the Palm with power and a desktop computer. This cradle presently comes with a USB link standard, although a cradle with RS232 is available, and was standard on older Palms. Palms use a process called HotSync to transfer data between the handheld and a PC. Every Palm application that needs to transfer data requires a custom PC application called a conduit.

Every Palm handheld has an IrDA port on it. IrDA is common on high-end laptop computers from Dell, HP, and Apple, but doesn’t seem to be found on desktops from anybody. On Palm OS, the IrDA port can support up to 4 Mbps. It supports the base level services of the two hardware layers, plus IrLAP (IR Link Access Protocol), IrLMP (IR Link Management Protocol), and TinyTP (a lightweight transfer protocol).

The most flexible way to interface a Palm to the data acquisition or control application is via a Bluetooth link. The link can theoretically be made at up to 700 feet at very low speeds, but the minimum speed for the Palm-based Bluetooth link limit the range to about 30 feet. Stucco walls and metal objects such as vehicles don’t noticeably shorten the range, but concrete block walls effectively block the signal even at very short ranges.

Bluetooth can operate in several modes, called profiles. Although there are literally dozens of profiles, two are useful for embedded applications. One of these is the Serial Port Profile (SPP), and the other is the LAN Access Profile (LAP).

The SPP is designed for serial cable replacement. SPP mode is described as a drop in replacement for legacy RS232 applications. That is not always true. One thing that must be borne in mind is that any radio link, including Bluetooth, is not as reliable as a wire line, and has unpredictable delays due to message dropouts and the resulting need to resend blocks of data. In addition, Bluetooth has several layers of management software over and above the RS232 conversion and radio handlers. All of these layers add overhead, and slow the message transit time measurably. For one particular application, a message exchange that requires 60 ms on a wire line version takes 120 to 200 ms on a Bluetooth link even at close range. Messages can take seconds to get through at the extreme end of the range. Although the maximum bit rate for Bluetooth is advertised at 1 Mbps, the Palm rate is limited by Palm OS overhead and other factors to about 100K bps. Also, flow control can be very different on Bluetooth systems. Defined status bits emulate hardware handshaking.

The LAN Access Profile (LAP) can handle up to eight devices in a grouping known as a piconet. Of these, one device is always the master, and all of the others are always slaves. All communication must occur between the master and one slave. Slaves never communicate with each other. A device can be part of more than one piconet at one time, and can be a master in one piconet and a slave in another.

Bluetooth hardware is very inexpensive, but the design must be certified by a recognized Bluetooth test facility. This process is so expensive that there are only a couple of off the shelf solutions suitable for the embedded market. All of the products that exist as of this writing (January, 2005) are for SPP cable replacement mode. There are no commercial devices for LAP mode. The good news here is that the SPP market is ideally suited for dirt-cheap solutions from Asia. They aren’t here yet, however.

(This part is under construction)

Palm OS supports the Bluetooth LAN Access Profile, the Dial-up Networking Profile, the Generic Object Exchange Profile, and the Object Push Profile.

TREO is a Palm OS handheld with a built-in cell phone.

(This part is under construction)

Palm handhelds presently come with 32 MB to 256 MB of static memory, which can be expanded with storage cards. This memory is divided between programs and data storage. The amount of memory available for data storage depends on how many other applications are loaded, and how much data they are storing. Typical values range from 25 MB to over 250MB of available memory depending on the model.

Palm screens are usually 320X320 pixels, although some are 320X480. In either case, it is too small for serious data display. Also, the current generation of Palm OS handhelds don’t really support color or at least not for graphing. The operator can change the color of the display, but the entire display is one color. This and the lack of a keyboard are the main reasons for offloading data processing to a desktop computer.

All code on a Palm is executed in response to an event. There are literally hundreds of events, but fortunately, the OS takes care of most of them, and many of the remaining events are translated for easy use. For example, the user can enter a character in three different ways (hand drawn, built-in screen keyboard, or external keyboard) but they all arrive at the user program as a key down event. Even this can be ignored if the program is only interested in the final result. The system will take care of the cursor, backspaces, erasures, insertions, etc. with no code from the application.

All interaction with Palm handheld hardware is done with OS calls. The hardware includes not only the usual suspects such as the serial ports, but also such things as the memory used for databases. These commands are not specifically designed for data acquisition, so finding the right combination of commands to accomplish a particular task can be challenging at first, but the OS calls are extremely well documented, and the documentation is well organized, so it will come together.

As with all systems that rely on event processing and OS calls, the Palm OS is not good at hard real time deadlines, but it is fast for functions that don’t need floating point or continuous screen updates. The basic system tick is 10 ms.

Manual entry of commands and data on a Palm handheld is very limited. Palm suggests that programs assume that the user will not have a full keyboard and discourages programmers from making users enter a lot of data. An easy to learn interface is paramount. Ideally, basic operations should be learned in five minutes with no instructions. This means that new Palm programs should behave as nearly the same as existing programs as possible.

Data display is very limited: 320x320 is currently the standard although some new products use 320X480.

Data is transferred to a desktop computer during the HotSync procedure. HotSyncs are completely automatic but require a dedicated PC program called a conduit to transfer data in either direction between the handheld and the desktop.

Palm handheld products have short production lives, and rapid turnover. But Palm emphasizes compatibility from one generation to the next. Every program written for the original Palm Pilot can run on the latest Tungsten T5, assuming that the programmer lived by the Palm programming recommendations. This is the chief advantage of Palm OS handhelds over Pocket PCs.