| timer_cancel | Cancels a currently running timer. This operation cancels a timer by removing the currently running timer from the timer-handling facility. |
| Input Parameter: 1. An ID identifying a previously created timer structure |
The third group is mainly used by user-level applications. The operations in this group interact either with the system clock or with the real-time clock. A system utility library offers these operations. Each operation in the group is given a fictitious function name for this discussion. Actual function names are implementation dependent.
Table 11.3: Group 3 Operations.
| Typical Operations | Description |
|---|---|
| clock_get_time | Gets the current clock time, which is the current running value either from the system clock or from the real-time clock. |
| Output Parameter: A time structure containing seconds, minutes, or hours[3] | |
| clock_set_time | Sets the clock to a specified time. The new time is set either into the system clock or into the real-time clock. |
| Input Parameter: A time structure containing seconds, minutes, or hours[3] |
11.8 Points to Remember
Some points to remember include the following:
· Hardware timers (hard timers) are handled within the context of the ISR. The timer handler must conform to general restrictions placed on the ISR.
· The kernel scheduler depends on the announcement of time passing per tick.
· Soft timers are built on hard timers and are less accurate because of various delays.
· A soft-timer handling facility should allow for efficient timer installation, cancellation, and timer bookkeeping.
· A soft-timer facility built using the timing-wheel approach provides efficient operations for installation, cancellation, and timer bookkeeping.
Chapter 12: I/O Subsystem
12.1 Introduction
All embedded systems include some form of input and output (I/O) operations. These I/O operations are performed over different types of I/O devices. A vehicle dashboard display, a touch screen on a PDA, the hard disk of a file server, and a network interface card are all examples of I/O devices found in embedded systems. Often, an embedded system is designed specifically to handle the special requirements associated with a device. A cell phone, pager, and a handheld MP3 player are a few examples of embedded systems built explicitly to deal with I/O devices.
I/O operations are interpreted differently depending on the viewpoint taken and place different requirements on the level of understanding of the hardware details.
From the perspective of a system software developer, I/O operations imply communicating with the device, programming the device to initiate an I/O request, performing actual data transfer between the device and the system, and notifying the requestor when the operation completes. The system software engineer must understand the physical properties, such as the register definitions, and access methods of the device. Locating the correct instance of the device is part of the device communications when multiple instances of the same device are present. The system engineer is also concerned with how the device is integrated with rest of the system. The system engineer is likely a device driver developer because the system engineer must know to handle any errors that can occur during the I/O operations.
From the perspective of the RTOS, I/O operations imply locating the right device for the I/O request, locating the right device driver for the device, and issuing the request to the device driver. Sometimes the RTOS is required to ensure synchronized access to the device. The RTOS must facilitate an abstraction that hides both the device characteristics and specifics from the application developers.
From the perspective of an application developer, the goal is to find a simple, uniform, and elegant way to communicate with all types of devices present in the system. The application developer is most concerned with presenting the data to the end user in a useful way.
Each perspective is equally important and is examined in this chapter. This chapter focuses on:
· basic hardware I/O concepts,
· the structure of the I/O subsystem, and
· a specific implementation of an I/O subsystem.
12.2 Basic I/O Concepts
The combination of I/O devices, associated device drivers, and the I/O subsystem comprises the overall I/O system in an embedded environment. The purpose of the I/O subsystem is to hide the device-specific information from the kernel as well as from the application developer and to provide a uniform access method to the peripheral I/O devices of the system. This section discusses some fundamental concepts from the perspective
