@ 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
