|
|
|
|
|
|
|
|
PROGRAMMING POWER
Interrupt-driven serial communications
By Alan Jay Weiner
In my December 1998 column, I introduced you to the Palm device's serial port. That version of SerialEcho used polling -- it would check every now and then for received characters. As I said then, polling is inefficient; it wastes processor time (and therefore battery power) to check and find that nothing has been received. In some programs, the time wasted checking could be used for other processing.
There's a better way. When your phone rings, you answer it; interrupting what you're doing. After the call, you can return to what you were doing before. We can do the same in the Palm device by using some undocumented, but well established APIs (Applications Programming Interfaces).
The low-level serial drivers actually do use interrupts. When the hardware is able to transmit a character or has received a character, it pulls an interrupt, causing the processor to stop what it's doing and service that interrupt -- either receiving or sending a character.
Unfortunately, the application is forced to poll for received characters.
This month I'll show you how to set up a callback when characters are received on the serial port. This allows the program to sit idle or do other processing while nothing's waiting to be read in.
If you want to follow along with the actual code, open a new browser window and point your browser at http://www.component-net.com/pp-extras/serial2.html.
What's a callback?
When you go to a hotel and ask the desk for a morning wakeup call, that's a callback. Software callbacks are the same thing -- you tell the operating system the address of the callback routine, then later when the conditions are right the operating system calls that routine. In this case, the callback will be executed when characters have come in the serial port. We already use callbacks to set the form event handler. When our application calls FrmSetEventHandler (usually in ApplicationHandleEvent or some similarly named routine) it tells Palm OS the address of the particular form's event handler. Then when form events occur, and your event loop calls FrmDispatchEvent, guess where it goes? Yup: the form event handler. See? It's just a callback.
Use the Source, Luke!
Hidden in the SDK's header files are many gems of information. There are numerous definitions and API prototypes that don't appear in the documentation. Over time, some of these have become semi-documented by various people who asked questions and figured out how they worked.
|
|
|
|
|
|
|
|
|
|
|
