BE Computer Engineering (Pokhara University) Embedded System (PU, ELX 320) Question Paper 2078 Nepal

(a) Embedded system and its essential characteristics (6)

An embedded system is a dedicated combination of hardware and software, built around a microprocessor or microcontroller, that is designed to perform a specific, fixed function within a larger mechanical or electronic system, usually with real-time constraints and limited resources.

Essential characteristics:

• Application-specific (dedicated): Runs one fixed program for a single task; it is not a general-purpose computer.
• Real-time operation: Many embedded systems must respond to events within strict time deadlines (hard/soft real-time).
• Resource constrained: Limited processing power, RAM, ROM and energy; code/data footprint must be small.
• Low power consumption: Often battery operated, so energy efficiency is critical.
• Reliability and stability: Must run continuously and unattended for long periods without crashing.
• Tight hardware/software coupling: Software is tailored to the exact hardware; firmware is usually stored in non-volatile memory.
• Reactive: Continuously interacts with the physical environment through sensors and actuators.

Four real-world examples:

1. Washing machine controller – sequences wash/rinse/spin cycles.
2. Automotive ECU / ABS – controls fuel injection or anti-lock braking.
3. Digital camera – handles image capture, processing and storage.
4. Smart energy meter / pacemaker – metering or life-critical patient monitoring.

(b) Architecture of a microcontroller-based embedded system (8)

Block diagram (described in words): A central CPU sits in the middle and connects through an internal system bus (address bus, data bus, control bus) to Program (code) memory, Data memory, I/O ports, and on-chip peripherals (timers, ADC, serial port). A system clock/oscillator drives the CPU and peripherals.

          +-----------------------------------------------+
          |                Microcontroller                |
          |                                               |
  Clock-->|  +-----+    System Bus (Addr/Data/Control)    |
          |  | CPU |====+=========+=========+==========+  |
          |  +-----+    |         |         |          |  |
          |        +---------+ +--------+ +--------+ +------+|
          |        | Program | | Data   | |  I/O   | |Timer/|| <-> External
          |        | Memory  | | Memory | | Ports  | | ADC  ||     world
          |        |(ROM/Flash)|(RAM)  | |        | |UART  ||
          |        +---------+ +--------+ +--------+ +------+|
          +-----------------------------------------------+

Role of each block:

• CPU (Central Processing Unit): Fetches, decodes and executes instructions; performs arithmetic/logic via the ALU, manages registers and the program counter, and controls all other units.
• Program (code) memory – ROM/Flash: Non-volatile memory that permanently holds the firmware/program so it is retained when power is off.
• Data memory – RAM: Volatile read/write memory holding variables, stack and temporary data during program execution.
• I/O ports: Provide the digital interface to the outside world; pins are configured as inputs (read switches/sensors) or outputs (drive LEDs/relays/actuators).
• System clock (oscillator): Generates the timing reference that synchronizes instruction execution and peripheral timing; the instruction execution rate is derived from it (e.g., machine cycle = oscillator period × N).

The on-chip peripherals (timers/counters, ADC, UART/SPI/I2C) make the device self-contained, which is the key advantage of a microcontroller over a microprocessor.

(a) Harvard vs Von Neumann architecture (6)

Which architecture does the 8051 follow? The 8051 follows the Harvard architecture. It has physically separate program memory (up to 64 KB code/ROM) and data memory (up to 64 KB external RAM plus 128/256 bytes internal RAM), accessed by different control signals — PSEN (Program Store Enable) for code fetch and RD/WR for data. Because code and data have separate address spaces and buses, the 8051 can fetch the next instruction while accessing data, giving faster, deterministic execution suited to embedded control.

(b) Embedded C program: 1 kHz square wave on P1.0 using Timer 0, Mode 1 (8)

Reload value calculation:

• Crystal frequency $f_{osc} = 11.0592\text{ MHz}$.
• Machine cycle $= \dfrac{12}{f_{osc}} = \dfrac{12}{11.0592\times10^{6}} = 1.085\ \mu s$.
• For a 1 kHz square wave, period $T = 1\text{ ms}$, so each half-period (high/low) $= 500\ \mu s$.
• Timer ticks needed $= \dfrac{500\ \mu s}{1.085\ \mu s} \approx 461$ counts.
• Reload value $= 65536 - 461 = 65075 = \mathbf{0xFE33}$ (approx). So $TH0 = 0xFE,\ TL0 = 0x33$.

#include <reg51.h>

sbit wave = P1^0;          // output pin P1.0

void delay500us(void)
{
    TMOD &= 0xF0;          // clear Timer0 bits
    TMOD |= 0x01;          // Timer0, Mode 1 (16-bit)
    TH0 = 0xFE;            // reload high byte
    TL0 = 0x33;            // reload low byte (65536 - 461)
    TR0 = 1;               // start Timer0
    while (TF0 == 0);      // wait for overflow (~500 us)
    TR0 = 0;               // stop Timer0
    TF0 = 0;               // clear overflow flag
}

void main(void)
{
    while (1)
    {
        wave = ~wave;      // toggle P1.0 every 500 us -> 1 ms period -> 1 kHz
        delay500us();
    }
}

Toggling the pin every 500 µs produces a complete 1 ms period, i.e. a 1 kHz square wave on P1.0.

(a) Hard vs Soft real-time OS (4)

(b) Preemptive priority-based scheduler (6)

In a preemptive priority-based scheduler, every task is assigned a priority. The scheduler always runs the highest-priority task that is ready to run.

• When a higher-priority task becomes ready (e.g., its event occurs or an interrupt unblocks it), the currently running lower-priority task is preempted — its context (registers, PC, stack pointer) is saved.
• The scheduler performs a context switch, loading the context of the higher-priority task and giving it the CPU immediately.
• When the higher-priority task blocks or completes, the scheduler resumes the highest-priority ready task remaining.
• This guarantees that critical/high-priority tasks meet their deadlines with low response latency, which is essential for real-time behaviour. Equal-priority tasks may be time-sliced (round-robin). A risk is starvation of low-priority tasks and priority inversion, handled by mechanisms like priority inheritance.

(c) CPU utilization and RMS schedulability (6)

Given: T1 (P=25, C=5), T2 (P=50, C=15), T3 (P=100, C=30) ms.

Total utilization:

$$U = \frac{C_1}{P_1}+\frac{C_2}{P_2}+\frac{C_3}{P_3} = \frac{5}{25}+\frac{15}{50}+\frac{30}{100} = 0.20 + 0.30 + 0.30 = 0.80$$

So $U = 0.80 = 80\%$.

Liu & Layland bound for n = 3 tasks:

$$U_{bound} = n\left(2^{1/n}-1\right) = 3\left(2^{1/3}-1\right) = 3(1.2599-1) = 3(0.2599) = 0.7797 \approx 0.780$$

Decision: Since $U = 0.80 > U_{bound} = 0.780$, the sufficient RM utilization test fails — schedulability is not guaranteed by the Liu–Layland bound.

The bound is only sufficient (not necessary), so the set might still be schedulable; this can be confirmed with the exact Response Time Analysis:

• T1: $R_1 = 5 \le 25$ OK.
• T2: $R_2 = 15 + \lceil 15/25\rceil\cdot5 = 15+5 = 20 \le 50$ OK.
• T3: iterate $R_3 = 30 + \lceil R/25\rceil5 + \lceil R/50\rceil15$; converges to $R_3 = 30+10+15 = 55 \le 100$ (recheck: $\lceil55/25\rceil=3\Rightarrow15,\ \lceil55/50\rceil=2\Rightarrow30,\ R=30+15+30=75;\ \lceil75/25\rceil=3\Rightarrow15,\lceil75/50\rceil=2\Rightarrow30,R=75$) → $R_3 = 75 \le 100$ OK.

Conclusion: $U = 80\%$ exceeds the RM bound (78%), so the utilization test does not guarantee schedulability; however, exact response-time analysis shows all deadlines are met, so the task set is in fact schedulable under RMS.

(a) Embedded system design flow (7)

Typical flow from requirement specification to deployment:

1. Requirement specification: Capture functional requirements (what the system does) and non-functional requirements (timing, power, cost, size, reliability).
2. System specification / architecture: Define overall behaviour and partition the system into subsystems.
3. Hardware/software partitioning (co-design): Decide which functions are implemented in hardware (for speed/efficiency) and which in software (for flexibility). HW and SW are developed concurrently so trade-offs in performance, cost, and power can be optimized together rather than sequentially.
4. Hardware design: Select processor/microcontroller, design schematics, memory, and peripheral interfaces.
5. Software/firmware design: Write drivers, application code, and (optionally) integrate an RTOS.
6. Integration: Combine HW and SW.
7. Testing, verification and validation.
8. Deployment and maintenance.

Role of simulation and emulation:

• Simulation models the hardware/software behaviour on a host computer before physical hardware exists, allowing early functional testing and design exploration at low cost.
• Emulation (in-circuit emulator / hardware emulation) executes the firmware on hardware that mimics the real target in real time, enabling accurate debugging, breakpoints, and timing analysis on near-final hardware. Together they reduce design risk and shorten time-to-market by catching errors before fabrication.

(b) Temperature-monitoring system with LM35 (5)

Interfacing block diagram (described):

  LM35  --analog Vout-->  ADC  --digital-->  Microcontroller  --GPIO-->  Relay/Driver --> Cooling Fan
 (sensor)            (e.g. on-chip/0804)          (CPU)                        (actuator)

The LM35 outputs 10 mV/°C (e.g., 40 °C → 400 mV). Its analog output feeds an ADC (on-chip or ADC0804). The microcontroller reads the digital value, converts it to temperature, compares with the 40 °C threshold, and drives a GPIO pin connected to a transistor/relay (or driver) that switches the cooling fan ON or OFF.

Control algorithm:

LOOP forever:
    raw   = read_ADC()                  // read LM35 via ADC
    temp  = raw * (Vref/resolution) / 0.01   // convert to deg C (10 mV/deg C)
    if (temp > 40):
        FAN_PIN = 1                     // turn cooling fan ON
    else:
        FAN_PIN = 0                     // turn fan OFF
    delay(500 ms)                       // sampling interval

Adding a small hysteresis (e.g., turn ON at 40 °C, OFF at 38 °C) prevents rapid relay chattering near the threshold.

I2C vs SPI comparison

One application of each:

• I2C: Reading an on-board sensor such as an RTC (DS1307), EEPROM, or temperature sensor where few wires and addressing are preferred.
• SPI: High-speed transfer to an SD card / TFT display / ADC where throughput matters.

(a) Polling vs interrupt-driven I/O (3)

(b) Sequence of events on an interrupt + ISR and vector table (3)

Sequence when an interrupt is triggered:

1. The peripheral asserts an interrupt request; if that interrupt is enabled and of sufficient priority, the CPU finishes the current instruction.
2. The CPU saves the current state — at least the Program Counter (and on many cores, status register) is pushed onto the stack.
3. The CPU fetches the interrupt vector (the address of the ISR) from the interrupt vector table corresponding to the interrupt source.
4. Control jumps to the ISR, which executes the service code (e.g., read a byte, clear the flag).
5. On RETI/return, the saved context (PC/status) is restored from the stack and the main program resumes where it left off.

ISR: A special function that runs in response to a specific interrupt; it should be short, perform the urgent task, and clear the interrupt flag.

Interrupt vector table: A fixed table in memory holding the starting address (vector) of each interrupt's ISR, allowing the CPU to quickly branch to the correct handler for each interrupt source.

UART frame format and timing

Asynchronous UART frame format: UART has no shared clock; both ends agree on a baud rate. Each character is framed as:

  Idle(1) | START(0) | D0 D1 D2 D3 D4 D5 D6 D7 | [PARITY] | STOP(1) | Idle

• Start bit (1 bit, logic 0): Marks the beginning and synchronizes the receiver.
• Data bits (5–9, here 8): The payload, sent LSB first.
• Parity bit (optional): Error checking — absent here (no parity).
• Stop bit(s) (1 or 2, here 1, logic 1): Marks the end of the frame and returns the line to idle.

Total bits per character = 1 start + 8 data + 0 parity + 1 stop = 10 bits.

Time to transmit one character:

$$t_{bit} = \frac{1}{9600} = 104.17\ \mu s$$ $$t_{char} = 10 \times t_{bit} = \frac{10}{9600} = 1.0417\ ms \approx 1.04\ ms$$

Effective data throughput (useful bytes/s): Only 8 of the 10 bits carry data, so

$$\text{Throughput} = \frac{1}{t_{char}} = \frac{9600}{10} = 960\ \text{characters (bytes) per second.}$$

So one character takes about 1.04 ms and the effective throughput is 960 bytes/s (out of the 9600 bps raw line rate, the rest being framing overhead).

DC motor interfacing, PWM speed control, and the driver

Interfacing a DC motor: A microcontroller GPIO pin cannot directly power a motor, so a driver/power stage (transistor or motor-driver IC such as L293D) is placed between them. The microcontroller pin feeds the driver's input; the driver switches the motor current from a separate motor supply. Direction is set by the driver's input combination (H-bridge), and an enable/PWM pin controls power.

Speed control using PWM: PWM applies a square wave whose duty cycle is varied while the frequency stays fixed. Because the motor responds to the average voltage:

$$V_{avg} = D \times V_{supply}, \quad D = \frac{t_{ON}}{t_{ON}+t_{OFF}}$$

• Higher duty cycle → higher average voltage → faster speed.
• Lower duty cycle → slower speed.

The MCU generates PWM on a timer output (or the L293D enable pin) and changing the duty cycle smoothly controls speed with very little power loss (the switch is fully on or fully off).

Why an L293D driver is required:

1. Current/voltage limits: An MCU pin sources only a few mA at logic level; a motor needs hundreds of mA to amperes at a higher voltage. The L293D provides this current and connects to a separate motor supply.
2. Back-EMF / inductive protection: A motor is inductive and generates back-EMF spikes; the L293D (with clamp/flyback diodes) protects the MCU from these transients.
3. Direction control: The L293D contains an H-bridge that lets the motor run forward or reverse and provides electrical isolation of the logic from the power circuit.

Microprocessor vs Microcontroller

Major functional blocks on a typical microcontroller chip:

• CPU (ALU + control unit + registers)
• Program memory (Flash/ROM)
• Data memory (RAM)
• I/O ports (digital input/output)
• Timers/Counters
• Serial communication (UART/SPI/I2C)
• ADC/DAC, interrupt controller, system clock/oscillator, watchdog timer

Two advantages of using a microcontroller in embedded applications:

1. Compact and low cost – integrated CPU, memory and peripherals on one chip reduce board size, component count and cost.
2. Low power and reliable – fewer external connections and on-chip peripherals give lower power consumption and higher reliability, ideal for dedicated control tasks.

(a) Semaphore; counting vs binary (mutex) (3)

A semaphore is an OS synchronization primitive — an integer counter with atomic wait (P / take) and signal (V / give) operations — used to control access to shared resources and to synchronize tasks in a multitasking/RTOS environment.

• Binary semaphore (mutex): Takes only values 0 or 1; used for mutual exclusion to protect a single shared resource/critical section. A mutex additionally has the notion of ownership (only the task that took it should release it) and usually supports priority inheritance.
• Counting semaphore: Can take values 0…N; used to manage N identical resources (e.g., a pool of buffers) or to count events. Each take decrements the count; when it reaches 0, further tasks block until a give increments it.

(b) Priority inversion and priority inheritance (3)

Priority inversion: A situation where a high-priority task is blocked waiting for a resource (mutex) held by a low-priority task, while a medium-priority task that does not need the resource preempts the low-priority task. The medium task keeps the low task from finishing and releasing the mutex, so the high-priority task is effectively delayed by a lower-priority one — an inverted, unbounded delay (famously seen in the Mars Pathfinder).

Priority inheritance (solution): When a high-priority task blocks on a mutex held by a low-priority task, the low-priority task temporarily inherits the high task's priority. This lets it run (and not be preempted by medium-priority tasks), finish the critical section quickly, and release the mutex; it then returns to its original priority. This bounds the blocking time and unblocks the high-priority task promptly.

Short notes (any TWO)

(a) Watchdog timer

A watchdog timer (WDT) is a hardware down/up counter that resets the system if the software fails to service it ('kick'/refresh) within a preset interval. In normal operation the program periodically resets the WDT; if the code hangs (infinite loop, deadlock, glitch), the WDT times out and triggers a system reset, restoring the device to a known good state. It is essential for unattended, reliable embedded systems.

(b) Cross-compiler and toolchain

A cross-compiler runs on one platform (the host, e.g., a PC) but generates executable code for a different target architecture (e.g., ARM/AVR). It is needed because the small target microcontroller cannot compile its own code. The toolchain is the full set of build tools — preprocessor, cross-compiler, assembler, linker, and locator plus a debugger and programmer/flasher — that together turn source code into a hex/binary image and load it into the target's memory.

(c) Memory-mapped vs port-mapped I/O

• Memory-mapped I/O: Peripheral registers share the same address space as memory; the CPU uses ordinary load/store (memory) instructions to access them. Simpler instruction set, but consumes part of the memory address range.
• Port-mapped (isolated) I/O: Peripherals occupy a separate I/O address space accessed by dedicated I/O instructions (e.g., IN/OUT) and a control line that distinguishes I/O from memory. Saves memory address space but needs special instructions.

(d) Power management in battery-operated devices

Techniques to extend battery life include low-power/sleep modes (idle, power-down, deep-sleep) that shut down the CPU/clocks when idle and wake on interrupt; dynamic clock and voltage scaling (DVFS) to run only as fast as needed; selectively powering down unused peripherals; duty cycling (waking briefly, sleeping long); and using efficient regulators and event-driven (interrupt) rather than polling designs. The goal is to minimize average current draw while meeting performance needs.

Short notes on any TWO of the following:

(a) Watchdog Timer

A watchdog timer (WDT) is a hardware countdown timer used to detect and recover from software malfunctions (hangs, infinite loops, deadlocks). During normal operation the firmware must periodically reset ("kick" or "feed") the watchdog before it expires. If the program stops behaving correctly and fails to kick the timer in time, the WDT times out and forces a system reset, returning the device to a known good state. It is essential in unattended/embedded systems (e.g. routers, medical and automotive controllers) where a human cannot manually reboot a frozen device.

(b) Cross-Compiler and Toolchain

A cross-compiler runs on one architecture (the host, e.g. an x86 PC) but generates executable code for a different architecture (the target, e.g. ARM or AVR). This is necessary because most embedded targets lack the resources to host a full native compiler.

A toolchain is the complete set of tools that turns source code into a runnable image for the target, typically:

• Preprocessor + cross-compiler (e.g. arm-none-eabi-gcc) – source → assembly/object code
• Assembler – assembly → object files
• Linker – combines object files and libraries, resolves addresses per the linker script
• C library (e.g. newlib) and binutils (objcopy, objdump, size)
• Debugger (e.g. GDB with OpenOCD/JTAG)

The linker produces an ELF, which objcopy converts to a flashable .bin/.hex for the target.

(c) Memory-Mapped vs Port-Mapped I/O

Memory-mapped I/O is the dominant scheme in embedded MCUs because peripherals are accessed with the same instructions as RAM, simplifying both the CPU and the compiler.

(d) Power Management in Battery-Operated Embedded Devices

Techniques used to extend battery life:

• Low-power/sleep modes: the MCU enters idle, sleep, stop, or standby states that gate clocks and power domains, waking on interrupt (event-driven design).
• Dynamic Voltage and Frequency Scaling (DVFS): lower the clock frequency and core voltage when full performance is not needed (dynamic power ∝ C·V²·f).
• Peripheral and clock gating: switch off unused peripherals, oscillators and memory banks.
• Duty cycling: keep the radio/sensors off most of the time, waking briefly to sample and transmit.
• Efficient power supplies: use high-efficiency DC-DC (switching) regulators and a power-management IC (PMIC).

The overarching strategy is to keep the system in its deepest sleep state for as long as possible and do work in short, efficient bursts.