Peripheral device control

                               Peripheral device control

Buffers

An operating system is often able to pass input data to an application program far faster than an input device can supply it. Similarly, it can often supply the application program’s output data far faster than an output device can accept it. To compensate for the difference in rates of data processing and allow the processor to perform other tasks while waiting to receive or send data, system software called a device driver manages the transfer. This driver uses an area of memory to hold data temporarily. Such an area in memory is called a buffer.

    For example, a computer’s printer driver creates a printer buffer in memory to hold data for the printer when the printer is busy. The printer driver transfers output data to the buffer. It then waits until the printer has finished processing previous data or the user has attended to an error message (such as ‘out of paper’) before transferring the new data.

 Polling of peripherals

Peripheral devices cannot control the transmission of data to and from the computer. Only a running program can do that. So how does a peripheral device attract the operating system’s attention to signal that it is ready to send data to a device driver’s buffer or that it has finished receiving data from such a buffer? For example, the printer may need to signal to the computer’s printer driver that it has successfully received the data sent to it and is ready for more, or that it has run out of paper or link.

   One method is for the operating system to be responsible for checking for communication from peripheral devices by periodically interrogating each peripheral device in turn to discover its status. This is known as polling.

  Imagine a robot truck that has a number of sensors for obstruction. If a sensor spots an obstruction in front of it as the truck moves across a factory floor, it must alert the operating system. Although the operating system may be busy with other tasks, it is programmed to poll the sensors sufficiently frequently that there is little chance of the robot hitting the obstruction before the operating system checks the data from the relevant sensor. The disadvantage of this method is that the operating system has to devote significant processing time to polling all the peripheral devices, even when the devices are not active. A system in which a peripheral device waits to be asked whether it needs the attention of the operating system is called a polling system.

Peripherals interrupting the operating system

To reduce the amount of time the operating system spends polling, processors were designed to accept a separate type of signal called an ‘interrupt’. An interrupt is signal sent from a peripheral device (hardware) or program (software) to the processor to indicate that the sender needs attention. This leaves the operating system entirely free to process other tasks until its attention is needed. A system in which a peripheral device signals that it needs the attention of the operating system is called an interrupt system.

  A processor usually has relatively few hardware interrupt inputs with different priorities. Before fetching each machine code instruction from internal memory, the processor checks an area of memory within the processor called its ‘interrupt register’ to see whether any interrupts are waiting to be serviced.

   One way of allowing a number of peripheral devices to share these interrupt inputs is for the processor to respond to an interrupt signal by polling the peripherals devices. This wastes  a certain amount of time polling, but now polling only occurs when a peripheral is known to need attention. Another for responding to interrupts is known as ‘ vectored  interrupt’, in which a peripheral device supplies an internal memory address of the appropriate interrupt handler program code.

  An obstruction sensor in our robot truck would need to generate a high priority to ensure that its input data are handled quickly to avoid hitting obstructions. Interrupts with high priority can be handled extremely rapidly. For example, if a peripheral device monitoring the power supply voltage a detects a sudden drop indicating that a power failure is starting to occur, it can interrupt the processor to request saving the state of all the running programs to disk before the power supply is actually lost. If this succeeds, when the user re-starts the computer, the saved data enable the computer’s operating system to resume operating with the running programs in the same state that they were in before the power failure. An ‘uninterruptible’ power supply’ similarly uses a microcontroller to rapidly switch from mains to battery power to continue to run a computer for long enough that it can be shut down using the normal procedure.

  We said earlier that programs can also generate interrupts. An application program can use a software interrupt to request a service from the operating system. The sort of service an application requires would include opening a file from a disk drive or exiting the application. This is known as a ‘ system call’. Sending the interrupt to the operating system to request a service passes control back to the operating system. Since the operating system passed control to the application program in the first place, in effect, the application has interrupted itself to fulfil the user’s request.

Handshaking

In many cultures, people use a handshake as a physical gesture or ‘body language’ to indicate that they are ready to start communication or that they are ending communication with each other. We often use such as ‘ Hello’ and ‘Goodbye’ as the verbal equivalent.

  Computers need to do similar things, sometimes to negotiate the rules or ‘protocol’ that they will use to communicate for the rest of the session. For example, they have to find a data transfer rate that is acceptable to both computers and to decide whether odd or even parity will be used. A computer also often needs to control the flow of data over a network with another computer or between the computer and a peripheral device such as printer. ‘Flow control’ is necessary to prevent a delay in processing data at the receiving end resulting in lost data or an irretrievable breakdown in communication.

  A computer’s handshaking may involve sending electronic signals as special codes down the normal data channel or, in some cases, sending extra signals down a separate hardware wire in a short cable.

  As an example, we look at how a computer’s printer driver program sends data to a printer over a USB connection. To start the transmission of a data packet (a bundle of up to 512 bytes), the computer’s ‘USB host controller’ sends a relatively small OUT ‘token packet’ to the printer. This informs the printer that the computer is ready to send data. The ‘handshake packet’ from the printer replies with one of the following options:

-         Successful reception (ACK, short for ‘Acknowledged’);

-         The printer’s buffer is not yet empty because it is still processing a previous data packet (NAK, short for ‘Not acknowledged’);

-         The printer has encountered an error (STALL).

The complete process for transmitting one data packet looks like this:

1.    The printer driver program fills the print buffer and requests the host controller to send the data to the printer.

2.    The host controller sends an OUT token packet immediately followed by a data packet to the printer. Although the OUT packet is not technically a handshake packet, it marks the beginning of a handshaking flow control process.

3.     The printer’s USB hardware sends an ACK handshake packet to inform the host controller that it has successfully received the packet in its input buffer.

4.     The printer’s USB hardware generates an interrupt signal to the printer’s microcontroller.

5.     The printer’s firmware handles the interrupt by reading the processing the contents of its input buffer. The steps above are repeated, possibly thousands of time, until the host controller generates a hardware interrupt to the computer’s operating system to signal that the data transfer requested by the printer driver is complete.

Checksum

When data are transferred to and from peripherals and over networks, they vulnerable to signaling errors. It is therefore important to check that they have not been corrupted. In other words, we ensure that their ‘integrity’ ( their completeness and correctness) has been preserved.

  A checksum is a way of summarizing a block of data such as a USB or network data packet. At its simplest, it consists of the arithmetical sum of all the numerical values of all the elements of the block. The sum is reduced to a standard number of digits and transmitted with the block. When the block of data gets to its destination, the same mathematical calculation is  performed on the data by the receiving device and the  result is compared with the received checksum. If the two checksums match, the integrity of the data has been maintained. If the two checksums do not match than an error has been made in transmitting the data and the receiving device requests the sending device to re-transmit the data. Even if one binary digit has changed in the data, the recalculated checksum and the data are rejected.

   You may recognize a checksum as being similar in function to a parity bit for a byte or a check digit for a code number. More complex implementations of a checksum involve more complex arithmetic to try to detect a wider range of errors. Cryptography can be used to try to prevent someone from maliciously substituting different data with the same checksum.