Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/4401—Bootstrapping
  • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
  • G06F9/4413—Plug-and-play [PnP]
  • G06F9/4415—Self describing peripheral devices
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
  • G06F13/10—Program control for peripheral devices
  • G06F13/102—Program control for peripheral devices where the program performs an interfacing function, e.g. device driver

Definitions

• the present invention relates to peripheral devices of a computer system and more particularly to a method and apparatus for providing a software interface between a system and a peripheral device.
• a typical computer system comprises one or more processors, control devices, memory, and input/output devices along with the necessary interconnects that allow these devices to communicate with one another.
• a processor includes, for example, a microprocessor, microcontroller, or other device that is capable of performing mathematical computations.
• a processor is commonly considered to be the "brain" of a computer system, while the memory and control devices support the processor by providing information storage and organizing the flow of information, respectively, within the system.
• a peripheral device is typically a user-installed, optional device that adds additional performance capability to the basic computer system.
• a disk drive may be thought of as a peripheral device.
• a disk drive supplements a basic computer system by providing additional memory and a means for long-term storage of information.
• a modem is a peripheral device that supplements a basic computer system by providing a means for communicating information to a remote location via telephone lines.
• Basic input and output devices such as a keyboard and a display screen, are examples of other peripheral devices.
• peripheral device Once a peripheral device is physically coupled to a computer system, generally via an electrical socket that accommodates easy coupling and decoupling, the processor, memory, and other devices of the system gain access to the peripheral device through a series of interlinks called buses. Through these buses, various parts of the system are able to communicate with the peripheral device. This communication, also known as interfacing, involves the exchange of data from one device to another.
• both the system and the peripheral device must be speaking the same interface language. This requires that the system be aware of certain parameters of the peripheral device. For example, where the peripheral device is a memory device used for data storage, the system needs to know the amount of data that can be stored in the device so that the system can allocate and more effectively manage the flow of data sent to (written) and taken (read) from the device. The system also needs to know the proper protocol for reading or writing data this data. As another example, if the peripheral device is a modem, the system needs to know the speed at which the modem transmits data, as well as the protocol for sending data to the modem for transmission, so that the system can download data to the modem in a manner in which the modem can accept it.
• the software that provides the system with the necessary parameters and enables the system to interface with the peripheral device is called the peripheral device driver, or driver code, or, simply, driver.
• the source code for a driver is typically written in a high-level language or the processor's assembly language, then compiled into an object code executable file.
• This executable is stored on a floppy disk that accompanies the peripheral device, and a user installs the compiled driver as an executable in the memory of the computer system to which the peripheral device is to be coupled.
• the driver may alternatively be stored in the peripheral device itself or come pre-loaded in the computer system in either the operating system or the BIOS. Thereafter, when the peripheral device is accessed, the system uses the executable to enable the interface.
• Different drivers are associated with the same type of peripheral device, depending on the make, model, and configuration of the peripheral device, and the make, model, and configuration of the system for which the peripheral device is intended.
• One reason for multiple drivers is that the executable driver code is compiled in a processor- specific manner. In other words, a peripheral device driver that has been compiled for one type of processor is virtually unreadable by another type of processor. Therefore, a peripheral device having driver code that has been compiled for a type "X" processor can only be used in a computer system comprising a type "X” processor. An essentially identical peripheral device having driver code that has been compiled for a type "Y” processor can only be used in a computer system comprising a type "Y” processor.
• An object of the present invention is to provide a method for interfacing between a system and a peripheral device.
• Another object of the present invention is to provide a method by which an interface between a system a peripheral device is processor- independent.
• a peripheral device for use in interfacing with a system.
• the peripheral device contains driver code stored in memory locations within the peripheral device.
• the driver code is uncompiled, and, when read by a system to which the peripheral device is coupled, enables the system to interface with the peripheral device.
• Figure 1 is a block diagram of a system to which peripheral devices are coupled.
• Figure 2 is a sample of interpretive driver code.
• a peripheral device is described along with a method by which driver code is provided that enables the peripheral device to interface with the system to which it is coupled.
• the peripheral device contains its associated driver code stored in memory locations within the peripheral device.
• the driver code is uncompiled, meaning that the driver code can be either source code or interpretive code.
• the driver code is source code
• the code is first read by the system to which the peripheral device is coupled, and is then stored in memory locations within the system.
• the system contains an appropriate compiler for compiling the source code into an executable file, which is then executed by the system, thereby enabling the system to interface with the peripheral device.
• the driver code is interpretive code
• the code is first read by the system to which the peripheral device is coupled, and is then stored in memory locations within the system.
• the system contains an appropriate interpreter for interpreting the source code, thereby enabling the system to interface with the peripheral device.
• a peripheral device and method of providing an interface between the peripheral device and a system, will be described in more detail below.
• FIG. 1 is a block diagram of a system 100 to which peripheral devices 106-108 have been coupled.
• System 100 comprises an operating system driver interface 101 , which is coupled to an interpreter and driver administrator 102, which is coupled to three memory locations (or access thereto) 103-105. Each memory location 103, 104, and 105 interfaces with each of peripheral devices 106, 107, and 108 respectively.
• Operating system driver interface 101 provides the interface between the commands initiated by the system user and the peripheral devices.
• peripheral memory cards such as Personal Computer Memory Card International Association-compliant (PCMCIA) cards, PC or CardBus cards
• the operating system driver interface comprises a file system/media manager and a card services interface.
• the file system/media manager partitions and manages the memory media by, for example, providing for directory and subdirectory levels for a user, and associating each of these levels to memory locations.
• the card services interface based on the memory location indicated by a read or write command initiated by the file system/media manager, determines which of a plurality of peripheral memory cards is being accessed, and passes the command along to the proper technology driver. The system then interfaces with the appropriate memory card through the associated driver to execute the command.
• Peripheral device 106 is a fax-modem that is capable of converting data from system 100 into telephone signals for transmitting the data to a remote location. Fax-modem 106 is also capable of transmitting data received via a telephone signal back into the system. Therefore, fax-modem 106, in addition to being coupled to system 100, is also coupled to a telephone line (not shown).
• Peripheral device 107 is flash memory that provides system 100 with non-volatile, flash memory for storage of data.
• Peripheral device 108 is a video capture device that digitizes incoming images from a camera and provides the data associated with those images to system 100 for manipulation or storage.
• system 100 is a desktop or mobile computer system, and peripheral devices 106 - 108 are compliant with the PCMCIA or CardBus standards. Many of the terms and operations mentioned herein may be found in a standard PCMCIA driver specification.
• Each of peripheral devices 106 - 108 comprises memory locations large enough to store the driver code for the associated peripheral device.
• memory of each of peripherals 106 - 108 is stored its associated driver as interpretive code, which is capable of being interpreted by an interpreter.
• the system to which a peripheral device is coupled contains or has access to driver memory locations within the system.
• the driver code stored in the memory of a peripheral device is read into the system by the driver administrator and stored in the appropriate driver memory location within the system.
• the interpretive driver code is stored in protected regions of memory of the associated peripheral device.
• a protected region of memory is a memory location from which the contents of the memory cannot be readily erased or written-over, making it difficult to corrupt the interpretive driver code stored in peripheral device memory through normal use and operation of the peripheral device.
• System 100 before transferring the interpretive driver code of a peripheral device into system memory, must first be apprised of the basic information needed to load the driver code into driver memory locations 103 - 105. For example, the driver administrator must know where the driver code resides within the memory of a particular peripheral device. This basic information may be obtained either from predefined memory locations with the peripheral device, or via previously installed set-ups within the system. After the interpretive driver code has been read from the peripheral device and stored in system memory, communication with the peripheral device is primarily conducted in accordance with the software interface established by the driver.
• interpretive driver code which may be the entire code stored in the peripheral device or some portion thereof, has been transferred from the peripheral device 106 - 108 to driver memory locations 103 - 105 within the system
• the inte ⁇ reter in the int ⁇ reter/driver administrator 102 of the system interprets the code as needed to interface with the peripheral device.
• Interpretive code is code that need not be compiled before executing it.
• BASIC is one example of interpretive code. Interpretive languages are usually generic across various processors. So, for example, a driver written in BASIC for a system comprising processor "X” will also run on a system comprising processor "Y,” notwithstanding incompatibilities between processors "X” and "Y,” as long as a BASIC interpreter is provided in each system.
• An interpreter which may be processor-dependent, is the tool through which an interpretive language is executed.
• the peripheral devices coupled to a system contain source code rather than inte ⁇ retive code as the device driver software.
• Source code before being executed, is typically compiled into an object code executable. Therefore, for this embodiment, the system contains (or has access to) a compiler.
• the source code driver Upon transferring the source code driver from the peripheral device by reading it into driver memory locations of system memory, the source code is compiled into object code by the compiler, and is stored in system memory as an executable file. The system then executes the file as needed to interface with the peripheral device.
• Source codes like inte ⁇ retive codes, are usually generic across various processors.
• a source code driver written for a system comprising processor "X” will also run on a system comprising processor "Y,” notwithstanding incompatibilities between processors "X” and “Y,” as long as a compiler, which may be processor-dependent, is provided in each system.
• a system comprising a digital camera, uses flash storage devices, or flash cards, as the film upon which digital images from the digital camera are stored.
• each flash card contains its associated driver code stored in an inte ⁇ retive language in memory within the card.
• the digital camera comprises an interpreter/driver administrator and memory.
• the digital camera After a picture is taken, the digital camera stores the data associated with the picture into the flash card by calling on the operating system driver interface to write the data into the attached flash card.
• the driver administrator reads the section of memory within the flash card containing the desired driver code related to write operations, and stores this code in memory within the camera.
• the camera then proceeds to execute or run this code using the int ⁇ reter, thereby enabling an interface between the camera and the flash card, storing the data in the flash card.
• the system is an audio recording device which stores digital audio signals in peripheral flash memory.
• the system is a personal data assistant (PDA) or cellular phone which uses peripheral devices to perform functions such as storing or displaying data.
• PDA personal data assistant
• BASIC is one type of inte ⁇ retive language.
• BASIC is a relatively extensive language, resulting in a substantially large interpreter to inte ⁇ ret the language and fairly high computational requirements.
• a new interpretive language is developed, along with an associated inte ⁇ reter, which is optimized for the particular application for which the inte ⁇ retive driver code will be used.
• Figure 2 is a sample of interpretive driver code that has been written in a new interpretive language that has been optimized for flash memory peripherals. Only the lines of code associated parameter settings and the write operation are shown here. A more complete interpretive driver code sequence would additionally include, for example, lines of code associated with the read and erase operations.
• the first line of code of Figure 2 "PARAMETER_START” indicates that this is the section of the code that provides parameter information related to the parameters of the flash card.
• WIDTH 08" indicates that this is a x8 card.
• WRITE_START indicates that this is the section of the code that provides the protocol for executing a write operation to the flash card.
• a write command is initiated by the operating system driver interface of the system, in response to, for example, a system user command.
• the write command is directed to the interpreter/driver administrator in the form of a write request packet comprising 1) the request type (write in this case); 2) the number of bytes to be written (called “number_bytes” in Figure 2); 3) the destination address of the data (called “destination_address” in Figure 2 and refers to the flash card in this case); and 4) the source address of the data (called “source_address” in Figure 2 and usually refers to a buffer in system memory).
• the interpreter/driver administrator In response to a write command, the interpreter/driver administrator, if it hasn't already done so, will load either the entire interpretive driver code or only the write portion of the code from the peripheral device into the appropriate driver memory location with the system. The interpreter/driver administrator then locates the "WRITE_START" line in the interpretive drive code within the system, and begins to execute what follows.
• "OUTPUT destination_address + offset, write_command” instructs that the data or control commands following the "OUTPUT” command be sent to the flash card.
• the destination address sent with the write request packet is offset by the "offset” variable (0 in the first iteration) and is sent a "write_command,” which is a flash card-specific command that indicates that the next write to that address contains data to be stored.
• "OUTPUT destination_address + offset, source_address + offset” instructs that the data stored in the source address, offset by the "offset” variable, is to be stored at the destination address, also offset by the "offset” variable.
• Card_status is flash card-dependent value that the flash card provides to the system to indicate whether or not the previous OUTPUT command to write data into the flash card executed properly.
• Write_valid is also a flash card- dependent value that is equal to the value the flash card provides to indicate a successful write operation has taken place.
• the interpreter determines if the counter has reached 100, and if so, the inte ⁇ reter is instructed to jump back up to the line labeled "BEGIN" so that the data can be rewritten.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Computer Security & Cryptography (AREA)
• Devices For Executing Special Programs (AREA)

Priority Applications (1)

Applications Claiming Priority (2)

Publications (1)

Family

ID=24322652

Family Applications (1)

Country Status (4)

Cited By (2)

Families Citing this family (24)

Citations (4)

Family Cites Families (1)

• 1995
  • 1995-12-29 US US08/580,808 patent/US5835772A/en not_active Expired - Fee Related
• 1996
  • 1996-12-27 AU AU15684/97A patent/AU1568497A/en not_active Abandoned
  • 1996-12-27 WO PCT/US1996/020809 patent/WO1997024656A1/en not_active Ceased
• 1997
  • 1997-01-29 TW TW086100984A patent/TW318227B/zh not_active IP Right Cessation

Patent Citations (6)

Also Published As

Similar Documents

Legal Events