The embedded bible: what the field demands, and which part of it is leadership

• C/C++ at production level, in particular modern C++ and embedded C.
• MCU/SoC architectures: ARM Cortex-M/A, possibly RISC-V, memory architecture, MMU/MPU, interrupts, DMA.
• Bare metal and RTOS, e.g. FreeRTOS, Zephyr, ThreadX; embedded Linux on larger systems.
• Bootloader, firmware update, OTA, secure boot.
• Device drivers, HAL/BSP, register-level debugging.
• Real-time behaviour: scheduling, priorities, interrupt latencies, timing, race conditions, deadlocks.
• Memory and resource management under hard constraints.
• Debugging with JTAG/SWD, logic analyser, oscilloscope and trace.

A lead does not write a driver here. He recognises whether a timing problem is a bug or architectural damage — and whether “we will optimise that later” holds this time.

• On-device execution tracing: instruction and data trace over the core's trace interfaces, event output over SWO, an in-RAM trace buffer when there is no wire to the outside.
• Event recording in the operating system: task switches, interrupts, blocking, priority inversion — the only way to see a timing problem instead of guessing at it.
• Timestamps and clock alignment across several control units. Without a common clock a distributed trace is a collection of assumptions.
• Recording in the field: what gets written down, how long it stays, who may read it, and which part of it is personal data.
• Analysis: a trace only becomes a finding when someone holds it against an expectation.
• Traceability from requirement through code to test case and evidence — the same question at process level.

Two things are called tracing here, and they answer the same question: **what actually happened.** The trace on the device answers it for a millisecond, traceability answers it for a programme. Without either one you end up arguing from opinion — in front of the customer, the acceptance board, the court. That is why tracing sits with leadership on this page and not with the tools: it is the principle that a decision must be evidenced, turned into technique.

• Reading schematics and datasheets — and knowing when not to believe the datasheet.
• Bus systems: SPI, I²C, UART, CAN and CAN FD, LIN, automotive Ethernet; off-highway also J1939 and ISOBUS.
• Signal integrity, EMC and the field failures they turn into.
• Energy budget, power supply, sleep and wake paths.
• Sensors and actuators: characteristics, calibration, failure behaviour.
• Manufacturing and test: what is checked at end of line, and what is never reachable again after that.

The point where software decisions create hardware cost and the other way round. Whoever cannot read both sides negotiates blind.

• The cut: what a building block is, where the boundary lies, what may cross it.
• Variant management: one platform across product lines and markets, without every variant becoming its own product.
• Classic and service-oriented architecture side by side, including the transition.
• Middleware and communication patterns, and what they cost in determinism.
• Migrating an existing fleet that keeps running while it is carried across.

This is where what a change costs in five years is decided. That is not a question of technology but of ownership.

• Functional safety in the standard family that applies to the domain — and knowing which one that is.
• Cybersecurity across the lifecycle, including reporting and update duties.
• Evidence: who supplies it, who maintains it, and what happens when a supplier changes.
• Tool qualification — including for anything AI takes over in the process.
• Traceability from requirement to test case.

The most expensive part is never the code, it is the evidence. Plan it too late and you plan the date twice.

• Build, configuration, generation — and who owns the configuration.
• Continuous integration for devices: simulation, hardware in the rack, test automation.
• Test at every level, from unit to vehicle or machine.
• Maturity models and what they actually demand day to day.
• AI-assisted analysis of existing material where the artefacts are machine-readable.

The chain is the longest tie in the whole programme — longer than any supplier contract.

• Who supplies which layer, and where the boundary runs in your own programme.
• Licence, delivery and operating models, and what they tie up over the service life.
• What changing vendor costs, before you need to.
• Open-source building blocks: where they hold, where they do not, and who answers for them.

The decision this site has an instrument for — and a record that outlives it.

• Decision rights: who decides, who must consent, who is consulted.
• An organisation that fits the architectural cut — not the other way round.
• A roadmap against dependencies, not against wished-for dates.
• Escalation before it is needed, and the ability to justify a no.
• Keeping knowledge: what happens when the two people who really understand it leave.

The part that cannot be delegated, because it governs delegation itself.