11 device drivers

8/10/2019 11 Device Drivers

1/41

Architecture of Device I/O

Drivers


2/41

Introduction

Device driver consists of a lot of "bit-bashing and register-twiddling" to convince some ornery unit of hardware tosubmit to the control of driver software.

You've got to get every one of a myriad of details rightthebits, the sequences, the timing -- or else that chunk ofhardware will just refuse to do its thing.

A device driver can be organized as a collection of "chunks"of concurrent software.

The RTOS is involved in both scheduling the "chunks" andallowing them to communicate cleanly with one another.

In different operating systems, the concurrent "chunks" ofsoftware might be given different names like 'threads' or'tasks'.

For example, in the pSOSystem RTOS they are called 'tasks'and 'Interrupt Service Routines' (ISRs).


3/41

Introduction A device driver itself is a collection of functions that are

programmed to make a hardware device perform someinput/output-related ("I/O") activities.

A driver might contain an "initialization" function, a "read"

function, a "write" function, etc.

Device drivers that work with hardware devices that deliverinterrupts also include the ISRs for thoseinterrupts as an additional component of the device driver.

The functions of a device driver can be called byapplication software tasks that would like to get somehardware I/O-related activities to happen.


4/41

Issues in Architectural Design

Low level IssuesAutomation

Organization of a Device Driver

Device I/O Supervisors

Basic Design Decisions Checklist

Mutual Exclusion for Device Access


5/41

Low-level Device Driver Issues

Interdisciplinary: Software + Hardware

Knowledge

Complex, Tedious

Hard to debug

One bit programmed wrong Device wont

work

Automation to the rescue !


6/41

The Role of Device Drivers

Information Hiding for Hardware Devices

That Interface to an Embedded Processor

Make Hardware Respond to an ApplicationProgramming Interface

Using calls that are Standardized for Many

Devices and Drivers

Application Software

Device Driver

ECU


7/41

Tasks, Processes,

Threads RTOS Interface

(Optional)

Device-IndependentServices Example:

Synchronization toApplication

HardwareAbstraction Layer


RTOS

Device

Driver

Device Hardware

Driver Upper Half

Hardware Specific Driver


8/41

Whats Done at Each Driver Layer? Driver Upper Half

Re-useable for Many Devices

Defines an I/O Model

Example: Byte I/O, Block-oriented I/O

Application Interface

Interaction with OperatingSystem

Hardware-Specific Driver

Standard Interface to UpperHalfof Driver

Device Configuration andInitialization

Data Input/Output

Device-Specific Control

Examples: Reset, ChangeScale


RTOS

Device

Driver

Device Hardware

Driver Upper Half

Hardware Specific Driver


9/41

Components of a Driver

Collection of Functions

That Make Useful Things Happen to an Input/Output (I/O) Device

Callable from Application Code, Tasks

Each Function may be structured as 1 or 2 Layers

Provide Mechanism to Operate I/O Device,Not Policy

Interrupt Service Routine(s)

To Handle Interrupt(s) from the I/O Device

Device

Init.

Device

Start.

Device

Hardware

Device

Abort

Write

Device

Abort

Read

Device

Open

Device

Close

Device

Read

Device

Write

Device

Simulate

Interrupt

Device

Get

Info

Device

Get

Config

Device

Set

Config.

Device Interrupt

Service


10/41

The Most Popular Driver FunctionsDevice Initialize

Device Open

Device Close

Device Read

Device Write

Device Control

This Model isNotAppropriate for All Devices

Device Controlis usually by far the LargestFunction

Example: MPEG Device Driver


11/41

Device I/O Supervisor In Addition to Programming Interface for Operating a

Driver

for Processors with Many Drivers, you may need

To Organize Large Sets of Drivers

Manages a set of Encapsulated Tables

Dynamically Load, Unload Drivers (?)

User

Application

Serial Device Driver

Ethernet Device Driver

Other Device Driver

User Mode Supervisor ModeDevice I /O Supervisor


12/41

Checklist: Basic Decisions in Driver

Design Layered Driver ?

Assembler Coding or High-Level Language ?

Source of Low-Level Bit-Bashing Code ? Automated Code-Generation Tool

Chip Manufacturers Free Driver

Hand-Coding

Which Driver Functions to Implement ?

Do I Need a Device I/O Supervisor ?

Mutual Exclusion Requirement ?

Synchronous or Asynchronous Driver ?


13/41

Mutual Exclusion for Device

Access? Device Driver may need to ensure use by No More than 1

Task at a time can request an input or output operation on a

specific device

Use a Mutex Alternatives: Semaphore, Mailbox or Message Queue

Print

Im TSK1

Print

Im TSK2

Im TSK1 Im TSK2


14/41

Mutual Exclusion Unnecessary?

Reentrancy !

Special Discipline Required to Write Reentrant

Code

No Static Variables

Put all Variables on Stack

Or Stack of CallerNo Self-Modifying Code

Beware: Libraries


15/41

MUTUAL EXCLUSION OF DEVICE

ACCESS

For devices that may be thought of as "session-oriented",exclusive access must be granted for an entire "session"which may consist of many individual I/O operations.

Example, a single task might want to print an entire page

of text, whereas the printer driver's output function canprint only a single line of text.

In such a case, a driver's 'open session' operation wouldrequest the semaphore token.

And a 'close session' operation would return the semaphore

token. Any other task attempting to 'open session' while thesemaphore's token is unavailable, would be denied accessto the driver software.


16/41

Models for Device Drivers

Synchronous vs. Asynchronous Drivers

Synchronous I/O Models

Asynchronous I/O Models

Latest Input Only Drivers (Asynchronous) Simple Asynchronous Output Driver


17/41

Synchronous Vs. Asynchronous I/O Models

A much larger question in structuring adevice driver, is the question of synchronousversus asynchronous driver operation.

To put it another way: Do you want theapplication task that called the device driver

to wait for the resul t of the I /O operation

that it asked for? ... Or do you want theapplication task to continue to run while the

device driver is doing its I /O operation?


18/41

Synchronous or Asynchronous Driver ?

Synchronous Driver Requesting Task waits for Driver I/O operation to

complete

RTOS: Blocked state, Waiting state, Suspended state Other tasks can continue to execute

ISRs can continue to execute

Asynchronous Driver Requesting Task continues to execute, while Driver I/O

operation is underway Issue: Whats it going to do at that time?

Example: Input device: Task can not yet process the Input itRequested


19/41

Categories of I/O

Passive I/O On-Demand or Polled

Interrupt-Driven I/O Input: Interrupt -> New input

ready to be processed Output: Interrupt -> Finished

with previous output Ready for next output data

DMA Direct MemoryAccess

Transfer of a Complete LargeBuffer of Data

1 Interrupt at the End ofTransfer

Most I/O Hardware isAsynchronous

Device

Hardware

Device

Hardware

Device

Hardware

Device

DevRead()

Device

Interrupt

Service

DMA

Device

Interrupt

Service


20/41

Design Model 1: Synchronous I/O

Driver for Passive Device Passive == No Interrupts associated with device

Example without Mutual Exclusion, without Control

Function

Application Task

dv_init()

Application Task

dv_read()

Application Task

dv_write()

Driver

DevInit()

Driver

DevRead()

Driver

DevWrite()

Device

HardwareRTOS


21/41


Driver for an Interrupt Device Using Semaphore DONE to synchronize

with ISR

DevInit() creates Semaphore DONE Initial value 0 (No IO complete yet)

Application Task

dv_read()RTOS Driver

DevRead()Semaphore

DeviceInterrupt

ServiceDevice

Hard

ware


22/41


Driver for an Interrupt Device

The requesting task is shown on the left as a light blue rectangle withrounded corners. It calls the driver's "read" function, shown as a yellowrectangle (named "DevRead()").

This call can be either through the RTOS, or bypassing the RTOS (shownas a black-dotted rectangle).

The driver's "read" function will request the device hardware to perform a"read" operation, and then it will attempt to get a token from thesemaphore to its right.

Since the semaphore initially has no tokens, the driver "read" function,and hence the task to its left, will become blocked To the right of thesemaphore, is a pink ellipse representing an ISR.

The "lightning" symbol represents the hardware interrupt that triggersexecution of the ISR.

When device hardware completes the requested "read" operation, it willdeliver an interrupt that triggers this ISR, that will put a token into thesemaphore.

This is the semaphore token for which the entire left side of the diagram iswaiting, so the left side of the diagram will then become un-blocked andwill proceed to fetch the newly-read data from the hardware.


23/41




24/41

Design Model 2(Continued) :

Synchronous Driver for an Interrupt

DeviceDevRead()[ and/or DevWrite()] Device_Interrupt Service

ServiceSYNC_OP:

BEGIN

Start IO Device Operation;

semaphore_get ( DONE, Wait);

/* Wait for Signal */

Get Device Status/Data;

END

DEVICE_ISR:BEGIN

Handle Hardware Data/Status;

semaphore_release (DONE);

/* Signal Completion */

END

Application Task


DevRead()Semaphore

Device

Interrupt

ServiceDevice

Hard

ware


25/41

Design Model 2(Continued) : Synchronous


The driver function, does the logic described in the followingpseudocode when called by a task:

DevRead_function:BEGIN

Start IO Device Read Operation;Get Synchronizer Semaphore Token (Waiting OK);

/* Wait for Semaphore Token */

Get Device Status and Data;Give Device Information to Requesting Task;

END

The ISR has very simple logic:DevRead_ISR:

BEGINCalm down the hardware device;Put a Token into Synchronizer Semaphore;

END


26/41

Design Model 3: Basic

Asynchronous Input Driver Concept: Requesting Task processes Previous Input

At the same time as Hardware is working on New Input

Calling Task is not blocked while I/O is taking place

I/O Overlaps with execution of This Task as well as other tasks Mailbox or short Message Queue D_IN

Holds Message (previous input data) from ISR

DevInit()contains mailbox_create(D_IN);or queue_create (D_IN); Supplies initial (bogus) Message of input data

Application Task


DevRead()

DeviceInterrupt

ServiceDevice

Hard

ware

Mail Box


27/41


Asynchronous Input

DevRead() Device_Interrupt Service

ASYNC_OP:

BEGIN

rc= mailbox_pend( D_IN, Q_NOWAIT);

if (rc!= 0) .../* Error */

Start next Input Operation at H/W;

Process D_IN Status/Data;

END

DEVICE_ISR:

BEGIN

Transfer Data/Status from H/W;mailbox_post (D_IN);

/* Send new data */

END

Application Task


DevRead()

DeviceInterrupt

ServiceDevice

Hard

ware

Mail Box

Food for Thought: What if Hardware Delivers New Input Data

Unrequested ?


28/41

Design Model 4: Free-Running

Asynchronous Input Driver Limitation of Model 3:Cant Handle a Free-Running Hardware

Device

Calling Task is not blocked while I/O is taking place

BUT: Some Hardware can Interrupt Repeatedly withoutsoftware request Each time with New Input Data

Solution:Use long Message Queue D_IN to deliver

messages from ISRApplication Task


DevRead()

DeviceInterrupt

ServiceDevice

Hard

ware

QUEUE


29/41


Free Running Input

DevRead() Device_Interrupt Service

ASYNC_OP:

BEGIN

rc= queue_receive ( D_IN, Q_WAIT);if (rc!= 0) .../* Error */

Process D_IN Status/Data;

END

DEVICE_ISR:

BEGIN

Transfer Data/Status from H/W;

queue_send (D_IN); /*New data*/

END

Application Task


DevRead()

DeviceInterrupt

ServiceDevice

Hard

ware

QUEUE

Food for Thought:

What should be the Length of the Message Queue ?

Will the Application Task first receive the oldest or newest Data in Queue?


30/41

Design Model 5 :

Latest Input Only Limitation of Model 4:Always saving unread Incoming Data

Very old data can get Queued up

A Solution: Set up a Protected Shared Data Area Protect from Access Collisions using a Binary Semaphore (Initial

Value 1) Data Area contains Latest Measured Value only. Old data

Overwritten. Destructive Write, Non-Destructive Read

Input Device Hardware can be free-running, giving Interruptswhenever

Application Task


DevRead()Semaphore

DeviceInterrupt

ServiceDevice

Hard

wareSharedData Area


31/41


Latest Input Only

Gain access to shared data

/* semaphore_get(WAIT) */Read data from shared data area

End access /* semaphore_release() */

Application Task


DevRead()

DeviceInterrupt

ServiceDevice

Hard

ware

Shared

Data

Area

Food for Thought:

What if the ISR is refused the Semaphore ?

What if youre Not Using an Operating System, or Dont Have Semaphores?

/* Interrupt -> New data available */

Gain access to shared data

/* semaphore_get (NO_WAIT) */

IF semaphore OKs access

THEN

Write to shared data area

End access /* semaphore_release() */

ELSE ...

ENDIF

Semaphore


32/41

Design Model 6 : Latest Input Only

But No Semaphore Limitation:ISRsCant do Semaphore_Get()

Some RTOSs Dont Allow It

Even if its semaphore_get (NO_WAIT)!

Solution(?):Driver Function (DevRead) TurnsOff InterrupT

when Accessing Shared Data Area

Application Task


DevRead()

Device

Interrupt

ServiceDevice

Hard

ware

Shared

Data

Area


33/41


Latest Input, No Semaphore

Prepare to access to shared data

/* Interrupt_OFF */Read data from shared data area

End access /* Interrupt_ON */

Application Task


DevRead()

DeviceInterrupt

ServiceDevice

Hard

ware

Shared

Data

Area

Food for Thought:

What if Interrupts Arrive when Interrupts are Disabled?

/* Interrupt -> New data available */Write to shared data area


34/41

Design Model 7 :

Latest InputBut No RTOS (Way #2)

Limitation: RTOS services Illegal?, Too Slow?,

or there is No RTOS?

Solution(?): ISR increments an Update Countin Shared Data

Area

Driver Function (DevRead) Compares the Update Count

Before & AfterReading the Shared Data Area

Application Task


DevRead()

Device

Interrupt

ServiceDevice

Hard

ware

Shared

Data

Area

Update

Count


35/41


Latest Input, No RTOS

/* Leave Interrupts On */

DO_UNTIL the 2 Update Countsmatch

Read Update Count before Fetch

Fetch data from shared data area

Read Update Count after Fetch

END_D0

Application Task


DevRead()

DeviceInterrupt

ServiceDevice

Hard

ware

Shared

Data

AreaFood for Thought:

What if the Update Count Rolls Over ?

What if the Update Count is OK by Coincidence?


Increment the Update Count

Write into shared data area/*

Update

Count


36/41

Design Model 8 :

Latest InputBut No RTOS (Way #3)

Limitation: RTOS services Illegal?, Too Slow?,

or there isNo RTOS?

Solution(?): ISR Sets an Update Bitin Shared Data Area

Driver Function (ADevRead) first Zeros the Update Bit,

Then Reads from the Shared Data Area

And Checks for Zero After Reading

Application Task


DevRead()

Device

Interrupt

ServiceDevice

Hard

ware

Shared

Data

Area

Update

Bit


37/41


Latest Input, No RTOS

/* Leave Interrupts On */

DO_UNTIL Update Bitstays at 0

Zero the Update BitFetch data from shared data area

Check that Update Bit still 0

END_D0

Application Task


DevRead()

DeviceInterrupt

ServiceDevice

Hard

ware

Shared

Data

AreaFood for Thought:

What if the Driver is Invoked by 2 or more Tasks ?

Solution:Set Up Mutual Exclusion!


Set the Update Bit to 1

Write into shared data area/*

Update

Bit


38/41

Design Model 9 :

Simple Asynchronous OutputDriver

Use Mailbox or short Message Queue STAT

To deliver hardware status messages from ISR

DevInit() creates STAT and sends first (dummy) message to it

Multiple tasks can call dv_write() Theyll wait in the Task Waiting Queue of queue_receive()

Most RTOSs automatically create a Task Waiting Queue for

each Message Queue

Application

Task

dv_write()

RTOS Driver

DevWrite()

Device

Interrupt

ServiceDevice

Hard

ware

Task

Waiting

Queue

Message

Queue


39/41


Asynch. Output Driver

ASYNC_OP:

BEGIN

queue_receive ( STAT, Wait);

Wait for H/W done/status */

IF( STAT is O.K. )

Start next Output Operation;

ELSE ...

END

Application Task

dv_write()RTOS Driver

DevWrite()

DeviceInterrupt

ServiceDevice

Hard

ware

Food for Thought:

What happens after a Device Error?

Answer: This Driver can "Die"

DEVICE_ISR:

BEGIN

Fetch Status from H/W;/*queue_send (STAT);

/* Send new status */

END

DevWrite() Device Interrupt Service

Task

Waiting

Queue

Message

Queue


40/41

Meaning of an Interrupt is Different

in Output Devices vs. Input Devices Interrupt from Input Device Ive Got an

Input Ready for Software

Interrupt from Output DeviceMeans Hardware Finished Outputting the

Previously Requested Output

And Also Hardware is Now Ready for theNext Output Request


41/41

Further Reading

Architecture of Device I/O Drivers by Prof. David Kalinsky

11 device drivers

Documents