An embedded system is a computer built into a device to do a specific job: the controller in a washing machine, the ECU in a car, a smart meter, a router, a pacemaker or an IoT sensor. Embedded devices vastly outnumber servers and laptops, and the cloud services you run increasingly talk to them. This article revisits the five units of the JNTUK course.
Unit 1: Introduction to embedded systems
Definition and characteristics
An embedded system is a combination of hardware and software designed for a dedicated function, often with limits on cost, power, size and memory.
| Characteristic | Meaning |
|---|---|
| Single-function | Does one task repeatedly |
| Real-time | Must respond within a deadline |
| Resource-constrained | Small memory, low power, low cost |
| Reliable and long-lived | Often cannot be restarted or serviced easily |
| Reactive | Responds continuously to sensors and events |
Classification
| By | Types |
|---|---|
| Performance | Real-time, stand-alone, networked, mobile |
| Complexity | Small (8-bit), medium (16 or 32-bit), sophisticated (SoC with an OS) |
| Timing | Hard real-time (missing a deadline is a failure: airbag, pacemaker), soft real-time (a late result is degraded: video) |
Hardware building blocks
| Block | Role |
|---|---|
| Microcontroller / SoC | CPU, memory and peripherals on one chip |
| Memory | Flash or ROM (program), RAM (data), EEPROM (settings) |
| Sensors and actuators | Input from the world (temperature, motion) and output (motors, relays) |
| ADC and DAC | Convert between analog and digital |
| Timers and watchdog | Measure time; a watchdog timer resets the system if the software hangs |
| Communication interfaces | UART, SPI, I²C, CAN, USB, Ethernet, Wi-Fi, Bluetooth |
| Power supply and management | Batteries, regulators, sleep modes |
Design process
Requirements, hardware-software partitioning, design, co-simulation, implementation, testing, integration and maintenance. The trade-off is always between cost, performance, power and time to market.
Today: a smart thermostat, a Wi-Fi router, a drone controller, a PLC on a factory floor and a Raspberry Pi in a monitoring rack are embedded systems. The “watchdog” idea is the same as a Kubernetes liveness probe: restart if it stops responding.
Unit 2: ARM architecture and peripherals
Why ARM
ARM processors dominate embedded and mobile devices because they are low power, licensable and offered in many sizes. They follow RISC principles: simple, fixed-length instructions, a load-store architecture (only load and store touch memory), many registers and efficient pipelines.
| Family | Use |
|---|---|
| Cortex-M (M0, M3, M4, M7) | Microcontrollers: sensors, appliances, motor control |
| Cortex-R | Real-time, high reliability: car braking, storage controllers |
| Cortex-A | Application processors: phones, tablets, Raspberry Pi, servers (AWS Graviton) |
Cortex-M features
- Registers: R0 to R12 (general), SP (R13), LR (R14, link register for returns) and PC (R15), plus the program status register.
- Thumb / Thumb-2 instruction sets give compact code.
- Pipeline: three stages (fetch, decode, execute) in the classic cores.
- Nested Vectored Interrupt Controller (NVIC): priorities and fast interrupt entry.
- Memory map and bit-banding, with the memory protection unit (MPU).
- Low-power modes: sleep and deep sleep.
Peripherals
Microcontrollers include GPIO (general-purpose pins, configured as input or output), timers (PWM for motor speed and LED brightness), ADC, UART, SPI, I²C, watchdog and RTC (real-time clock). The programmer configures peripherals by writing to memory-mapped registers.
Today: ARM is in almost every phone, and AWS Graviton and Apple silicon bring the same architecture to servers. Building multi-architecture container images (
linux/amd64andlinux/arm64) is a practical DevOps task that comes from this. The RISC-V architecture is a newer open alternative.
Unit 3: Embedded programming and development
Languages and tools
C is the main language (control of memory and hardware), with C++, assembly for critical routines, and increasingly Rust and MicroPython.
| Tool | Purpose |
|---|---|
| Cross-compiler | Builds code on a PC for a different target CPU |
| Linker script and startup code | Place code and data in the memory map and set up the stack |
| Debugger (JTAG / SWD) | Step through code on the real chip |
| Simulator and emulator | Test without hardware (QEMU) |
| IDE and SDK | Keil, STM32Cube, Arduino IDE, ESP-IDF, PlatformIO |
Embedded C techniques
volatiletells the compiler a variable can change outside the program’s control (a hardware register or one changed in an interrupt), so it must not be optimised away.- Bit manipulation to set and clear register bits:
REG |= (1 << 3)to set,REG &= ~(1 << 3)to clear. - Fixed-size types (
uint8_t,uint32_t) for predictable sizes. - Static allocation is preferred over
malloc, to avoid fragmentation and failure. - Avoid recursion and long blocking delays.
Program structure
| Style | Description |
|---|---|
| Super loop | while (1) { read sensors; process; update outputs; } |
| Interrupt-driven | The main loop does background work; interrupt service routines (ISRs) handle events and must be short |
| State machines | Explicit states and transitions; common for control logic |
| RTOS-based | Several tasks scheduled by an operating system (Unit 4) |
Interrupt latency, shared data between an ISR and the main code (needs atomic access or disabling interrupts briefly) and debouncing switches are classic issues. Power saving uses sleep modes with a wake-up interrupt.
Today: firmware is built in CI like any other software, with cross-compilation, static analysis, unit tests on the host and hardware-in-the-loop tests. Over-the-air (OTA) updates and secure boot are now standard, and a failed update must not leave the device unusable.
Unit 4: Real-time operating systems (RTOS)
A real-time operating system guarantees that tasks meet their deadlines. What matters is predictability (bounded response time), not raw speed.
Tasks and scheduling
A program is split into tasks (threads), each with a priority, stack and state.
| Task state | Meaning |
|---|---|
| Ready | Can run, waiting for the CPU |
| Running | Executing |
| Blocked | Waiting for an event, delay or resource |
| Suspended | Stopped until resumed |
| Scheduling | Idea |
|---|---|
| Preemptive priority-based | The highest-priority ready task always runs |
| Round-robin | Time slices among equal priorities |
| Rate-monotonic (RMS) | Fixed priorities, shorter period means higher priority; schedulable if CPU utilisation is below about 69% for many tasks (the bound n(2^(1/n) − 1)) |
| Earliest deadline first (EDF) | Dynamic priority: closest deadline first; can reach 100% utilisation |
Synchronisation and communication
Semaphores, mutexes, message queues, event flags and mailboxes coordinate tasks.
| Problem | Explanation | Fix |
|---|---|---|
| Priority inversion | A low-priority task holds a lock needed by a high-priority task, and a medium task preempts the low one | Priority inheritance or priority ceiling (the Mars Pathfinder bug of 1997 was exactly this) |
| Deadlock | Tasks wait on each other | Ordered locking, timeouts |
| Race conditions | Shared data changed in the middle of an operation | Mutexes, atomic operations |
Common RTOSes
FreeRTOS (the most widespread, owned by AWS), Zephyr, VxWorks, QNX, ThreadX and embedded Linux (soft real-time, with the PREEMPT_RT patch for harder limits). Services include timers, memory pools, interrupt management and low-power support. Design questions are task partitioning, stack sizing, worst-case execution time (WCET) and jitter.
Today: the “priority inversion” and scheduling lessons also appear in server work (lock contention, noisy neighbours). FreeRTOS and Zephyr run on the microcontrollers in IoT sensors, with AWS IoT integration. Real-time Linux and Kubernetes at the edge are used for industrial control.
Unit 5: Communication protocols, networking and IoT
Wired and on-board protocols
| Protocol | Lines | Features | Use |
|---|---|---|---|
| UART (RS-232/485) | 2 (TX, RX) | Asynchronous serial; baud rate, start and stop bits | Consoles, GPS, modems |
| SPI | 4 (MOSI, MISO, SCK, CS) | Fast, synchronous, one master, chip-select per slave | Flash memory, displays, SD cards |
| I²C | 2 (SDA, SCL) | Addressed bus, many devices, slower | Sensors, EEPROM, real-time clocks |
| CAN | 2 differential | Robust, multi-master, message priorities | Cars, industrial machines |
| USB, Ethernet | Host connectivity and networking | PCs, gateways |
Wireless and IoT
| Technology | Range and rate | Use |
|---|---|---|
| Bluetooth Low Energy | Short, low power | Wearables, beacons |
| Zigbee, Thread | Mesh, low power | Smart home |
| Wi-Fi | Local, high rate | Cameras, gateways |
| LoRa / LoRaWAN | Very long range, tiny data | Farms, utilities |
| NB-IoT, LTE-M, 5G | Wide area through cellular networks | Meters, trackers |
| NFC and RFID | Very short range | Payments, tags |
IoT connects embedded devices to the cloud. Application protocols suit constrained devices: MQTT (publish-subscribe through a broker, small and efficient), CoAP (RESTful over UDP), HTTP/HTTPS and WebSockets. A typical architecture: device → gateway → cloud platform (AWS IoT Core, Azure IoT Hub) → storage, analytics and dashboards, with device shadows or twins that mirror device state.
Security and operation
Issues: weak default passwords, unpatched firmware, unencrypted traffic. Practices: secure boot, signed firmware, TLS with per-device certificates, minimal services, secure OTA updates and logging. Edge computing processes data near the device to reduce latency and bandwidth, and TinyML runs small machine-learning models on microcontrollers.
Today: MQTT brokers (Mosquitto, EMQX, AWS IoT Core) and time-series databases are standard back-end components for IoT. Fleet management (provisioning, certificates, OTA rollout, monitoring thousands of devices) is a DevOps problem in its own right, and the Raspberry Pi or ESP32 is the usual starting point.
One-minute recap
| Unit | Key idea | You meet it in |
|---|---|---|
| 1. Introduction | Dedicated function, constraints, hard vs soft real-time, watchdog | IoT devices, routers, probes and restarts |
| 2. ARM and peripherals | RISC, Cortex-M, NVIC, GPIO, timers, ADC | Phones, Graviton, multi-arch images |
| 3. Embedded programming | Cross-compilation, volatile, ISRs, state machines |
Firmware CI, OTA updates, hardware-in-the-loop |
| 4. RTOS | Preemptive priorities, RMS, priority inversion | FreeRTOS, Zephyr, real-time Linux |
| 5. Protocols and IoT | UART, SPI, I²C, CAN; MQTT, LoRa; secure OTA | AWS IoT Core, MQTT brokers, edge computing |
Next in Engineering Revisited: Information Security.
Written by Claude, Anthropic’s AI assistant, as part of Engineering Revisited, a quick refresher of the B.Tech subjects one at a time.