The complete embedded systems guide — what embedded systems are, the hardware/software stack, RTOS vs Linux, testing, and how the pieces fit together. A pillar page linking to our full library of in-depth engineering guides.
An embedded system is a computer that does not look like a computer. It lives inside a thermometer gun, a smart lock, a PLC controller, a drone — dedicated to one job, invisible to its user, and expected to work for years without a reboot, an update prompt, or a blue screen. Your laptop is a general-purpose computer that happens to run applications; an embedded system is the application, with the hardware and software designed together around a single purpose.
This page is the map of the territory. Embedded systems span at least six engineering disciplines — hardware design, firmware, real-time operating systems, embedded Linux, IoT connectivity, and testing — and we have written an in-depth guide for each, grounded in products we actually shipped. Start here for the overview, then follow the links wherever your project needs depth.
Every embedded product, from a $2 sensor node to a Linux-powered video system, is built from the same six layers. Understanding the stack is understanding where your engineering effort — and your risk — lives:
Hardware is the foundation and the least forgiving layer. A missed decoupling capacitor or a wrong footprint means a board spin — weeks and thousands of dollars, every time. Our hardware practice, refined over Rockchip mainboards, Allwinner custom motherboards, and dual-version consumer devices, comes down to a few disciplines: choose core-board-vs-custom deliberately, plan for three spins, treat power integrity as the main event, and hand manufacturing a complete, version-locked package. The full methodology is in the embedded hardware design guide; the step-by-step flow from schematic to Gerbers is in the design process guide.
And when you need hardware in hands fast — to validate an idea or to give the firmware team something to test against — the rapid prototyping guide covers how we get from concept to testable boards in weeks, not quarters.
On microcontrollers, the software is the product behavior. Our RTOS architecture guide covers how to structure firmware that stays maintainable as it grows: task decomposition, inter-task communication, driver layering, and the patterns that keep a FreeRTOS project (like our STM32 PLC controller) debuggable at 3 AM.
Firmware quality, though, is decided by testing — five layers of it, from host-based unit tests through hardware-in-the-loop rigs to production test fixtures. The embedded software testing guide walks through all five with examples from thermometer guns, gas detectors, and medical monitors.
Some products need what a microcontroller cannot give: video pipelines, complex networking, rich user interfaces, or a full application stack. That is when embedded Linux enters — and it enters in two halves. The BSP bring-up guide covers the low-level half: Bootloader, device trees, driver porting, and board bring-up on Rockchip and i.MX platforms. The Linux application development guide covers the upper half: userspace-first architecture, V4L2 camera drivers, VPU video pipelines, cross-compilation, systemd services, and OTA updates.
The rule that governs both halves: push complexity up the stack. What can live in userspace, must; the kernel is for drivers, not business logic.
Connectivity turns a device into a system. The IoT system architecture guide maps the full path from sensor to cloud — protocols, gateways, and backends. The IoT hardware design guide covers the two numbers that decide IoT hardware fate: battery life (duty-cycled down to 100µA standby, as in our 7-day smartwatch) and wireless selection (BLE, WiFi, LoRa, 433MHz, cellular — chosen from requirements, not habit).
And intelligence is moving to the edge: our AI meets IoT guide covers the cloud-vs-edge inference decision, TinyML on ESP32-S3, and the three-tier hybrid architecture (device / gateway / cloud) that survives production. With vision AI like our 30-FPS pose detection and speech recognition running on microcontrollers, "smart device" increasingly means smart on the device.
Two specialized domains deserve mention. Device UIs on resource-constrained MCUs are covered in our LVGL GUI development guide — how to build responsive graphical interfaces where every kilobyte counts. Real-time voice and video, from browser calls to ESP8266 intercoms, is covered in the WebRTC development guide — signaling architectures, embedded media bridging, and codec selection.
For a concrete sense of how the layers combine, consider a connected sensor product — say, a wireless air quality monitor:
We have shipped this exact shape of product multiple times — the ESP32 air quality collector and the gas sensor IoT terminal (with OTA, Android app, and cloud device management) among them. The layers are the same every time; only the requirements change.
One decision shapes everything downstream: microcontroller (MCU) or microprocessor (MPU)? An MCU — STM32, ESP32, Apollo2 — runs bare metal or an RTOS, sips power, boots in milliseconds, and costs dollars. An MPU — RK3128, i.MX6Q, T113 — runs Linux, handles video and networking stacks, and costs tens of dollars plus the software complexity of an operating system.
The selection rule we use with clients: start from the requirements, not the chip. If the product needs a display with rich graphics, video encode/decode, or a full TCP/IP application stack with TLS and a web server, that points at an MPU and Linux. If it needs years of battery life, sub-second boot, or deterministic real-time control, that points at an MCU and an RTOS (or bare metal). The uncomfortable middle — products that need a little of both — is where heterogeneous designs earn their keep: an MCU handling real-time sensor work alongside an MPU running the application, or a Linux-capable chip like the ESP32-S3 stretching into TinyML territory.
Cost traps to avoid: picking an MPU "for headroom" saddles a simple product with Linux maintenance forever; picking an MCU and discovering in month six that you need a web UI means a board redesign. Prototype the riskiest requirement first — the display, the video pipeline, the power budget — and let the measurement choose the chip.
If this page is your entry point into embedded systems, here is the order we recommend. Start with an MCU dev board (STM32 or ESP32) and learn to blink an LED without an OS — that teaches you registers, clocks, and datasheets, the unglamorous foundation everything else assumes. Then add FreeRTOS and build something with two tasks and a queue; the RTOS guide is your companion. Then design a small PCB for it — the schematic-to-PCB guide walks the full flow. Only then move to embedded Linux on a Raspberry Pi or similar: build an image, write a userspace application, and feel the difference between "it boots" and "it is a product" (Linux app guide). Connect it to the cloud (IoT architecture), and you have touched every layer of the stack. Each step takes weeks, not years — and each step makes the guides on this page more useful.
Embedded systems reward generalists who respect specialists: understand all six layers well enough to make system-level tradeoffs, and go deep where your product's risk lives. The guides linked from this page are our attempt to write down what two decades of shipping embedded products taught us — not theory, but the decisions behind real boards, real firmware, and real production lines. Bookmark this page; as we publish new deep-dives, they will be linked from their layer above.
If you are building an embedded product and want a team that has already made these decisions — and these mistakes — our embedded systems service covers hardware, firmware, Linux, and IoT under one roof. Browse the guides above for depth on any layer, then tell us about your project.
Contact us for customized solutions and quotes