Live online · enquire for cohort datesMaximum 5 learners per regular batchProgramme code EAL-CSEE-1

Complete Embedded Systems Engineering with AI and Edge Intelligence

A single, sequenced pathway from C programming through microcontroller firmware, RTOS, Embedded Linux, connected systems, automotive embedded and Edge AI, ending with production engineering and technical interview preparation.

Request a Free Career Consultation Jump to the curriculum

Learning outcomes

What you will be able to do at the end

Stated as capabilities you can demonstrate with code, hardware and measurements — not as a list of topics you will have 'covered'.

Language and architecture

Write C that manipulates memory deliberately and defend why.
Explain the compile, link and startup path of a firmware image.
Bring up a peripheral from a reference manual alone.

Concurrency and platforms

Design multi-task firmware and diagnose concurrency defects.
Boot Linux, write a character driver and debug it with kernel logs.
Design a device-to-cloud contract with offline tolerance.

Intelligence and evidence

Deploy a quantised model on-device and report its real budget.
Measure latency, memory and power instead of estimating.
Present and defend your own project under questioning.

Curriculum

Ten modules, in sequence

Open any module for prerequisites, detailed topics, learning objectives, practical exercises, assessment, project milestones, required hardware and software, and expected outcomes.

Core moduleElectiveHours are indicative planning ranges, not a duration guarantee.

Language fundamentals → memory model

C Programming for Embedded Work

Core60–80 hours

C is the working language of embedded development. This module moves past syntax into the memory model, undefined behaviour and debugging discipline that firmware work actually depends on.

Prerequisites

No prior programming experience required
Comfort with basic high-school mathematics

Learning objectives

Read and write C that manipulates memory deliberately rather than accidentally.
Explain how a program is translated, linked and loaded.
Diagnose common defects using a debugger instead of guessing.
Implement and use basic data structures in C.

Detailed topics

Language core

Fundamentals: control flow, scope, functions, recursion
Data types, qualifiers, conversions and integer promotion
Operators and operator precedence
Arrays and strings (including NUL-termination discipline)
Structures, unions, enums and bit-fields

Memory model

Pointers and pointer arithmetic
Function pointers and callbacks
Arrays vs pointers, multi-dimensional arrays
Memory layout: text, data, BSS, heap, stack
Storage duration: automatic, static, thread, allocated
Dynamic allocation and why embedded code often avoids it

Embedded-critical idioms

Bit manipulation: masks, shifts, set/clear/test, bitwise tricks
const, volatile and restriction — what the compiler may assume
Register access patterns and read-modify-write hazards
Preprocessor: macros, conditionals, include guards, token pasting

Toolchain and correctness

Compilation stages: preprocess, compile, assemble, link
Object files, symbols, sections and the linker map
Debugging with GDB / an IDE debugger: breakpoints, watchpoints, stepping
Common programming errors, undefined behaviour and edge cases
Data structures in C: linked lists, stacks, queues, hash maps

Practical exercises

Write a memory-layout explorer that prints addresses of globals, locals and heap allocations.
Implement a ring buffer with fixed storage and prove overflow behaviour under stress.
Build a bit-field register simulation for a fictional peripheral.
Reproduce and fix five seeded bugs in a provided C codebase using only a debugger.

Assessment

Timed Embedded C worksheet (pointers, memory, volatile) plus a code review of a provided module against a published checklist.

Project milestone

A reviewed, documented utility library (ring buffer, dynamic string, CRC) with unit tests.

Required hardware

Any computer capable of running a C toolchain

Required software

GCC or clang
GDB / IDE debugger
Make or CMake
Editor or IDE of choice

Expected learning outcomes

Can read unfamiliar C and explain its memory behaviour.
Can write defensive C with explicit bounds and lifetime rules.
Can locate defects with a debugger rather than by print statements alone.

Architecture → peripherals → hardware debugging

Embedded Systems Foundations

Core50–70 hours

How a microcontroller is actually built and controlled: the bus, memory-mapped peripherals, interrupts, analog and timing peripherals, and the discipline of reading a datasheet rather than a tutorial.

Prerequisites

Module 1 — C programming
Basic electronics: voltage, current, pull-ups

Learning objectives

Navigate a datasheet and reference manual to answer a concrete peripheral question.
Configure GPIO, timers, interrupts, ADC and PWM from register-level understanding.
Use a logic analyser or oscilloscope to confirm what the firmware is doing.

Detailed topics

Architecture

Processor core, bus matrix, memory map and clock tree
Flash, SRAM, registers and memory-mapped peripherals
Reset and clock configuration, PLLs and prescalers
Power domains, sleep modes and low-power design basics

Core peripherals

GPIO: modes, pull-ups/pull-downs, alternate functions, drive strength
Timers and counters: capture, compare, PWM generation
Interrupts: NVIC concepts, priority, latency, shared handlers
ADC: sampling, reference voltages, resolution, noise
PWM: duty cycle, frequency, dead-time intuition
DMA: transfers, arbitration, common pitfalls

Reading hardware documentation

Datasheet vs reference manual vs errata sheet
Register maps, bit fields, and read/write constraints
Typical application circuits and reference designs
Peripheral interface overview: UART, SPI, I2C, CAN

Hardware debugging

Multimeter and logic-analyser workflow
Signal integrity basics: pull-ups, debouncing, edge cases
Power measurement for battery-powered designs
Systematic fault isolation: split hardware vs firmware

Practical exercises

Bring up a board from a blank project using only the reference manual.
Debounce a mechanical input in hardware and in firmware; compare latency.
Capture I2C traffic with a logic analyser and decode a real transaction.
Measure current draw across sleep modes and chart the results.

Assessment

Peripheral bring-up practical: configure an unseen peripheral from documentation and demonstrate correct waveform behaviour.

Project milestone

Sensor acquisition node that samples, filters and reports data over UART with measured timing.

Required hardware

Development board (STM32 or ESP32 class)
USB cable
Logic analyser (shared/optional)
Breadboard, jumper wires, passives

Required software

Vendor IDE or VS Code + vendor toolchain
Serial terminal
Logic analyser software

Expected learning outcomes

Can implement peripheral drivers from reference-manual descriptions.
Can validate firmware behaviour against measured signals.
Can distinguish a hardware fault from a firmware fault efficiently.

Startup code → drivers → firmware architecture

Firmware Development on ARM Cortex-M

Core70–90 hours

The step from "code that runs" to firmware engineering: what happens before main(), how the linker shapes memory, how drivers are structured, and how firmware is tested and maintained.

Prerequisites

Module 1
Module 2

Learning objectives

Explain the boot path from reset vector to main().
Produce and read a linker script and linker map.
Write re-usable, testable peripheral drivers with clean interfaces.
Apply defensive firmware practices: watchdogs, assertions, error paths.

Detailed topics

ARM Cortex-M platform

Cortex-M architecture: registers, modes, exceptions and faults
ARM vs Thumb instruction sets and calling conventions
STM32 family overview and ecosystem
ESP32 architecture, dual-core considerations and the IDF

Startup and linking

Reset handler, vector table, .data and .bss initialisation
Linker scripts: sections, memory regions, symbols
Reading the map file and understanding code size
C runtime initialisation and static constructors in C++ (awareness)

Toolchains and workflow

GCC-arm / vendor toolchain, Make and CMake build systems
OpenOCD / ST-Link debugging, flashing and RTOS-aware debugging
Compiler/linker flags, -Wall discipline, warning triage
Static analysis and formatting in the loop (clang-tidy, clang-format)

Firmware architecture

Layering: HAL vs driver vs service vs application
Bare-metal superloop vs interrupt-driven design
State machines, event queues and non-blocking patterns
Hardware abstraction and portability across boards
Peripheral driver design: init, read/write, error handling

Quality and maintenance

Unit testing firmware logic on host (Unity/Ceedling style)
Mocking hardware boundaries for testable code
Code review practice and coding standards
Debugging techniques: logging, tracing, fault dumps, hard-fault analysis
Code quality, maintainability and documentation habits

Practical exercises

Write a linker script for a custom memory layout and verify it in the map file.
Implement a UART driver with DMA receive, timeouts and an error contract.
Convert a superloop application into a documented state machine.
Add host-side unit tests for a parser module with 90%+ branch coverage.

Assessment

Driver design exercise under review, plus a hard-fault post-mortem report on a provided failing firmware image.

Project milestone

A multi-peripheral data logger with a layered architecture, unit tests and a documented driver API.

Required hardware

STM32-class development board
Sensors for interfacing
Debugger/programmer

Required software

arm-none-eabi-gcc
OpenOCD or vendor probe software
CMake/Make
Ceedling or Unity
clang-format / clang-tidy

Expected learning outcomes

Can build firmware from scratch with a defensible architecture.
Can diagnose faults and memory corruption using a debugger.
Can review another engineer’s firmware code constructively.

Tasks → synchronisation → real-time debugging

RTOS and FreeRTOS

Core60–80 hours

Concurrency is where embedded engineers most often fail interviews and production systems. This module covers scheduling, synchronisation and the failure modes that only appear under timing pressure.

Prerequisites

Module 3 — firmware development
Comfort with C pointers and callbacks

Learning objectives

Decompose an application into tasks, queues and interrupt-safe handoffs.
Reason about priority, blocking time and worst-case responsiveness.
Diagnose priority inversion, deadlocks, starvation and stack overflow.
Apply watchdogs and timing analysis to a real application.

Detailed topics

Scheduling fundamentals

Tasks, states, schedulers and context switching
Preemptive vs cooperative scheduling, time slicing
Priorities, round-robin and assignment strategy
Interrupt latency, deferred work and ISR best practice

Communication and synchronisation

Queues: copy semantics, sizing, blocking behaviour
Mutexes vs semaphores, recursive mutexes
Event groups, task notifications, stream/message buffers
Interrupt-safe APIs and FromISR variants

Failure modes

Priority inversion and priority inheritance
Deadlock, livelock and starvation
Stack sizing and stack-overflow detection
Race conditions and non-atomic critical sections
Memory management options and fragmentation

Operations and analysis

Watchdogs: task-level and system-level feeding discipline
Timing analysis: CPU load, headroom, worst-case blocking
Tracing and visualisation: runtime stats, stack high-water marks
Real-time debugging strategies under intermittent faults
FreeRTOS application structure and porting concepts

Practical exercises

Build a producer/consumer pipeline with bounded queues and back-pressure.
Reproduce a priority inversion deliberately, then fix it with priority inheritance.
Instrument a system to find the task causing a watchdog reset.
Measure scheduler jitter under load and report the distribution.

Assessment

Concurrency review session: presented with a failing RTOS design, identify and fix the defects within a time box.

Project milestone

Multi-task sensor controller with queue-based IPC, queue-based logging, watchdog and measured CPU load headroom.

Required hardware

STM32 or ESP32 development board
Two or more sensors

Required software

FreeRTOS (vendor bundle or standalone)
Trace/recording tool
Debugger with RTOS awareness

Expected learning outcomes

Can design multi-task firmware with documented timing behaviour.
Can explain and fix concurrency defects in code review.
Can justify stack sizes and queue depths with measurements.

Boot → kernel → drivers → build systems

Embedded Linux and Device Drivers

Core80–110 hours

Moving from bare-metal to a general-purpose operating system: bootloaders, kernel structure, device trees, character drivers and reproducible image builds.

Prerequisites

Module 3
Comfort with the Linux command line
Module 4 helpful but not mandatory

Learning objectives

Trace a Linux system from power-on to user space.
Write, load and debug a character device driver.
Build a reproducible image with Buildroot or Yocto.
Debug kernel-level problems using logs and tracing.

Detailed topics

Linux foundations

User space vs kernel space, syscalls, virtual memory
Processes, threads, scheduling and IPC
Filesystems, device nodes, permissions
Shell tooling, permissions, package management

Boot chain

BootROM → bootloader (U-Boot) → kernel → root filesystem
Kernel command line and init systems
Cross-compilation: toolchains, sysroots, target vs host

Kernel internals and drivers

Kernel architecture: monolithic, modules, subsystems
Kernel modules: build, load, parameters, lifecycle
Device trees: nodes, properties, bindings, overlays
Character device drivers: file_operations, ioctls, polling
Kernel–user space copy, locking, and concurrency in drivers
Driver debugging: dmesg, ftrace, kprobe awareness, kgdb

Build systems and integration

Buildroot: minimal reproducible images
Yocto: layers, recipes, images (where appropriate)
Board support packages and porting to a new board
System integration: services, logging, updates

Practical exercises

Boot a board to a shell and document the complete boot path.
Write a character driver exposing a device with read/write/ioctl and test it from C.
Add a device-tree node for a new peripheral and verify enumeration.
Create a Buildroot image containing a custom application and driver.

Assessment

Driver implementation plus a boot-time analysis report identifying each stage and its artefacts.

Project milestone

Linux-based device that loads a custom driver, exposes sensor data through it and logs to a service.

Required hardware

Linux-capable board (e.g. Raspberry Pi class or an i.MX/Allwinner class board)
Sensor or peripheral to drive

Required software

Linux workstation or VM
Cross toolchain
U-Boot
Buildroot or Yocto
Kernel source tree
QEMU for early practice

Expected learning outcomes

Can port and boot Linux on unfamiliar hardware with documentation.
Can implement and debug a kernel module or character driver.
Can produce a reproducible image build.

On-board buses → networking → device-to-cloud

Communication Protocols and IoT

Core50–70 hours

From the wires on the board to the message in the cloud: serial buses, CAN, TCP/IP stacks, constrained-device protocols, provisioning, updates and security fundamentals.

Prerequisites

Module 2
Module 3

Learning objectives

Implement and debug UART, SPI and I2C interactions at the signal level.
Explain CAN/CAN FD framing and why arbitration matters.
Design a device-to-cloud message contract using MQTT or CoAP.
Apply basic security practices to a connected device.

Detailed topics

On-board and in-vehicle buses

UART: framing, baud, flow control, DMA reception
SPI: modes, chip selects, full-duplex throughput
I2C: addressing, clock stretching, error recovery
CAN: frames, arbitration, filters, error states
CAN FD: payloads, bit-rate switching, migration
Wiring discipline: signal integrity, grounding, termination

Networking

TCP/IP model, sockets and the client/server pattern
DNS, DHCP, TLS basics on constrained devices
MQTT: topics, QoS levels, retain, last will, session handling
CoAP: request/response, observe, constrained payload use
Device-to-cloud architectures and telemetry pipelines

Device lifecycle

Device provisioning and identity
Telemetry design: batching, back-off, idempotency
Over-the-air firmware updates and rollback safety
Security fundamentals: keys, secure boot awareness, least privilege
Local broker testing and offline-tolerant behaviour

Practical exercises

Recover an I2C bus stuck mid-transaction in software.
Simulate a CAN exchange and analyse arbitration between two nodes.
Publish telemetry from a device to a broker and consume it in a dashboard.
Implement an image-validated OTA update with a rollback path.

Assessment

Protocol debugging practical: given a faulty capture, identify and correct the timing/protocol defect.

Project milestone

Connected node that streams sensor telemetry, tolerates network loss and supports a safe firmware update.

Required hardware

Two microcontroller boards for bus work
CAN transceiver module
Wi-Fi capable board (ESP32 class)

Required software

Logic analyser software
mosquitto or equivalent broker
Network client tools (mqtt explorer, tcpdump)

Expected learning outcomes

Can design and debug multi-device communication.
Can define a robust device-to-cloud message contract.
Can identify the main security risks in a connected device.

ECUs → diagnostics → architecture → safety

Automotive Embedded Systems

Elective45–65 hours

An elective for learners targeting automotive roles: how vehicles communicate, how diagnostics work in practice, how automotive software is architectured, and the safety and security expectations that come with it.

Prerequisites

Module 4 — RTOS
Module 6 — CAN fundamentals

Learning objectives

Describe the structure of a modern ECU and its networks.
Perform UDS diagnostic request/response analysis.
Explain the intent of AUTOSAR layering and automotive software architecture.
State the basics of functional safety and automotive cybersecurity awareness.

Detailed topics

Vehicle electronics

ECU fundamentals: domains, gateways, zonal architectures
Powertrain, chassis, body and ADAS ECU categories
Automotive communication: CAN, CAN FD, LIN, automotive Ethernet overview
Bus topology, termination and gateway routing

Diagnostics

OBD-II and regulatory diagnostics overview
UDS (ISO 14229): services, session control, DTC handling
Diagnostic message analysis on a real or simulated bus
ISO-TP addressing and multi-frame transfer
Automotive testing: HIL concepts, test cases, regression

Software architecture

AUTOSAR concepts: BSW, RTE, SWC layering (conceptual)
Classic vs Adaptive platform awareness
State management and diagnostics in architecture
Coding standards awareness (MISRA C) and static analysis

Safety and security

Functional safety fundamentals: ISO 26262 intent, ASIL awareness
Safety mechanisms: watchdogs, plausibility checks, redundancy
Automotive cybersecurity awareness: ISO/SAE 21434 intent, secure boot, keys
Verification culture: traceability and evidence

Practical exercises

Capture and decode a UDS session, including a DTC read and clear.
Build a CAN simulator that replays a diagnostic exchange.
Review an automotive-style module against a MISRA-informed checklist.
Write a hazard-and-risk note for a simple feature.

Assessment

Diagnostic analysis report plus a design review of a simulated ECU software change.

Project milestone

Vehicle-data logger capturing CAN traffic with a UDS-driven configuration interface.

Required hardware

Two boards with CAN transceivers
Optional: CAN-capable vehicle interface

Required software

CAN analyser tool or simulator
UDS request tooling
Static analysis tool

Expected learning outcomes

Can read and analyse automotive diagnostic traffic.
Can explain how automotive software architecture constrains design.
Can discuss functional safety and cybersecurity at an awareness level appropriate to a junior/mid role.

Sensor data → TinyML → on-device inference

Embedded AI and Edge Intelligence

Core70–90 hours

AI used where it solves an embedded problem: collecting and preparing sensor data, choosing and compressing a model, deploying it under real memory, latency and power limits, and testing the system — not just the model.

Prerequisites

Module 1
Module 3
Module 6 helpful for connected-inference examples

Learning objectives

Frame an embedded problem as a measurable machine-learning task.
Train, quantise and deploy a model to a constrained device.
Measure and report latency, memory and power for an on-device model.
Validate the whole sensing-to-inference pipeline, not just accuracy.

Detailed topics

Foundations

AI/ML fundamentals: features, labels, training vs inference
Supervised learning, classification vs regression vs anomaly detection
Model selection reasoning for constrained problems
Overfitting, dataset balance, evaluation metrics that matter

Data pipeline

Sensor-data collection on device and on host
Sampling rates, windowing and synchronisation
Preprocessing: filtering, normalisation, feature extraction
Labelling strategy and dataset hygiene
Data leakage and how it invalidates results

Model compression and deployment

Quantisation: post-training int8, calibration, accuracy impact
Pruning and operator support awareness
TinyML runtimes: TensorFlow Lite for Microcontrollers, equivalent options
Model representation: FlatBuffers, arena allocation
Memory constraints: RAM/flash budgeting for inference
Latency budgets and power consumption measurement

System-level engineering

Feature extraction on microcontroller (FFT, statistical windows)
Interrupt-driven inference and streaming classification
Edge inference alongside RTOS tasks
Anomaly detection on sensor streams
Model evaluation on device vs on host
System-level testing: drift, corner cases, degraded inputs
Federated/continuous-improvement awareness (conceptual)

Practical exercises

Collect, label and train a gesture or vibration classifier from real sensor data.
Quantise a model and measure the accuracy/latency/memory trade-off explicitly.
Deploy inference inside an RTOS application with a documented latency budget.
Build an anomaly detector on a sensor stream and define an alert threshold from data.

Assessment

Model deployment report: dataset description, training approach, quantisation results, on-device latency/memory measurements and failure analysis.

Project milestone

On-device inference application (for example predictive-vibration or gesture recognition) running within a stated resource budget.

Required hardware

Microcontroller with sufficient RAM/flash for inference
IMU or audio/microphone sensor
Linux or desktop host for training

Required software

Python with a training framework
TensorFlow Lite for Microcontrollers or equivalent
Edge Impulse or equivalent (optional)
Serial/data-capture tooling

Expected learning outcomes

Can take an embedded problem to a deployed, measured on-device model.
Can justify model and precision choices with numbers.
Can test an intelligent embedded system for real-world failure modes.

Git → tests → review → reliability

Production Engineering

Core35–50 hours

The practices that separate a hobby project from engineering work: version control discipline, automation, testing strategy, review, documentation, reliability and security awareness.

Portfolio → assessments → interviews → search

Career Preparation

Core30–40 hours

Turning completed work into evidence: a technical resume, a public portfolio, assessments under time pressure, and explaining your own projects clearly to an interviewer.

Sequencing note.Modules 1–6 form the shared core. Module 7 (Automotive Embedded) is an elective, and modules 8–10 close the path with Edge AI, production engineering and career preparation. Indicative hours total roughly 745 at the upper range, which is why the programme is described in months rather than weeks.

Courses & fees

Choose the route that fits your goal

Live online training, focused batches and practical hardware work. Course fees include the hardware kit and exclude GST.