@ McGraw-Hill Education

PROPRIETARY MATERIAL. © 2009 The McGraw-Hill Companies, Inc. All rights reserved. No part of this PowerPoint slide may be displayed, reproduced or
distributed in any form or by any means, without the prior written permission of the publisher, or used beyond the limited distribution to teachers and educators
permitted by McGraw-Hill for their individual course preparation. If you are a student using this PowerPoint slide, you are using it without permission.
1
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers

 Device driver is a piece of software that acts as a

bridge between the operating system and the
hardware
 In an operating system based product architecture,
User Level Applications/Tasks
the user applications talk to the Operating System App 1 App 2 App 3
kernel for all necessary information exchange
including communication with the hardware Operating System Services
peripherals (Kernel)

 The architecture of the OS kernel will not allow Device Drivers

direct device access from the user application
 All the device related access should flow through the Hardware

OS kernel and the OS kernel routes it to the

concerned hardware peripheral
 OS Provides interfaces in the form of Application
Programming Interfaces (APIs) for accessing the
hardware
 The device driver abstracts the hardware from user
2
applications
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers
 Device drivers are responsible for initiating and managing the communication
with the hardware peripherals
 Drivers which comes as part of the Operating system image is known as ‘built-
in drivers’ or ‘onboard’ drivers. Eg. NAND FLASH driver
 Drivers which needs to be installed on the fly for communicating with add-on
devices are known as ‘Installable drivers’
 For installable drivers, the driver is loaded on a need basis when the device is
present and it is unloaded when the device is removed/detached
 The ‘Device Manager (Name may vary depending on OS kernel)’ service of the
OS kernel is responsible for loading and unloading the driver, managing the
driver etc.
 The underlying implementation of device driver is OS kernel dependent
 How the driver communicates with the kernel is dependent on the OS structure
and implementation. Different Operating Systems follow different
implementations
3
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers
 The device driver implementation normally follows a layered architecture where
the upper layer provides the OS specific interface and the lower layer provides
platform dependent (device dependent) implementation
 The upper layer of this architecture is referred as ‘Model Device Driver (MDD)’
or ‘Logical Device Driver (LDD)
 The ‘Platform Dependent Driver (PDD)’ implements the platform (hardware
specific) part of the device driver
 MDD provides a platform neutral implementation for the driver
 For a standard driver, for a specific operating system, the MDD/LDD always
remains the same and only the PDD part needs to be modified according to the
target hardware
 The OS provides access to the device driver interface through a set of interfaces
called Application Programming Interfaces (APIs)
 User applications can talk to the device driver through the API interface

4
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers
 Device drivers can run on either user space or kernel space
 Device drivers which run in user space are known as user mode drivers and the
drivers which run in kernel space are known as kernel mode drivers
 User mode drivers are safer than kernel mode drivers
 If an error or exception occurs in a user mode driver, it won’t affect the services
of the kernel
 If an exception occurs in the kernel mode driver, it may lead to the kernel crash

5
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers
The way how a device driver is written and how the interrupts are handled in it are
Operating system and target hardware specific. However regardless of the OS
types, a device driver implements the following:

Device (Hardware) Initialization and Interrupt configuration

Interrupt handling and processing
Client interfacing (Interfacing with user applications)

6
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers
The Device (Hardware) initialization of part of the driver deals with configuring the
different registers of the device (target hardware). For example configuring the I/O port line
of the processor as Input or output line and setting its associated registers for building a
General Purpose IO (GPIO) driver.
The interrupt configuration part deals with configuring the interrupts that needs to be
associated with the hardware. In the case of the GPIO driver, if the intention is to generate
an interrupt when the Input line is asserted, we need to configure the interrupt associated
with the I/O port by modifying its associated registers. The basic Interrupt configuration
involves the following.
 Set the interrupt type (Edge Triggered (Rising/Falling) or Level Triggered (Low or
High)), enable the interrupts and set the interrupt priorities.
 Bind the Interrupt with an Interrupt Request (IRQ). The processor identifies an interrupt
through IRQ. These IRQs are generated by the Interrupt Controller. In order to identify
an interrupt the interrupt needs to be bonded to an IRQ.
 Register an Interrupt Service Routine (ISR) with an Interrupt Request (IRQ). ISR is the
handler for an Interrupt. In order to service an interrupt, an ISR should be associated
with an IRQ. Registering an ISR with an IRQ takes care of it.
7
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers

When an interrupt occurs, depending on its priority, it is serviced and the

corresponding ISR is invoked
The processing part of an interrupt is handled in an ISR
The whole interrupt processing can be done by the ISR itself or by invoking an
Interrupt Service Thread (IST)
The IST performs interrupt processing on behalf of the ISR
It is always advised to use an IST for interrupt processing, to make the ISR
compact and short

8
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers

The Client interfacing part of the device driver is responsible for

Informing the user application that the device has generated an interrupt and data is
received from the device
exchange of data between driver and user application through shared buffers
User applications can create events, register for the events and wait for their
occurrence
Device driver sets the event when an interrupt occurs