Who this programme is for
ECE, EEE, instrumentation and CSE graduates who want to write the software that runs on hardware — firmware, drivers and real-time systems. You need working C and a willingness to debug with an oscilloscope next to your keyboard.
What you will be able to do
- Bring up an ARM Cortex-M board from reset vector to running application
- Write peripheral drivers against a datasheet rather than copying vendor examples
- Design with an RTOS: tasks, priorities, queues and the deadlock traps
- Debug with JTAG, a logic analyser and your own instrumentation
- Implement and troubleshoot UART, SPI, I2C and CAN links
Syllabus
Module 1 — Embedded C, properly
Pointers and memory layout, volatile and why it matters, bit manipulation, structs and unions for register maps, the linker script, and what the startup code does before main().
Module 2 — Microcontroller architecture
ARM Cortex-M core, memory map, the NVIC and interrupt handling, clock trees and configuration, power modes, and reading a reference manual without drowning in it.
Module 3 — Peripherals and drivers
GPIO, timers and PWM, ADC, DMA, and writing your own driver layer for each — on the board, verified on the bench.
Module 4 — Communication protocols
UART, SPI, I2C and CAN: the electrical reality, the protocol rules, driver implementation, and how to find the fault when a bus goes quiet.
Module 5 — Real-time operating systems
Task scheduling and priorities, queues, semaphores and mutexes, priority inversion, interrupt-to-task handoff, stack sizing, and measuring real-time behaviour.
Module 6 — Debugging and reliability
JTAG and SWD debugging, fault handlers and post-mortem analysis, watchdogs, logic analyser workflow, and defensive firmware patterns.
Module 7 — Linux and embedded systems
An introduction to embedded Linux: boot flow, device tree, kernel modules and the character device interface — enough to know which side of the MCU/MPU line a job sits on.
Module 8 — Capstone
Build a complete multi-peripheral product on hardware — sensor acquisition, an RTOS task structure, a communication link and a resilience story — then defend the design choices under review.