Transcript
DESIGN ALTERNATIVES FOR THE BASIC USER INPUT DEVICE INTERFACE IN PORTABLE SYSTEMS John Milios, USAR Systems Bruce DeVisser, Fujitsu
Abstract Embedded User Input Devices (UIDs) in portable systems come in different forms and form factors as they are tailored to fit the specific functions of a system. When it comes to interfacing the input device sensors to the host system, the designer is faced with different continuously evolving alternatives defined by the capabilities of the host system chip set. Selection of the right interface is a function of cost, power consumption and suitability to the application. This paper will investigate the different approaches in the design of the User Input Device Interface, taking into account the unique requirement of UIDs in portable systems, and will point out the advantages and disadvantages of each approach. Special requirements of portable systems User Input Devices in portable systems possess characteristics discrete from those of the external desktop input devices. To begin with, they are not stand-alone devices; they are embedded in the system unit box. Although this characteristic seems to allow the designer greater flexibility in selecting the interface to the system, the devices still have to perform as primary boot devices. In the case of proprietary
architectures this imposes little or no limitations since the OS is adapted from scratch to the specific implementation. However, in standard - principally PC architecture systems, diversions from the dominant PS/2 interface necessitates the addition of extra BIOS support to maintain compatibility with the legacy software and hardware. In addition, most portable systems need to maintain expandability with external UIDs. Unlike embedded User Input Devices, external peripherals must be standard, in order to provide the end-user with the greatest flexibility in selecting off-theshelf products. If an external UID is connected to a portable system, data streams from external keyboards and mice have to be converted and merged with the embedded device data and then relayed to the system through the common interface. Another unique feature of portable UIDs originates from the role they often play in the overall power management of the system. User Input Devices provide the main link between the user and the system. The user will invoke action, and subsequently changes in the power state of the system, through the input devices. For this reason input devices have to be functional at all times when the system is fully on or in the suspended mode. The interface protocol selected should thus provide for minimum power
consumption during the system idle state. Size is another limiting factor in portable systems. Each specific implementation imposes different requirements on the PCB area as to the space necessary to accommodate the electronics for the input device sensor interface. Size is primarily determined by package technology and the number of pins necessary to implement the interface. Finally, special human factors have a direct impact on the operational characteristics and the way the input device subsystem integrates with the rest of the hardware and the OS in portable systems. Such factors affect, among other things, the scanning rate for portable keyboards, multi-layered keyboard implementations, single hand operation support and support of hot plug-ins of external devices. PS/2 Implementation Alternatives PS/2 has been around for quite some time and has thus far been able to serve sufficiently basic keyboard and mouse input requirements. It has been used both for interfacing embedded keyboard/pointer devices as well as for acting as an extension to provide more comfortable full-size desktop attachments. Architecturally there are two alternative ways to implement the PS/2 solution in portable systems. A. Direct Interface to the ISA bus Typically PS/2 is implemented with an 8042 compatible keyboard controller now offered by several IC manufacturers in different shapes and sizes. These
controllers offer a register and pin compatible interface to the ISA bus, ensuring BIOS compatibility in PC compatible architectures. At a minimum, the keyboard controller supports scanning of the embedded keyboard/keypad, interface to an internal pointing device and an 8042 compatible expansion port available to PS/2 compatible external keyboards and mice. Higher-end controllers support other system specific functions such as LCD control and battery and power management. ISA bus Embedded Keypad
Embedded Pointer 8042 Compatible Interface
Other Functions
PS/2 Port
External Devices
Figure 1: Keyboard Controller Implementation
B. Interface to the PS/2 Ports of an I/O chip An alternate implementation method is suitable for systems employing chip sets with an embedded 8042 controller. In this case the basic input device interface is implemented with a keyboard encoder, as illustrated in Figure 2.
I/O Chip Embedded 8042 Port PS/2 Port
Other Functions
PS/2 Port
Embedded Keypad
Keyboard Encoder
External Devices
Figure 2: Keyboard Encoder Implementation At the very least, the encoder provides keyboard scanning and the PS/2 keyboard interface to the system necessary to implement the standard PS/2 keyboard boot device. In more complex implementations, the encoder will also support an embedded pointing device, an 8042 compatible expansion port as well as other system specific functions such as power management and LCD support. Expansion Port Most portable systems provide at least one 8042 compatible expansion port for connecting an external desktop keyboard or a PS/2 compatible mouse. The keyboard controller or encoder needs to support swapping of the two types of devices on the same port, as well as hotplug-ins.
code set and the specific key attributes that may have been programmed by the OS for the scan code set 3 operation must be synchronized. In the mouse case, the device has to be programmed to match the desired report rate, resolution, mode and other attributes of its operation. Although part of these functionality can be supported by special drivers, the most robust method is to support hotplug-ins within the keyboard encoder/controller itself and transmit it transparently to the host system. Power Management Issues An optimal implementation for power management requires that the input device interface consumes the minimum amount of current in periods of inactivity while maintaining the capability of detecting user input. This function can be accomplished by the “Self Power Management” method in which the IC enters a “stop” mode even in between keystrokes. Implementations with a keyboard encoder as opposed to a keyboard controller are more suitable for implementing lower power modes since encoder ICs are typically capable of operating in lower frequencies and do not need to keep an alive interface with the host bus when the system is active. Their operation is primarily determined by user activity. Power planes control
Support of device-type swapping and hot-plug-ins requires that the newly connected device is synchronized at the moment of connection with the internal BIOS state as well as with the embedded device(s). In the case of a keyboard, the LED status, the typematic rate, the scan
In a typical system, the encoder will control built-in peripherals such as the keyboard matrix, digital potentiometers for LCD contrast and brightness, LEDs as well as an optional external PS/2 compatible port. The encoder can also
be used as the sole power management IC to control the user invoked “resume” transition on any system based on PC compatible chip sets. The low power consumption and the “Self Power Management” characteristics of the encoder make it suitable to be used as the only peripheral IC that remains powered-on while the system enters into the “suspend” mode. Because the encoder controls the user interface (keypad/keyboard), it is naturally positioned in the system to provide “resume” SMI (System Management Interrupt) on any user keystroke. Systems employing the method can turn the power off to any other peripheral including the 8042 keyboard controller. System “resume” can be accomplished either by pressing a dedicated key on the keyboard or on any key at the designer’s option. Implementation of “any key resume” will result in loss of the first keystroke. The encoder IC can be powered by its own power line without contributing any significant load to the system battery. Any other interconnected peripheral, including the 8042 keyboard controller, LEDs and an external keyboard can be powered by a switched power plane which can be turned off whenever the system enters the “suspend” mode. Leakage Currents Unless certain precautions are taken, switching off devices that are interconnected through signal lines with powered devices will cause leakage currents. These currents will increase system power consumption and defeat the purpose of power management. The following diagram illustrates a typical implementation using the UR5HCPLX
interconnected with switched rail powered devices. Switched Vcc Power Rail
External PS/2 Device
Encoder
8042
Always-on Vcc
Figure 3: Power Plane Connections In order to control leakage currents when interconnecting powered with unpowered devices, designer should make sure that the switched off power plane voltage drops all the way to ground (within 50 mV). Floating un-powered lines may indicate uncontrolled current paths and will prevent any system from achieving optimized power consumption. According to Figure 3, the encoder is primarily connected to two switched active devices: the external keyboard and the 8042 keyboard controller. Signal lines connected to these devices are normally open collector. The encoder will monitor the voltage of the switched power plane. When the power plane is switched off, all participating open collector outputs are driven low to prevent leakage currents and noise induced signals through the floating inputs. Pull-up resistors of the open collector outputs should also be turned off. If the system re-establishes power both to the 8042 and the external device, the encoder should be notified through a wake-up pulse provided by the system. If the 8042 is not powered off, the wake
up information can be provided through a command from the system. When connection with the external device is re-established, the previous state of the external device should be set either through software drivers or directly from the keyboard encoder. The following state diagram shows the power management states of the UR5HCPLX, along with the power consumption associated with each state.
Keyboard controllers as opposed to keyboard encoders need to provide an ISA bus interface increasing the number of pins and subsequently the area occupied by the IC. More savings can be accomplished by integrating the 8042 bus interface within the chip set. The following table lists typical pin counts for some of the more popular keyboard controllers and encoders.
Keypad or system activity
Active
No further processing and Ext KBD connected or LEDs on
2 mA Keypad activity issue RESUME
External KBD connected and/or LEDs are on
Keyboard or system activity Switched power is off
Wait
Stop and Disconnect
2 uA
Switched power is now on
No activity, LEDs or Ext KBD
Keypad or system activity
Ext KBD connected
800 uA
LEDs off and/or Ext KBD not connected and no activity
Switched power is off Stop and Connected
Product/ Manufacturer
Pin #
Type
8051SL/Intel IKAP/Hitachi M38802/Mitsubishi Lapkat/Motorola
100 80 80 160
PlexiCoder/USAR
44
Controller Controller Controller I/O/ Controller Encoder
Table 1: Pin count of keyboard/mouse ICs
2 uA
Figure 4: Power States of the UR5HCPLX Real Estate Issues The following diagram illustrates the relative area occupied by a square IC as a function of the number of pins.
The additional number of pins on each specific controller, in addition to accommodating the bus interface, indicates added functionality and I/O capability and reflects different design philosophies on input device sub-system implementation. Plain and Super Controllers
Relative IC Area 1400 1200 IC Area
1000 800 600 400 200 0 44
64
100
128
144
No of Pins
Figure 5: IC Area vs. Pin numbers
In the laptop industry, the keyboard controller often has been used to accommodate a set of system functions that were not served by the standard PCcompatible architecture. Such functions include battery management, LCD brightness and contrast control and different-type sensor interfacing. These functions are specific to each design and are accommodated by dedicated I/O pins, A/D and D/A channels as well as
by additional computing power and memory size. The introduction of new standards designed specifically to accommodate these un-met system functions, such as the SMBus/On-board ACCESS.bus, and the implementation of the supporting hardware on the chip sets will eventually provide for more standard and modular implementations. Upcoming Technologies Two upcoming technologies are expected to affect the input device system implementation: SMBus/Onboard ACCESS.bus and USB. SMBus/On-board ACCESS.bus will meet the need for an internal low power control bus with a standard system interface that will accommodate a set of functions that are currently served by either the keyboard controller or other proprietary methods. Derived from the 2 mature I C architecture designed jointly by Philips and Digital Equipment Corporation, the specification allows TM Smart Batteries to communicate present state, calculated and predicted battery information to the host system, enabling end-users to control system power management functions and command a battery re-charge through a software interface. End-users will also have the ability to utilize different types of batteries, such as nickel-cadmium, lithium etc., interchangeably without having to reconfigure the system. USB will provide for external peripherals expandability in portable systems and may also accommodate current and future UIDs. USB, operating at 12 Mbps with a low speed un-shielded
sub-channel operating at 1.5 Mbps, is based on a tiered star hub topology master/slave architecture and offers both asynchronous and isochronous data transfer. The specification promises automatic configuration “plug and play” of low and medium speed peripheral devices such as keyboards, mice, joysticks, modems, scanners and printers. These devices can be hotplugged through a single port. In addition, USB offers support for new computer telephony integration capabilities to allow mixed media information, including sound, images and data, to be communicated without the need for specialized add-in telephony connections. The data rate is also sufficient for CD-ROMs and MPEG-2 video. In short, USB is intended to pick-up where PS/2 left off. While, as has been mentioned previously, the PS/2 standard still adequately serves traditional keyboards and mice, the emergence of new types of input devices, such as VR helmets and gloves, will exhaust the limited resources of the standard. Further, as designers try to stretch the limitations of PS/2 to accommodate new technologies (often by introducing proprietary "enhancements"), the purity of the standard will erode. In the near future, a high speed serial bus - one that can satisfy end-user demands for increased performance UIDs while simplifying the connection of those UIDs - will not be a luxury; it will be a necessity. But for now, we have PS/2.
