Device Drivers

Computer Organization & Embedded System — Real-Time Operating and Control System, NEC licence examination syllabus (Nepal Engineering Council).

Device Drivers

The translator between generic OS calls and specific hardware quirks.

A device driver is software that lets the OS talk to a specific piece of hardware without the rest of the OS needing to know that hardware's details — this is why installing a new printer doesn't require rewriting Windows itself, just adding a small driver. Drivers usually contain an Interrupt Service Routine (ISR) — the code that runs the instant the device raises an interrupt (e.g., "data ready").

Polling drivers repeatedly check device status (simple, wastes CPU). Interrupt-driven drivers let the CPU do other work until the device signals it — the standard approach for anything beyond trivial devices.

💡 One-liner: "Why must an ISR be kept as short as possible?" → It runs with interrupts often disabled/masked, so a long ISR delays handling of other urgent events, which is dangerous in a real-time system.

What to do with work that will not fit in the ISR

"Keep the ISR short" raises an obvious question the chapter leaves open: where does the rest of the work go? The answer is the standard structure of every serious driver.

⚡ Top half and bottom half

Top half (the ISR)Runs immediately with interrupts masked. Does the minimum that cannot wait — acknowledge the device, copy the data out of the hardware buffer before it is overwritten, and schedule the rest.

Bottom halfRuns later as an ordinary schedulable task with interrupts enabled. Does the processing: parsing, checksums, waking whoever was waiting.

The split exists because time spent in the ISR is time when other interrupts cannot be serviced. Moving everything that can tolerate a delay out of the top half is what keeps the system responsive to the events that cannot.

💡 So the full exam answer to "why must an ISR be short?" is not merely that it blocks other interrupts — it is that the work is deferred to a bottom half, giving a short critical section and full processing without sacrificing either.

Interrupt latency, and why a real-time system is specified on it

Interrupt latency is the delay between a device raising an interrupt and its handler beginning to run. In a real-time system this is not a performance metric but a correctness one: a deadline missed because latency was too high is a failure, not a slowdown.

⏱️ What the delay is made of

Interrupts disabledAny critical section currently masking interrupts must finish first. This is usually the dominant and least predictable term.

Current instructionThe processor completes the instruction in progress before it will accept the interrupt.

Context saveRegisters must be preserved before the handler can run.

Higher-priority ISRsAnything more urgent already running goes first.

This is why a real-time system is characterised by its worst-case latency rather than its average. An average of one microsecond with an occasional millisecond spike is useless if the deadline is ten microseconds — the spike is the only number that matters.

💡 It also explains the standing rule that critical sections must be as short as possible. Every region that disables interrupts adds directly to the worst case, and one careless long section anywhere in the kernel sets the bound for the entire system.

Polling versus interrupts, with numbers

"Polling wastes CPU" is true and vague. Put figures on it:

Device producing 10 events per second. Polling at 1 kHz, 2 µs per check: CPU used = 1000 × 2 µs = 2 ms per second = 0.2% Useful checks = 10 out of 1000 → 99% find nothing Interrupt-driven, 5 µs per ISR: CPU used = 10 × 5 µs = 50 µs per second = 0.005% Forty times less CPU, and the response is immediate rather than up to 1 ms late.

💡 Note the second advantage, which is the one that matters in real-time work: polling at 1 kHz means an event can wait up to a full millisecond before anyone notices. Interrupt-driven handling responds as soon as the current critical section allows.

When polling is the right answer after all

The trade-off reverses at high event rates, and a good answer says so.

Every interrupt costs a context switch. If events arrive faster than they can be serviced individually, the system can spend all its time switching and none doing work — a livelock, where the machine is fully busy and makes no progress. Polling has a fixed cost regardless of event rate, so under heavy load it wins.

This is exactly why high-speed network drivers switch from interrupts to polling when traffic is heavy, and back again when it subsides. It is also why polling remains correct for very simple or very fast devices, where an interrupt would cost more than the operation itself.

Syllabus points

Role and structure
Interrupt Service Routine (ISR); polling vs interrupt driver

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.