@ 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, the user
applications talk to the Operating System kernel for all
necessary information exchange including communication with
the hardware peripherals
 The architecture of the OS kernel will not allow direct device
access from the user application
 All the device related access should flow through the 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 applications 2
 @ McGraw-Hill Education

Designing with RTOS

User Level Applications/Tasks

App 1 App 2 App 3

Operating System Services

(Kernel)

Device Drivers

Hardware

3
 @ 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’

4
 @ McGraw-Hill Education

Designing with RTOS

Device 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

5
 @ 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

6
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers
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 7
 @ 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
8
 @ 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)

9
 @ 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.

10
 @ 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.

11
 @ McGraw-Hill Education

Designing with RTOS

Device Drivers
 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.

12
 @ 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

13
 @ 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

14