BE Computer Engineering (IOE, TU) Embedded System (IOE, CT 655) Question Paper 2078 Nepal

(a) Definition and Key Characteristics [6]

Definition: An embedded system is a dedicated computer system designed to perform one or a few specific functions, in which hardware and software are tightly integrated, and which is usually embedded as a part (subsystem) of a larger mechanical or electrical system. Examples: washing-machine controller, automotive ABS, digital camera firmware.

Distinguishing characteristics (vs. a general-purpose computer):

• Application-specific / dedicated: runs a fixed task, not arbitrary user programs.
• Real-time operation: must respond to events within strict time deadlines.
• Resource-constrained: limited CPU speed, memory (RAM/Flash), and power.
• Low power consumption: often battery operated; power efficiency is critical.
• Reliability and robustness: expected to run unattended for long periods, often in harsh environments.
• Tightly coupled hardware + software (firmware): software stored in ROM/Flash, no hard disk or general OS in many cases.
• Reactive and deterministic: continuously interacts with the physical world via sensors/actuators.
• Cost and size sensitive: mass-produced, so cost, weight and form factor matter.

(b) Hardware Architecture [6]

Block diagram (described): A central Processor Core sits in the middle. To its left, a Memory Subsystem (RAM + ROM/Flash) connects via the address/data/control bus. Below it, I/O ports and Peripheral Interfaces (timers, ADC/DAC, UART, SPI, I2C) connect to external sensors (inputs) and actuators/displays (outputs). A clock/oscillator and power supply feed the whole system.

      Sensors                                 Actuators/Display
         |                                            ^
         v                                            |
   [ Input Ports ]                            [ Output Ports ]
         |                                            ^
         +----------------+        +------------------+
                          |        |
   [ RAM ] --- bus --- [ Processor Core / CPU ] --- bus --- [ ROM/Flash ]
                          |
              [ Peripherals: Timers, ADC/DAC, UART/SPI/I2C ]
              [ Clock/Oscillator ]   [ Power Supply ]

Roles:

• Processor core (CPU): executes the firmware, performs arithmetic/logic and control; the heart of the system (microcontroller/microprocessor/DSP).
• Memory subsystem:
  • RAM — volatile working memory for variables, stack and runtime data.
  • ROM/Flash — non-volatile storage holding the program code (firmware) and constants; retained on power-off.
• I/O ports: digital input/output pins through which the CPU reads switches/sensors and drives LEDs/relays/actuators.
• Peripheral interfaces: on-chip units such as timers/counters, ADC/DAC, and serial buses (UART, SPI, I2C) that let the CPU communicate with the analog world and other devices.

(a) Embedded System Design Life-Cycle [7]

The design proceeds through the following major phases:

1. Requirement Specification: capture functional requirements (what the system must do) and non-functional requirements (performance, power, cost, size, reliability).
2. System Specification / Modelling: translate requirements into a precise specification (block diagrams, state machines, data flow).
3. Architecture / Hardware-Software Partitioning: decide which functions are done in hardware and which in software; choose processor, memory and periph­erals.
4. Detailed Design: design the hardware (schematic, PCB) and software (modules, RTOS tasks, drivers) in parallel.
5. Implementation: build/fabricate the hardware and write the firmware.
6. Integration & Testing: combine HW and SW, debug, and verify against the specification (unit, integration, system testing).
7. Deployment / Manufacturing: release the product for production.
8. Maintenance & Upgrades: field support, bug fixes, firmware updates.

Life-cycle flow (described): Requirement Spec → System Spec → HW/SW Partitioning → (Hardware Design ∥ Software Design) → Integration → Testing → Deployment → Maintenance, with feedback arrows looping back to earlier phases whenever a verification step fails.

Requirements -> Specification -> Partitioning -> [HW design | SW design]
     ^                                                |
     |                                                v
  Maintenance <- Deployment <- Testing <- Integration

(b) Key Design Trade-offs [5]

• Performance vs. Power: higher clock speeds and more powerful cores improve throughput but consume more energy and generate heat — critical for battery-operated devices.
• Performance vs. Cost: faster processors, more memory and dedicated hardware (ASIC/FPGA) cost more; a slower MCU with optimised software may meet needs cheaply.
• Cost vs. Time-to-Market: custom silicon lowers per-unit cost but takes long to develop; off-the-shelf MCUs and existing software/RTOS speed up release at higher unit cost.
• Hardware vs. Software realization: putting a function in hardware gives speed and determinism but increases cost and reduces flexibility; software is flexible and cheap to change but slower.
• Power vs. Cost: ultra-low-power parts and power-management circuitry add cost.

The designer must balance these competing factors to meet the product's market window, budget, and performance/power targets simultaneously.

(a) RTOS, Hard vs. Soft Real-Time [5]

RTOS: A Real-Time Operating System is an operating system designed to process tasks within strict, predictable (deterministic) time constraints. Its scheduler guarantees that high-priority tasks meet their deadlines; correctness depends not only on the logical result but also on the time at which it is produced.

Hard real-time: Missing a deadline causes total system failure / catastrophe. The deadline is absolute.

• Example: Aircraft flight-control system or automotive airbag deployment.

Soft real-time: Missing a deadline degrades quality of service but is tolerable; the result is still useful if slightly late.

• Example: Video/audio streaming or an online reservation display.

(b) Task Scheduling [7]

Task scheduling is the activity of deciding which ready task the CPU executes next, so that timing requirements are satisfied.

Pre-emptive priority-based scheduling: each task has a priority; the scheduler always runs the highest-priority ready task and pre-empts a lower-priority running task when a higher-priority one becomes ready. Gives fast response to urgent tasks; risk of starving low-priority tasks.

Round-robin scheduling: tasks of equal priority each get a fixed time slice (quantum) in turn, cycling through the ready queue. Fair sharing, but not ideal when some tasks are more urgent than others; response time depends on the number of tasks.

Priority inversion: occurs when a high-priority task is blocked waiting for a resource (e.g. a mutex) held by a low-priority task, while a medium-priority task pre-empts the low-priority task — so the high-priority task is effectively delayed by a medium one (famous Mars Pathfinder bug).

Avoidance techniques:

• Priority Inheritance: the low-priority task holding the resource temporarily inherits the priority of the highest task waiting for it, so it finishes quickly and releases the resource.
• Priority Ceiling Protocol: each shared resource is given a priority ceiling equal to the highest priority of any task that may use it; a task acquiring it runs at that ceiling, preventing inversion and deadlock.

(a) 8051 Internal Architecture [6]

Block diagram (described): An 8-bit CPU (ALU + accumulator A, B register, PSW) is connected to on-chip memory (4 KB ROM and 128 bytes RAM), two 16-bit Timers/Counters (T0, T1), a full-duplex serial port (UART), an interrupt control unit, and four 8-bit I/O ports (P0–P3), all linked by an internal bus, with an oscillator/clock circuit.

      +-------------------- Internal Bus --------------------+
      |          |           |          |          |        |
   [ CPU ]   [ 4KB ROM ] [128B RAM] [Timer0/1] [ UART ] [Interrupts]
   ALU,A,B                                                  |
      |                                                     |
   [ P0 ] [ P1 ] [ P2 ] [ P3 ]   <- four 8-bit I/O ports
   [ Oscillator / Clock ]

• CPU: 8-bit ALU, accumulator (A), B register, PSW (flags), program counter, stack pointer.
• On-chip memory: 4 KB internal ROM (program), 128 bytes internal RAM (registers banks, bit-addressable area, scratchpad). Separate program and data memory (Harvard-style).
• Timers: two 16-bit timer/counters T0 and T1, usable as timers or event counters.
• I/O ports: P0, P1, P2, P3 — four 8-bit bidirectional ports (P0/P2 also serve as the external address/data bus).

(b) 1 kHz Square Wave using Timer Mode 1 [4]

Assumptions: Crystal frequency = 12 MHz, so machine cycle = 12/12 MHz = 1 µs. A 1 kHz square wave has period 1 ms, i.e. 0.5 ms HIGH and 0.5 ms LOW. For each half: 500 µs / 1 µs = 500 counts. Reload value = 65536 − 500 = 65036 = 0xFE0C → TH = 0xFE, TL = 0x0C.

#include <reg51.h>
sbit out = P1^0;            // output pin

void timer0_delay(void) {   // ~500 us delay, Timer0 Mode 1
    TMOD = 0x01;            // Timer0, mode 1 (16-bit)
    TH0  = 0xFE;            // load 65036 = 0xFE0C
    TL0  = 0x0C;
    TR0  = 1;               // start timer
    while (TF0 == 0);       // wait for overflow
    TR0  = 0;               // stop timer
    TF0  = 0;               // clear overflow flag
}

void main(void) {
    while (1) {
        out = ~out;         // toggle pin every 500 us -> 1 kHz
        timer0_delay();
    }
}

Toggling the pin every 500 µs produces a full period of 1 ms ≈ 1 kHz.

I2C vs. SPI Comparison

Suitable applications:

• I2C: reading low-speed on-board sensors (e.g. RTC, EEPROM, temperature/accelerometer) where many devices share two wires.
• SPI: high-speed peripherals such as SD cards, TFT displays, and ADCs where throughput matters.

(a) UART Asynchronous Frame Format [4]

UART sends one character as a serial frame; the line idles HIGH.

 IDLE | START | D0 D1 D2 D3 D4 D5 D6 D7 | PARITY | STOP | IDLE
  1   |   0   |  <-- data bits (LSB first) --> |  P     |  1   |

• Start bit: one bit, always logic 0, marks the beginning of a frame and synchronises the receiver.
• Data bits: 5–9 bits (commonly 8), transmitted LSB first, carrying the actual character.
• Parity bit (optional): one bit for error detection (even/odd parity); may be omitted.
• Stop bit(s): 1, 1.5 or 2 bits, always logic 1, mark the end of the frame and allow the receiver to resynchronise.

No separate clock line is used — both ends must agree on the same baud rate.

(b) Time to Transmit One Byte [2]

Configuration: 8 data bits, no parity, 1 stop bit → total bits per frame = 1 (start) + 8 (data) + 0 (parity) + 1 (stop) = 10 bits.

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

(a) Interrupt; Maskable vs. Non-Maskable [3]

Interrupt: a hardware or software signal that temporarily suspends the normal execution of the CPU so that it can service an urgent event, after which it resumes the interrupted program. Interrupts allow asynchronous, event-driven response without continuous polling.

• Maskable interrupt: can be enabled or disabled (masked) by software through the interrupt-enable flags/registers. Used for ordinary peripheral events (timer, UART, external pins).
• Non-maskable interrupt (NMI): cannot be disabled by software; always serviced. Reserved for critical events such as power failure, watchdog reset, or hardware errors.

(b) Interrupt Handling Sequence [3]

When an interrupt occurs the microcontroller performs:

1. Finish current instruction and recognise the interrupt request.
2. Save context: push the Program Counter (return address) and processor status/registers onto the stack so the interrupted program can be resumed exactly.
3. Disable further interrupts (or set appropriate priority) and load the ISR address from the interrupt vector table into the PC.
4. Execute the ISR (Interrupt Service Routine) — the dedicated function that handles the event (e.g. read data, clear flags).
5. Restore context: pop the saved registers and PC from the stack and re-enable interrupts (via the RETI/return-from-interrupt instruction).
6. Resume the interrupted main program from where it left off.

Importance of saving/restoring context: the ISR uses the same CPU registers as the main program; saving them on entry and restoring on exit ensures the main program continues with its data intact and unaffected by the interrupt.

Interfacing an Analog Temperature Sensor (LM35) to a Microcontroller

Sensor characteristics: The LM35 is a linear analog temperature sensor whose output voltage is directly proportional to temperature: 10 mV per °C (e.g. 25 °C → 250 mV), with a 0 V output at 0 °C.

Interfacing steps:

1. Analog output: The LM35 produces a small analog voltage on its output pin. This is fed to an analog input channel of the microcontroller.
2. Signal conditioning (need): Because the output change is only 10 mV/°C — a small range relative to the ADC's full-scale (often 5 V) — an amplifier (op-amp gain stage) may be used to scale the signal to better fill the ADC range and improve resolution. A simple RC low-pass filter removes electrical noise, and the signal is kept within the ADC's input range.
3. ADC role: The Analog-to-Digital Converter samples the (conditioned) analog voltage and converts it into an n-bit digital number proportional to the input voltage. With a reference voltage $V_{ref}$ and resolution $n$ bits, the step size is $V_{ref}/2^n$.
4. Conversion back to temperature: The digital count is converted to voltage and then to °C:

$$V_{in} = \frac{\text{ADC\_value}}{2^n - 1}\times V_{ref}$$ $$T(^\circ C) = \frac{V_{in}\,[\text{mV}]}{10\ \text{mV/}^\circ C}$$

Example: 10-bit ADC ($2^{10}=1024$), $V_{ref}=5$ V, ADC reading = 51 → $V_{in}=51/1023\times5 \approx 0.249$ V = 249 mV → $T = 249/10 \approx 24.9\,^\circ C$.

(a) Why a Driver Circuit is Required [3]

A microcontroller I/O pin can only source/sink a few milliamperes at logic-level voltage (e.g. 5 V, ~20 mA max). Motors, relays and similar actuators need much higher current (hundreds of mA to amperes) and sometimes higher voltage. Therefore a driver circuit is placed between the pin and the actuator to:

• Amplify current/voltage so the actuator gets enough power (a transistor or ULN2003 Darlington array switches the high-current load while the MCU pin only controls the base).
• Provide electrical isolation/protection for the sensitive MCU, including a flyback (free-wheeling) diode across inductive loads (relay/motor coil) to absorb the back-EMF when switched off, protecting the driver and MCU.
• An H-bridge additionally allows the DC motor to run in both directions by reversing the polarity across it.

(b) PWM Speed Control of a DC Motor [3]

Pulse Width Modulation (PWM) controls average power delivered to the motor by switching the supply ON and OFF rapidly at a fixed frequency and varying the duty cycle (the fraction of each period the signal is HIGH).

$$V_{avg} = D \times V_{supply}, \qquad D = \frac{t_{on}}{t_{on}+t_{off}}$$

• A higher duty cycle → higher average voltage → motor runs faster.
• A lower duty cycle → lower average voltage → motor runs slower.

Because the switching frequency is much higher than the motor's mechanical response time, the motor's inductance/inertia smooths the pulses, so the motor sees an effective average voltage. PWM is efficient because the switching transistor is either fully ON or fully OFF, dissipating little power (unlike a series resistor).

Bit Manipulation in Embedded C

In embedded C, hardware registers are accessed bit-by-bit using bitwise operators so that only the target bit is changed and the others are preserved. Assume an 8-bit register REG and we want to operate on bit position n.

Set a bit (make it 1) — OR with a mask:

REG |=  (1 << n);   // set bit n, others unchanged

Clear a bit (make it 0) — AND with the inverted mask:

REG &= ~(1 << n);   // clear bit n, others unchanged

Toggle a bit (flip it) — XOR with a mask:

REG ^=  (1 << n);   // toggle bit n, others unchanged

Test/read a bit — AND with a mask and check the result:

if (REG & (1 << n)) {
    // bit n is 1 (set)
} else {
    // bit n is 0 (clear)
}

Why it works: (1 << n) builds a mask with a single 1 at position n. OR sets, AND-with-complement clears, XOR toggles, and AND tests — each affecting only bit n while leaving all other bits intact, which is essential when configuring hardware registers (e.g. setting one GPIO pin without disturbing others).

Producer-Consumer Problem in a Multitasking Embedded System

Problem: One or more producer tasks generate data and place it into a shared bounded buffer, while one or more consumer tasks remove and process it. Two hazards arise:

• Race condition: if producer and consumer access the shared buffer simultaneously, the data may be corrupted.
• Synchronisation: the producer must wait when the buffer is full; the consumer must wait when the buffer is empty.

In an embedded RTOS this is common, e.g. an ISR/sensor task producing samples that a processing task consumes.

Solving it with RTOS primitives:

• Mutex (mutual exclusion): protects the critical section — the code that updates the shared buffer/indices. A task locks the mutex before access and unlocks after, guaranteeing only one task modifies the buffer at a time. Mutexes typically support priority inheritance to avoid priority inversion.
• Counting semaphores: used for synchronisation/flow control. Use two:
  • empty (initialised to buffer size) — producer takes it before writing (blocks when buffer full).
  • full (initialised to 0) — producer gives it after writing; consumer takes it before reading (blocks when buffer empty).
• Message queue: the cleanest RTOS solution — a built-in thread-safe FIFO. The producer calls queue_send() (blocks/returns if full) and the consumer calls queue_receive() (blocks until an item is available). The queue internally handles both mutual exclusion and the full/empty blocking, so the application code stays simple and safe.

Pseudocode (semaphore + mutex):

Producer:                         Consumer:
  wait(empty);                      wait(full);
  lock(mutex);                      lock(mutex);
  buffer.put(item);                 item = buffer.get();
  unlock(mutex);                    unlock(mutex);
  signal(full);                     signal(empty);

This ensures safe, deadlock-free data exchange between concurrent tasks.

(a) Microprocessor vs. Microcontroller [2]

(b) Harvard vs. Von Neumann Architecture [2]

(c) RISC vs. CISC [2]

Polling vs. Interrupt-Driven I/O

Polling: the CPU repeatedly checks (in a loop) the status flag of a device to see whether it needs servicing.

Interrupt-driven: the device signals the CPU (raises an interrupt) only when it needs attention; the CPU runs other code meanwhile and jumps to the ISR when interrupted.

Summary: Polling is simple and acceptable for slow or frequently-active devices, but wastes CPU time and can be slow to respond. Interrupt-driven I/O gives much better CPU utilisation, lower power, and faster, more deterministic response, at the cost of extra programming complexity, so it is preferred for time-critical or infrequent events.