Orginal of this paper is at http://www.qnx.com/literature/whitepapers/pcmcia.html
The PCMCIA standard was created to make it easy to install memory, mass storage, LAN cards, and other types of expansion products in small portable computers. PCMCIA is also being used in industrial and embedded applications because of its convenience and cost-effectiveness.
One feature of PCMCIA is the ability to have the software support live insertion (and removal) or "hot-swapping." While hot-swapping is part of the PCMCIA specification, and conforming sockets are designed to generate a hardware interrupt upon a card’s insertion/removal, the underlying operating system must recognize this interrupt and configure the cards to make them available.
Under DOS, PCMCIA device drivers are loaded at boot time. Should a change be necessary, the appropriate configuration files are modified and the computer is reset.
In the class of applications running in the realm of realtime computing, this is simply not acceptable. Since mission-critical monitoring and control systems need to be highly available, an alternative is needed to configure these devices.
This paper provides an overview of PCMCIA and describes how dynamic configuration of PCMCIA devices allows the host computer to function uninterrupted from its mission-critical duties and remain highly available.
PCMCIA (Personal Computer Memory Card International Association) is a technical design standard and an international industry trade association that was established in June 1989. PCMCIA membership has grown substantially from its inception and now includes companies such as Apple, AT&T, IBM, Kodak, Lotus, Microsoft, Novell, Polaroid, QNX Software Systems, Toshiba, and others.
PCMCIA’s original goal was to develop standards and to promote the worldwide adoption of PCMCIA-based products. All of this was done in the hope that the adoption of the PC Card standards would promote interoperability and upgradability and ultimately provide a cost-effective alternative to proprietary expansion cards that were once the norm in the portable computer market.
QNX is a microkernel-based, message-passing, realtime, POSIX-compliant, multitasking operating system. QNX is the leading realtime OS for PCs and has been used in hundreds of thousands of installations in areas such as industrial automation, medical instrumentation, point-of-sale, financial online transaction processing, and communications.
As mentioned above, QNX Software Systems is also a member of PCMCIA. In addition, we have worked closely with a number of manufacturers including Adaptec, Socket Communications, SunDisk, and others offering PC Card Solutions.
The PCMCIA Consortium has been successful in seeing PCMCIA adopted as a standard. PC Cards have become widespread on portable computers and are very cost effective. There has even been movement to install PC Card slots on desktop computers to facilitate the sharing of data and peripherals.
Because of this widespread acceptance, PC Cards are now being designed into many embedded systems. All the advantages PC Cards offer, can now be enjoyed by the embedded system engineer:
A special advantage of PC or PCMCIA Cards is that they relieve the embedded designer from having to build proprietary buses, interfaces and/or expansion peripherals. Even with the tiniest of
form factors, PCMCIA socket hardware is readily available and can be very easily integrated into the embedded design at much lower costs than a proprietary equivalent.
PCMCIA has become so popular that other bus architectures (such as PC/104) are adding PCMCIA sockets to their boards. Even more manufacturers are expected to follow suit.
A layered approach provides better hardware and software independence. Figure 1 shows how PCMCIA structured the various hardware and software layers.
The Socket hardware layer of the PC Card standard defines the physical, mechanical, and electrical characteristics of the PCMCIA slots themselves. The Socket Services layer provides the control for the Socket hardware. Socket hardware accepts card configuration commands from Socket Services and handles PCMCIA card interrupts.
Several vendors (e.g. Cirrus, Databook, Intel, and Vadem) offer socket hardware. Each of these socket manufacturers has a unique way of configuring their sockets. Providing support for different socket hardware is sometimes further complicated when enhancements or restrictions must also be incorporated (e.g. SCSI support and security issues) that were not included in the original PC Card Spec.
Socket Services is the lowest layer of host software in the multilayered scheme defined by PCMCIA. Socket Services is the hardware-dependent software (possibly resident in the host system’s BIOS1) that provides a standard method of accessing and controlling the PCMCIA slot of a computer. Socket Services connects a PCMCIA host controller to higher services such as Card Services or—if Card Services is not present—directly to device drivers. Socket Services reports how many sockets it is controlling in the host computer system and detects the insertion or removal of a PC Card.
Card Services, the hardware-independent layer of host system software, resides between Clients and Socket Services. Card Services’ Clients (e.g. device drivers, application software, etc.) make use of PCMCIA and host system resources such as memory, I/O address space, and interrupts. Card Services is a software-management interface that coordinates the Clients’ allocation and release of host system resources. Card Services notifies Clients of events such as card insertion or removal after Socket Services notifies Card Services of the events.
Clients can be device drivers, utility programs, application software, or resource managers (see below). Several Clients can be loaded into the host computer system at the same time. The Clients call various Card Services routines that control the socket hardware in order to configure and gain access to the actual PC Cards. When a PC Card is made accessible in the Client’s memory or I/O space, the Client usually accesses the card directly to perform the function the user requests.
Ideally, every PC Card is supposed to have enough information contained on the card so it can be properly configured. This descriptive data is referred to as the CIS (Card Information Structure). This information is supposed to be read by the Card Services and Client layers of the PCMCIA architecture to assist in selecting and configuring a PC Card and socket for a particular application.
However, when PCMCIA first arrived on the scene, some PC Cards were not engineered "thoroughly enough" to provide enough data in the CIS to properly configure the card. For example, a modem manufacturer’s product would not work unless vpp was set to 12 volts, but nowhere was this very important detail recorded.
As a result, implementors of the PCMCIA standard, such as QNX, had to come up with a way of recording the missing information so that PC Cards could be properly configured with a minium of user intervention. QNX created a database of PC Cards and this database provides the additional hints in the event that the CIS is incomplete.
QNX also provides a utility (pin) that will interrogate the card and the CIS on the card, so that even an unknowledgable user can easily add entries to the database to support new cards. This has proven flexible enough to accommodate all PC Cards to date.
The QNX PCMCIA architecture provides all the same capabilities mentioned above but with several distinct advantages. With PCMCIA services structured as a resource manager, we have encapsulated all the Card and Socket Services into a single entity.
But before we describe the QNX PCMCIA architecture and its advantages,
it is important to understand what a resource manager is.
QNX resource managers are discrete server processes that provide
OS extensions. Resource managers can be dynamically started and
stopped2 programmatically, or from a shell. All of the functionality
beyond QNX’s 10K microkernel is provided in the form of resource
managers including, for example; the Filesystem Manager, the Network
Manager, and the PCMCIA Manager.
Figure 2 shows the QNX microkernel surrounded by resource managers. User-supplied resource managers can also be easily written and integrated. As an extensible OS, QNX lets you add your own resource managers (e.g. I/O server, database server, etc.). These custom managers blend into the OS itself and are indistinguishable from QNX-supplied resource managers. Like all processes within the QNX environment, resource managers run in MMU (memory management unit) protected address space, preventing their corruption from errant user processes.
The architecture adopted by QNX is essentially the same as that already shown in figure 1. Still providing all the necessary PCMCIA functionality, we have integrated the Card and Socket Services into a single, efficient resource manager.
The problem with the original PCMCIA specification was that too many "DOS-isms"3 were woven into the existing Card Services to simply implement it in our 32-bit environment. We opted instead to remain compatible yet provide equivalent functionality on our own terms (32-bit, multitasking, multithreading, etc.).
Not only did we achieve our design goals, but our implementation also provides a number of additional benefits beyond what PCMCIA already offers, including improved performance, automatic dynamic configuration, and a cleaner/simpler programming interface that allows complete PCMCIA support in less than 10 lines of C code4 (See figure 3).
for(;;) {
Receive(proxy, 0, 0);
while (qnx_pcmcia_io_info(handle, _PCMCIA_DEV_Serial, &io) !=1) {
if (io.flags & _PCMCIA_FLAG_CARD) {
if (qnx_pcmcia_io_lock(handle, io.socket, io.index) != -1 {
// Initialize
}
} else {
qnx_pcmcia_io_unlock(handle, io.socket, io.index);
// Deallocate Resources and possibly clean up
}
}
}
In addition to a greatly simplified programming interface, we were able to write and provide a wrapper driver that allows existing drivers (e.g. NE2000 network driver) to work with PCMCIA devices even though the driver may have not been originally designed to do so.
As mentioned earlier, to allow the widest range of PC Card support, QNX adopted a PC Card database that can offer hints to the PCMCIA Resource Manager to properly configure the card.
This database may either be saved in a file or—in the case where a filesystem isn’t available—specified on the command line to the PCMCIA Resource Manager when it is invoked.
Another advantage to this architecture is that the onus is on us—not the application developer—to implement and support the tough parts of writing PCMCIA and to adopt any newer standards emerging from PCMCIA.
Also, the application doesn’t have to deal with hardware interrupts (unless desired) because all of PCMCIA’s asynchronous event notification (hardware interrupts) are converted to synchronous proxies (messages) or POSIX (UNIX) style singles. Asynchronous events include such things as the insertion of a card, the removal of a card, the change of state of a card, etc.
The resource manager also supports multiple clients accessing a single device (PC Card) and provides a mechanism for mutual exclusion.
To understand how all the pieces fit together, see the following table, which shows each of the steps that occur when a PC Card is inserted and removed (See Figure 4).
PCMCIA is not expecting to add any additional form factors or to allow major changes in card sizes or dimensions. Future standards will enhance and extend the existing framework. Further work is also being done to provide extensions for PCMCIA cards that need additional capabilities (e.g. high speed LAN and SCSI bus expansion cards) that are not covered by the current specification.
In some cases, software loaded on PCMCIA memory cards can execute directly from the card without requiring that it first be loaded (copied) into the host system’s main memory (RAM).
At QNX, we currently support XIP within our E-Kit (embedded kit). QNX XIP allows the direct execution of programs from Flash and SRAM. In embedded designs, this can eliminate the need to create ROM images.
The problem with using XIP technology on the current PC Card architecture (16-bit) is that the XIP is slow. However, with the advent of CardBus, XIP will likely become a viable method of booting and loading programs.
Just as the VME industry has embraced PCI, so also has PCMCIA adopted PCI to form the basis of their next PCMCIA standard, called CardBus. CardBus offers a number of advantages including the widening of the PCMCIA data path from 16 to 32 bits. This wider data path plus Plug ’n’ Play support (beyond the Plug ’n’ Play that PCMCIA already supports), mean that PCMCIA will only get better with time.
PCMCIA and realtime are a viable alternative to proprietary bus designs. With the proliferation of PC Cards, practically every type of peripheral is now available to the embedded system designer.
With the flexibility that the PC Card form factor offers, and its typical access from outside the chassis, upgrading embedded systems in the field with faster network cards and higher-speed modems will simply require the swapping of PC Cards, with neither the case nor the power having to be removed.
Given their small size, PC Card sockets will likely fit even the smallest of embedded systems.