Here is how the three actually differ, and what each is bad at.

Classic CAN (ISO 11898-1/-2)

What it is: a multi-drop differential bus, up to 1 Mbit/s, 8 data bytes per frame, non-destructive bitwise arbitration by identifier, strong error detection (15-bit CRC, bit monitoring, form/stuff checks) with automatic retransmission.

What it is genuinely good at:

• Cost and ruggedness. A CAN transceiver is cents. The bus is two wires, no switch, no hub, tolerant of ground shift and EMI, and it degrades gracefully — a node dropping off does not take the segment down.
• Event-driven traffic with priority. Arbitration means the lowest-numbered ID always wins the bus with no collisions and no configuration. For “report this alarm now” traffic that is exactly right.
• Determinism at low load. Below roughly 30–40% bus load, worst-case latency for a given priority is calculable and small.
• Ecosystem. CANopen, J1939, and decades of tooling, diagnostics, and engineers who know it.

What it is bad at — state these before choosing it:

• 8 bytes. A 12-axis sensor packet or any structured record needs fragmentation (ISO-TP), which adds latency, state, and failure modes.
• 1 Mbit/s ceiling, and you only reach it on a short bus. At 1 Mbit/s the practical bus length is on the order of 40 m; longer buses force lower rates because arbitration needs the signal to propagate to the far end within a bit.
• Bus load cliff. Above ~50–60% load, low-priority frames see large and hard-to-bound latency, and a chatty node can starve them entirely.
• No native security. No authentication, no encryption; any node can send any ID. Mitigations exist (bus guardians, MACsec-style add-ons, segmentation) but they are bolt-ons.
• A single retransmitting faulty node can dominate the bus until error confinement kicks in.

CAN FD (ISO 11898-1:2015)

What it changes: up to 64 data bytes per frame, and a second, faster bit rate for the data phase (commonly 2–5 Mbit/s, 8 Mbit/s achievable with care) while the arbitration phase stays at the classic rate. Better CRC (17- or 21-bit) for the larger payload.

Why it is often the right upgrade:

• The 8-byte problem disappears without fragmentation. One 64-byte frame instead of eight classic frames means less protocol overhead and less software state.
• Effective throughput rises several-fold for payload-heavy traffic, because both the payload is bigger and the data phase is faster.
• You keep the topology, the transceivers’ ruggedness, the arbitration model, and most of the tooling. It is an incremental change, not a re-architecture.
• CANopen FD and J1939 variants exist to carry the ecosystem forward.

What it is bad at / what to watch:

• The arbitration phase is still limited to the classic bit rate. CAN FD does not raise the number of frames per second you can arbitrate; it raises the bytes per frame. A system that is frame-rate-bound, not payload-bound, gets little from it.
• Signal integrity gets harder. The fast data phase shrinks bit times to hundreds of nanoseconds; ringing, stub length, connector quality, and transceiver loop delay now matter. A messy bus that tolerated 500 kbit/s classic will not tolerate 5 Mbit/s FD without topology work and possibly ring or point-to-point rather than long stubs.
• Mixed classic/FD segments need care. A classic-only node on an FD bus sees FD frames as errors and floods the bus unless partial networking / FD-tolerant transceivers are used. Usually the whole segment must be FD.
• Controller support: older MCUs have classic-only CAN peripherals. Check the silicon, not the datasheet marketing.

Switched industrial Ethernet — PROFINET, EtherCAT, and TSN

Not one thing. “Industrial Ethernet” covers protocols with very different determinism stories, all on 100 Mbit/s or 1 Gbit/s PHYs.

• PROFINET RT — standard switched Ethernet, prioritised frames, cycle times down to ~1 ms; PROFINET IRT adds hardware time-slotting for sub-millisecond, low-jitter cycles but needs IRT-capable switches.
• EtherCAT — a single frame passes through every node, each reading and writing its slice on the fly (“processing on the fly”). Extremely efficient, cycle times to tens of microseconds, but it is a specific master/slave topology with EtherCAT slave controllers in each node, not general IP networking.
• TSN (IEEE 802.1 set — 802.1AS, Qbv, Qci, CB, …) — brings scheduled, bounded-latency traffic to standard Ethernet, letting control traffic and IT traffic share the same infrastructure. It is the direction the industry is moving; it also requires TSN-capable switches and endpoints and non-trivial network engineering (a schedule computed and pushed to every bridge).

What Ethernet buys you:

• Bandwidth: 100–1000 Mbit/s, so video, firmware images, and high-channel- count data are no longer a problem.
• Routable, IT-integratable: TCP/IP, TLS, MQTT/OPC UA to the cloud on the same wire (with segmentation and a firewall).
• Determinism if configured for it: IRT, EtherCAT, or TSN give bounded latency and low jitter — but plain “Ethernet” does not; a standard switch under load has queueing delay and no guarantees.

What it is bad at:

• Cost and complexity per node: a PHY, magnetics or connector, often a managed or special switch, more powerful MCU/SoC, and a stack. Multiples of a CAN node.
• Topology and cabling: star or line with switches, 100 m segment limit per hop, more connectors, more to go wrong mechanically in a vibrating machine.
• Determinism is opt-in and fragile to misconfiguration. A well-meaning IT change, a non-TSN device plugged into a TSN segment, or an unmanaged switch dropped in “temporarily” can quietly break the timing guarantees.
• Security surface: now you are on an IP network, with everything that implies. IEC 62443 becomes your problem.

A decision order that works

1. What is the largest single payload, and how often? ≤ 8 bytes, event-rate → classic CAN is still fine. 8–64 bytes → CAN FD. Kilobytes, or any streaming → Ethernet.
2. What is the tightest cycle time with bounded jitter you must hit? Above 5–10 ms and modest, CAN/CAN FD or PROFINET RT. Around 1 ms, PROFINET IRT or CAN FD on a lightly loaded bus. Under 250 µs with many axes, EtherCAT. Mixed critical and best-effort on one wire, TSN.
3. Node count, cost target, and environment. Dozens of cheap rugged nodes on a harness → bus wins. A cell with a handful of high-value devices and a video feed → Ethernet.
4. Does it need to talk to IT / cloud directly? Yes and at rate → Ethernet. Occasionally → keep the fieldbus and put the IP stack in the gateway.
5. Who maintains it for ten years? A plant electrician can fault-find a CAN bus with a multimeter. A TSN schedule needs someone who understands 802.1Qbv.

The realistic answer is usually “bridge”

Greenfield-everything-Ethernet is rare. The common shape is CAN or CAN FD at the machine edge for sensors and drives, aggregated by a gateway that speaks the fieldbus on one side and OPC UA / MQTT over Ethernet on the other, doing protocol translation, buffering across link outages, and store-and-forward. That gateway is also the right place to put the security boundary, the data-model mapping, and the firmware-update path — rather than pushing all of that cost into every edge node.

Designing that seam well — which data is published at what rate, what is buffered, how backpressure and reconnection behave — is usually more of the engineering effort than picking the physical layer.

This is the contents list we work to. It spans hardware, firmware, test, and compliance, because a product that splits those across separate incomplete hand-overs has no owner for the seams.

1. Released, versioned design data

Not “the latest files” — a release, tagged, with a revision and a date.

Hardware

• Schematics (PDF) and source project, at the released revision.
• PCB layout source, Gerbers, drill, netlist, fab drawing with stack-up and impedance spec, assembly drawings.
• BOM with manufacturer part numbers, approved alternates, and DNP items marked. Lifecycle status noted for anything NRND or single-source.
• Mechanical: enclosure models, gaskets, thermal interface parts, fasteners, labels and their artwork.
• The ECO/ECR history — every change since the first build, why it was made, and which build it entered. This is how the factory knows a v3 board is not a v2 board with a sticker.

Firmware and software

• Source, in a repo the client controls, tagged for the release.
• A reproducible build: pinned toolchain (container or documented exact versions), pinned dependencies, one command. The test is that a fresh machine reproduces the released binary — or the released image manifest — bit for bit. (For a Yocto-based product, this is its own checklist; see the Embedded Linux hub’s BSP hand-over reference.)
• The released binaries themselves, with checksums and signatures, and the public keys to verify them.
• Build and flashing instructions from empty machine to programmed unit.

2. Requirements and traceability

• The requirements the product was built to, at their released version.
• A traceability matrix: requirement → design element → verification test → result. Even a lightweight one. This is what a customer audit, a safety assessor, or a future change-impact analysis needs, and it cannot be reconstructed later without re-deriving intent.
• Interface control documents for every external interface (connector pinouts, protocols, message definitions, electrical limits).

3. Verification and validation records

• Test plans and procedures, with pass/fail criteria that are numbers, not adjectives.
• Results for the released revision: what was run, on how many units, with what outcome, signed and dated. Raw data retained, not just a summary.
• Coverage statement: what was tested, what was explicitly not, and why. A hand-over that implies everything was verified when it was not is worse than one that is honest about the gaps.
• Regression suite and how to run it, so the client can re-verify after a change.

4. Compliance / certification file

Whatever regimes apply (EMC, safety, radio, environmental, sector-specific):

• Test reports from the accredited lab, in full, not just the certificate.
• The Declaration of Conformity and the technical file / construction file behind it.
• The exact configuration tested: hardware revision, firmware version, cables, orientation, peripherals, any test-mode firmware used. A certificate that does not pin the configuration does not transfer to production cleanly.
• Applied standards and their editions. Standard editions change; the file must say which one the product was assessed against.
• Conditions and limitations of the approval, and the class/limits the product passed against (with margin, ideally).
• What invalidates the certification — which changes force re-test. This is the single most useful sentence for the team that inherits it.
• Radio module certs (modular approval IDs) and the conditions attached to using them under that approval.

5. Software bill of materials and update story

• SBOM (SPDX or CycloneDX) for the shipped image: every component, version, licence, and source. Increasingly a legal requirement, and the basis for answering “are we affected by CVE-XXXX” quickly.
• Licence compliance: the licence manifest, written offers where copyleft requires them, and the corresponding source archive.
• Secure/verified boot: key hierarchy, what signs what, where keys are stored or fused, key-rotation procedure, and the recovery path for a unit that fails a signature check.
• Field update mechanism: how an update is packaged, signed, delivered, applied, and rolled back; A/B or recovery-slot behaviour; what happens on power loss mid-update; version-compatibility rules.
• Provisioning: per-unit secrets, certificates, serial numbers — how they are generated, injected at the factory, and stored/backed up.

6. Manufacturing pack

• Factory test procedure with a defined sequence, measurement points, and limits for every measured parameter. This is what makes a contract manufacturer able to accept or reject a unit without judgement calls.
• Test fixtures: design, firmware, calibration procedure and interval, and a spare or the data to build one.
• Programming: what gets programmed, in what order, with what tool, and how the line verifies it took.
• Calibration: what is calibrated, against what reference, to what tolerance, and where the calibration constants are stored.
• Serialisation and labelling: numbering scheme, label content and placement, what is recorded per unit and where that record lives.
• Packaging and ESD/transport requirements.
• First-article inspection report and the golden-unit definition.
• Yield and known failure modes from the builds so far, with the diagnosis for each — so the line does not re-learn them.

7. Field support material

• Service manual: diagnosis flow, safe-to-replace parts, what needs a depot, recovery procedures (including “how to un-brick”).
• Diagnostics: what the product logs, how to extract it, and how to read it.
• RMA criteria and the data to capture on a return.
• Spares strategy: which parts, expected failure rates if known, last-time-buy exposure on any component.

8. The known-issues and deferred-work list

Every project has one. A hand-over without it means the client discovers the list one incident at a time.

• Open bugs with severity, reproduction, and any workaround.
• Deferred features and the reason they were cut.
• Design compromises made under schedule pressure and what a proper fix looks like.
• Component or supplier risks not yet resolved.
• Anything that “works but we do not fully understand why”.

9. Contacts, licences, and accounts

• Which third-party licences, subscriptions, or accounts the product depends on (cloud tenant, certificate authority, code-signing service, paid libraries), who holds them, and renewal dates.
• Escrow arrangements if any.
• A named transition contact and a defined support window, so the hand-over is a ramp, not a cliff.

How to know the pack is complete

Run the test that matters: give the pack to an engineer who was not on the project and have them, using only what is in the box, (a) build the firmware and get a matching binary, (b) build and pass one unit through the factory test, and (c) answer “what change would invalidate the CE marking”. If any of the three needs a phone call, the pack has a hole, and the hole is cheaper to fill now.

The trade-off

Assembling this properly is weeks of work, concentrated at the end of a project when budget and patience are thinnest, and most of it produces no visible feature. It is genuinely tempting to ship the design files and a README and call the rest “support”.

The cost of that shortcut is entirely borne later and by someone else: the first CM build that fails because the test limits were in someone’s head, the CVE response that takes three weeks because there is no SBOM, the field failure with no service procedure, the change that quietly invalidates a certification because nobody wrote down what the certification depended on. The pack is insurance, and like insurance its value is invisible right up until the moment it is the only thing that helps.

This is the checklist we run schematics against before releasing them to layout. It assumes the design is functionally “done” — the point is to find what “done” missed.

Power: the section that causes the most respins

Rail inventory and budget

• List every rail: voltage, tolerance, estimated and worst-case current, source (which regulator), and every load on it. A spreadsheet, not a mental model.
• Check each regulator against its worst-case load including inrush and transient, not typical. Add margin for the load estimate being wrong — 30% is common at this stage.
• Thermal: (Vin − Vout) × I for every linear regulator. An LDO dropping 3.3 V at 500 mA is dissipating 1.65 W and needs a heatsinking copper plan that layout has to know about now.
• Efficiency and input current: does the upstream supply / connector / fuse actually deliver the sum of input currents at low line?

Sequencing

• Does the SoC/FPGA have a required power-up and power-down order? Most do (core before I/O, or a specific ramp relationship). Violating it can cause latch-up or excess current through internal diodes. Check the datasheet’s sequencing section and confirm the design enforces it — enable-pin daisy chains, a sequencer IC, or a supervisor.
• Power-down order matters too, and is more often missed. A rail collapsing in the wrong order can back-drive an I/O bank.
• What happens on a brown-out — does the sequence restart cleanly, or can it hang half-powered?

Decoupling, as schematic intent

• Every power pin has decoupling specified with values and count per the device datasheet. Bulk capacitance per rail sized for the load step.
• It is fine that placement is layout’s job — but the schematic must show the intent so the reviewer can check nothing is missing and layout knows the target.

Reset, clocks, and strapping

• Every reset: source, polarity, pull resistor, RC or supervisor timing, and which devices it reaches. Open-drain resets wired together need one pull-up, not none and not five.
• Reset supervisor threshold matched to the SoC’s minimum operating voltage, with hysteresis, so a sagging rail does not leave the part running out of spec.
• Watchdog: present, wired to actually reset the system, and not defeatable by the failure it is meant to catch.
• Boot strapping / mode pins: this is a classic post-layout disaster. Every strap pin identified, its required level confirmed against the boot-mode table, and the resistor value chosen so it wins against the pin’s other function (often the same pin is a functional I/O with its own loading). Note which straps need to be changeable for bring-up and give them a header or a 0 Ω option.
• Clocks: every oscillator/crystal has the load caps per the crystal spec and the oscillator’s drive level checked. PLL supplies filtered. Spread-spectrum choice made deliberately (it helps EMC, it can hurt a camera or ADC).

Every net: reference and return path

Signal integrity is decided in the schematic by what you connect to what, before a single trace exists.

• For each interface, name the return-current path. A differential pair referenced to a plane that has a split under it will radiate and fail EMC — and the fix is a stitching-cap or plane change that is far easier to plan now.
• Series termination / source termination resistors placed in the schematic for fast single-ended nets (RGMII, parallel memory, fast GPIO). Value TBD by layout, but the footprint must exist.
• Differential pairs (USB, Ethernet, MIPI, PCIe, LVDS): correct AC coupling where the standard requires it, correct common-mode termination, correct polarity, and pairs that the connector pinout does not force to cross.
• Unused inputs tied off, not floating. Unused outputs left open. Unused op-amp sections wired as followers to a mid-rail, not left open-loop.
• Level shifting wherever two voltage domains meet — confirm direction, speed, and that the translator’s supported data rate exceeds the bus.

Connectors and the outside world

Connectors are where field failures enter.

• Pinout sanity: power and ground pins adjacent enough to carry the current; hot-plug order (ground first, then power, then signal) if the connector is ever mated live.
• ESD/EOS protection on every externally accessible pin: USB, Ethernet (plus the magnetics and Bob Smith termination), buttons, connector I/O. TVS diodes with the right stand-off and clamping voltage, placed at the connector.
• Reverse-polarity and overvoltage protection on the power input, sized for the real worst case (a field tech with a 24 V supply on a 12 V input).
• Miswire survival: what happens if the harness is plugged in shifted by one pin? On rugged products this is worth a deliberate answer.
• Test points on every rail, reset, boot strap, and key signal — see DFT.

Design for test and manufacture

• DFT: bed-of-nails or flying-probe access to rails and critical nets. A JTAG/SWD header (even if depopulated in production). A UART console broken out. A way to hold the board in reset and in each boot mode. Programming access for every programmable device, and the programming order/method noted.
• DFM: no parts on both sides that force two reflow passes unless intended; package choices the assembler can place; no 0201s where 0402 would do; fiducials present; polarity markings that survive assembly.
• First-article bring-up plan implied by the schematic: can you bring rails up one at a time? Is there a “populate R1, leave R2 off” staged power-on option?

BOM and component risk

• Lifecycle: any part NRND or single-source? Flag it now; a second source or a footprint that accepts alternates is a schematic decision.
• Ratings with margin: capacitor voltage derating (ceramics lose capacitance with DC bias — a 6.3 V X5R on a 5 V rail may be at half its rated value), resistor power, inductor saturation current at the real peak, MOSFET SOA.
• Tolerance stack-up on anything that sets a threshold, a timing, or a feedback divider.
• Passives count: every DNP is intentional and labelled; every “we’ll tune this in bring-up” has a real footprint and a starting value.

How to actually run it

• Two reviewers minimum, at least one who did not draw the schematic.
• Page by page, net by net on the critical interfaces, out loud, against the device datasheets open on the table — not a glance-through.
• Every datasheet’s “layout guidelines” and “design checklist” section read, because vendors put the expensive mistakes there.
• Track findings as a list with owners and states. The review is not done when the meeting ends; it is done when the list is closed and re-checked.
• Re-review after the fixes. Fixes introduce errors.

The trade-off

A proper schematic review on a medium-complexity board is the better part of a day for two engineers, plus the fix cycle — call it two to three engineer-days before layout even starts. It feels like a delay when the schematic “looks finished”.

What it does not do: it will not catch problems that only exist in the physical layout — coupling, plane resonance, actual trace impedance, thermal reality, mechanical fit. Those need a layout review and, ultimately, measurement on hardware. The schematic review is necessary and cheap; it is not sufficient, and treating a passed schematic review as “the hard part is over” is its own failure mode.

This page walks the whole path from photons to photons and gives the order of magnitude of each stage, so you know which term to attack.

The pipeline, stage by stage

1. Exposure (integration time)

The sensor integrates light for the exposure time. The photons that form a frame are spread across that whole window, so the effective latency contribution is roughly half the exposure time for motion (the centroid of the exposure), but the frame is not readable until the full exposure ends, so for end-to-end timing you count the full exposure time.

• Bright scene, short exposure (1–2 ms): negligible.
• Indoor / auto-exposure (8–33 ms): this is often the single largest term, and it is invisible in any software profiler.
• Low light with a 1/30 s exposure: 33 ms before anything else has happened.

Lever: cap the maximum auto-exposure time and accept more gain (noise) if latency matters more than SNR. This is an ISP/3A tuning decision, not a code change.

2. Sensor readout

The pixel array is read out row by row and streamed. Readout takes on the order of one frame period at the sensor’s current mode — a rolling shutter sensor at 60 fps takes ~16 ms to clock the whole frame out, and the bottom of the frame is genuinely ~16 ms “younger” than the top.

• Higher frame-rate modes read out faster (and usually crop or bin).
• Global shutter removes the top-to-bottom skew but not the readout transport time.
• Lever: run the sensor faster than the display rate if the SoC can take it — reading a 60 fps stream for a 30 fps display halves this term and the exposure cap becomes easier to hit.

3. MIPI CSI-2 transport

Serialised over the D-PHY/C-PHY lanes into the SoC’s CSI receiver. At any sane lane rate this is sub-millisecond per frame for typical resolutions — it is almost never the problem. It shows up only if lanes are marginal and you are getting retimed/corrupted lines that force retry or drop.

4. Receiver DMA to memory

The CSI receiver writes frames into a ring of buffers in DRAM. Two things here:

• The write itself is fast (bounded by memory bandwidth, sub-ms to low-ms).
• The number of buffers in this ring is a latency knob. More buffers = smoother under jitter, but a frame can sit in the ring for up to (buffers − 1) × frame_period before anything consumes it. Four buffers at 30 fps is up to 100 ms of potential sit time. This is the classic hidden lag.

5. ISP

Debayer, black level, lens shading, denoise, sharpening, tone mapping, colour conversion, scaling. On a hardware ISP this is a few milliseconds and often pipelined with readout. In software (libcamera soft ISP, OpenCV) it can be tens of milliseconds and steals CPU from everything else.

• 3A (auto-exposure/white-balance/focus) runs here and feeds the next frame — it adds a frame of loop latency to convergence, not to the display path, but a slow-converging AE means longer exposures for longer, which loops back to stage 1.
• Lever: use the hardware ISP path (V4L2 media controller / libcamera with the vendor pipeline handler) rather than a software fallback.

6. Application / buffer handoff

The frame becomes a dmabuf handed to whatever draws it — a Qt QVideoSink, a GStreamer appsink/glimagesink, an LVGL canvas, a Weston/Wayland client, a direct DRM/KMS plane.

• Every queue between elements is depth × frame_period of potential latency. GStreamer’s default queue sizes, a v4l2src with many buffers, a compositor that triple-buffers — each is a place frames wait.
• Zero-copy or not. If the frame is memcpy’d (or worse, uploaded to a GL texture) at each stage, that is memory-bandwidth time and CPU stalls, a few ms each and more under load. dmabuf import all the way to the display plane avoids it.
• Lever: shortest possible pipeline. A camera frame on its own DRM/KMS overlay plane, composited by the display controller, skips GPU composition entirely.

7. Composition

If the UI draws the video into a scene (overlays, HUD, controls), the GPU composites. One frame period at the render rate, plus the GPU’s own latency. Using a hardware overlay plane for the video and only compositing the UI chrome avoids putting the video through this stage.

8. Display refresh and panel response

• The scanout waits for the next vsync to start sending the new frame: 0 to one refresh period of wait (average half). At 60 Hz that is up to 16.7 ms.
• Double/triple buffering adds one or two more refresh periods depending on whether a frame misses its flip deadline.
• The panel’s own response: LCD pixel response and its internal frame buffer / overdrive processing, commonly one frame for an LCD, sometimes more for a panel with a scaler or “image enhancement” it will not let you disable.
• Lever: PAGE_FLIP synced to vsync with exactly the buffers you need (often double, not triple), and pick a panel/timing controller with a documented, low, fixed latency. Disable panel-side processing.

Adding it up

A representative indoor 30 fps preview, no tuning:

That easily reaches 150–250 ms — the “laggy” complaint — and only ~5 ms of it is anything a code profiler would show you.

The same pipeline, tuned:

• Sensor at 60 fps, AE capped at 8 ms.
• Two CSI buffers, not four.
• Hardware ISP path.
• No GStreamer queues, or leaky=downstream max-size-buffers=1.
• Video on a dedicated KMS overlay plane, UI composited separately.
• Double-buffered page flip synced to vsync, panel processing off.

lands in the 40–70 ms range, and most of what remains is exposure, readout, and one refresh period — the irreducible physics.

How to measure it

Do not trust per-stage estimates; measure glass-to-glass:

• Photodiode + LED + scope. Flash an LED in frame, detect it with a photodiode taped to the display, measure LED-on to display-brightens on the scope. This is the only number that counts.
• On-screen millisecond counter filmed with a 120–240 fps camera alongside a physical stopwatch/timer in the same shot; count frames of offset.
• Per-stage: V4L2 buffer timestamps (v4l2_buffer.timestamp), GST_DEBUG with GST_TRACERS=latency, DRM/KMS PAGE_FLIP event timestamps, and a GPIO toggle at each app-level handoff. Line them up against the glass-to-glass number to find the fat stage.

The trade-offs you are actually making

• Fewer buffers = lower latency, less tolerance to scheduling jitter. Drop a deadline with two buffers and you get a visible stutter; with four you get lag but no stutter. Pick per product — a welding HUD wants low latency, a security-review monitor wants no dropped frames.
• Shorter exposure = lower latency, more noise. You are trading SNR for responsiveness, frame by frame, in the AE tuning.
• Overlay plane = low latency, less compositing flexibility. Overlay planes have format, scaling, and count limits set by the display controller; a complex UI that must blend with the video may not fit and has to go through the GPU.
• Running the sensor faster = lower latency and easier AE, more MIPI and memory bandwidth, more power and heat. On a thermally constrained enclosure that can be the deciding constraint.

This page is about writing that budget. It is protocol- and silicon-agnostic on purpose; the numbers change per project, the structure does not.

The four numbers

1. Sample rate (f_s)

The rate at which the loop reads its inputs and updates its output. Set it from the plant, not from what the CPU can do:

• Rule of thumb: f_s between 10× and 20× the closed-loop bandwidth you need. Below 10× the phase lag from sampling eats your phase margin; far above 20× you are burning CPU and amplifying sensor noise through the derivative term for no dynamic benefit.
• For a mechanical position loop with a 50 Hz bandwidth target, that is roughly 1–2 kHz. For a motor current loop it is typically 8–20 kHz because the electrical time constant is short. For a temperature loop, 1–10 Hz is often plenty and a faster loop just wastes power.
• Write down the reasoning, not just the number. The next engineer needs to know whether 2 kHz was a plant requirement or a guess.

2. Sampling jitter (Δt_s)

The allowed variation in when the input is actually sampled, relative to the ideal period 1/f_s. This is the number most specs omit and most loops get bitten by.

Jitter matters because a control law assumes a fixed Δt. If the real interval wanders by ±15% and the code still divides by the nominal Δt in the derivative and integral terms, you have injected a disturbance proportional to the jitter and the signal slew rate. Effects:

• The I term accumulates the wrong area.
• The D term produces spikes on jittered intervals.
• At the control-bandwidth frequency, timing jitter aliases into the loop as broadband noise you cannot filter out without also hurting the response.

Budget it as a percentage of the period and as an absolute time. “≤ 2% of period or ≤ 5 µs, whichever is larger” is a typical starting point for a mid-rate loop. For a current loop synchronised to PWM, the sampling instant is usually locked to a timer/PWM trigger and an ADC hardware trigger, and the jitter budget there is tens of nanoseconds — a software-timer-driven sample cannot meet it and the budget is what tells you that up front.

Two mitigations worth stating in the budget itself:

• Timestamp every sample and feed the actual Δt into the loop maths, so jitter degrades gracefully instead of injecting noise.
• Trigger sampling in hardware (timer-to-ADC, no CPU in the path) and let the ISR only consume the result.

3. Worst-case actuation latency (L_wc)

The time from “the sampling instant” to “the new actuator command is in effect” — end to end, worst case, not typical. Its components:

L_wc = t_acq        ADC conversion + settling
     + t_dispatch   interrupt latency + scheduler to the loop task
     + t_compute    the control law, worst-case path
     + t_output     DAC/PWM update, or the bus transaction to a remote drive
     + t_actuator   the actuator's own transport lag (often the biggest term)

Rules for filling it in:

• Use worst case for every term. Interrupt latency under maximum interrupt load, t_compute with the branch that runs the anti-windup and the fault checks, bus latency including retransmission if the link allows it.
• L_wc shows up in the loop as pure dead time. Dead time destroys phase margin fast: as a guide, keep L_wc under about 1/10 of the loop period, and treat anything above 1/4 of the period as a redesign trigger.
• If the actuator is across a fieldbus, the bus cycle time and its determinism are now inside your control budget. A 1 kHz loop commanding a drive over a 1 ms-cycle bus has spent its entire latency budget on transport before any control happens. This is the calculation that decides whether the loop runs local to the drive or on a central controller.

4. Deadline-miss policy

Define what a missed deadline is and what the system does about it. “It should not happen” is not a policy.

• What counts as a miss: loop iteration N has not completed before iteration N+1’s release. Instrument it — a GPIO toggled at loop start/end on a scope, or a software counter of overruns exported to diagnostics.
• Allowed miss rate: for a soft loop, “≤ 1 in 10⁶ iterations and never two consecutive” might be fine. For a loop tied to a safety function, the answer is usually zero within the safety analysis and the response is a defined safe state, not a retry.
• The response: hold last output, ramp to a safe value, trip a fault, or extrapolate one step. Each has failure modes — holding last output during a fast transient can be worse than a brief zero. State the choice and why.
• Escalation: what happens on the 2nd, 10th, 100th consecutive miss.

What the budget lets you decide without arguing

Once the four numbers exist, these stop being opinions:

Measuring against it

A budget you cannot measure is a wish. The standard instrumentation:

• GPIO + scope/logic analyser: toggle a pin at ISR entry, at loop-math start, at output write. Persistence mode on the scope shows the jitter envelope directly. This is the ground truth; trust it over any software timestamp.
• Cycle counter (DWT->CYCCNT on Cortex-M, PMCCNTR / perf on Cortex-A) around the compute path, logging min/max/histogram, not just mean.
• Overrun counter in the loop, exported to the same diagnostics channel as everything else so field units report it.
• Soak under worst-case load: every interrupt source firing, the comms stack saturated, the file system busy, cache cold. The typical case is not the number in the budget.

Hold the measurement for long enough to see the tail. Latency distributions in real systems have long tails driven by rare cache/TLB/bus-contention events, and the 99.99th percentile is often 3–10× the median. The budget is about the tail, so the measurement has to reach it.

The honest trade-off

Writing this budget costs a day or two of analysis and a negotiation with whoever owns the plant requirements, before any loop code exists. On a schedule under pressure that day is tempting to skip, and the loop will usually “work” on the bench without it.

What you lose by skipping it is the ability to say why it works, and the ability to catch — at design time rather than during integration — the cases where the chosen bus or OS cannot meet the timing. Those cases are expensive exactly in proportion to how late they are found. The budget moves that discovery to the cheapest possible point.

A tighter budget is not free either. Driving jitter to nanoseconds means hardware triggering, a shielded core, and no shared bus — real BOM and integration cost. The budget should be as loose as the plant genuinely allows, and no looser.

This page is the checklist we hold our own BSP deliveries to. It is deliberately about artefacts and their properties, not about a particular board.

The one property that matters: bit-for-bit rebuildability

Everything below is in service of a single test. Take the delivery, put it on a machine that has never seen the project, follow the written steps, and get an image whose package manifest matches the one that shipped. If that test passes, the BSP is maintainable. If it does not, you have bought a binary with source attached, not a BSP.

Yocto gives you the machinery for this — BB_HASHSERVE, hash-equivalence, buildhistory, reproducible-builds class — but none of it is on by a default that survives a vendor change. It has to be configured, and the configuration is part of the deliverable.

1. A pinned, self-contained source manifest

• A repo manifest or a kas file that pins every layer to a commit SHA, not a branch. honister, kirkstone, scarthgap — a branch name is a moving target. kirkstone today is not kirkstone from the release date.
• The BitBake and OE-Core revision pinned in the same file.
• No layer fetched from a URL the client does not control. If a layer lives only on a vendor’s GitLab, it is a single point of failure with someone else’s uptime. Vendored into the client’s own Git, with the upstream URL and SHA recorded in the commit message so the provenance is not lost.
• The conf/bblayers.conf BBLAYERS order documented, because layer priority changes which .bbappend wins.

The test: kas checkout (or repo sync) on an air-gapped mirror reproduces the exact tree. No “then update meta-freescale to the tip”.

2. Your own layer, and only your changes in it

There should be exactly one layer that contains the project’s work — meta-<project> — and it should be the only layer with local commits. Every change to a BSP or upstream recipe lives there as a .bbappend or a versioned recipe copy, never as an edit to meta-ti, meta-freescale, or poky.

Why this is a hand-over issue and not a style preference: when the client later moves from kirkstone to the next LTS, the migration work is reviewing one layer. If changes are smeared across five vendor layers, the migration is archaeology, and the estimate for it triples.

What belongs in meta-<project>:

• The machine .conf (or a .bbappend to the vendor’s) with every deviation commented — why PREFERRED_VERSION_linux-* is pinned, why a MACHINE_FEATURE was removed.
• The image recipe(s). One production image, one development image, and the delta between them stated explicitly (dev adds debug-tweaks, openssh-sftp, gdbserver — and production must be verified not to).
• The distro config if the project defines its own DISTRO. It usually should: inheriting poky and overriding twelve variables in local.conf means the config only exists on the machine that has that local.conf.

3. local.conf is not part of the delivery — the distro config is

local.conf is per-developer scratch. Anything load-bearing that lives there will be lost. The hand-over must move every meaningful setting into version control:

• DISTRO_FEATURES / DISTRO_FEATURES_remove — particularly systemd vs sysvinit, wayland/x11, pam, usrmerge.
• IMAGE_FSTYPES and how they map to what the factory actually flashes (wic.gz, wic.bmap, a .swu for SWUpdate).
• EXTRA_IMAGE_FEATURES, IMAGE_INSTALL:append.
• The PACKAGE_CLASSES choice (package_rpm/ipk/deb) — this affects the on-target update mechanism and cannot be changed casually later.
• Any PREMIRRORS / SSTATE_MIRRORS pointing at internal infrastructure.

4. The kernel: a defconfig fragment and a reason for every line

A kernel handed over as a 6,000-line .config is not maintainable, because nobody can tell an essential setting from an accident of make oldconfig.

• defconfig plus fragments, wired through KERNEL_CONFIG_FRAGMENTS or a linux-*.bbappend. The fragment is small and every line is intentional.
• A written rationale for the non-obvious ones: which CONFIG_ enables the Ethernet PHY, which sets the RT behaviour, which was needed for a USB gadget mode, which disables an unused subsystem to cut attack surface and boot time.
• The kernel provenance: mainline version, the vendor SoC tree it is based on, the patch stack applied on top — as a quilt series or Git history, not a single squashed diff. When a CVE lands, someone needs to know whether the tree already carries the fix.
• Out-of-tree modules identified, with their licence and their source. An out-of-tree Wi-Fi driver with no upstream is a maintenance liability that should be named in the hand-over, not discovered later.

5. Device tree: the board’s hardware description, reviewed

The device tree is where “the BSP works” and “the BSP is correct” diverge. A node can be missing and the board still boots.

• The board .dts in meta-<project>, including via .dtsi, not patched into the vendor’s file in place.
• Every pinmux group traceable to the schematic net name. A comment linking MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 to the actual card-detect net saves the next engineer an afternoon with a multimeter.
• Regulators modelled properly — regulator-always-on, regulator-boot-on and the supply chain to each peripheral. Half of “the peripheral randomly does not enumerate” bugs are a missing or lazy regulator description.
• Overlays, if used, with the base-plus-overlay combination that the running system actually uses documented. Applied by U-Boot or by the kernel — state which.

6. U-Boot: the config, the environment, and the boot flow

• The U-Boot defconfig and any board patches, same discipline as the kernel.
• The boot environment as a file, not as whatever is currently in the SPI flash of the one golden board. The boot.cmd/boot.scr or the extlinux config, in version control.
• The boot flow written out: ROM → SPL → U-Boot proper → kernel → init, with where each stage lives (eMMC boot partition, offset, GPT) and what the fallback path is if the primary kernel does not come up.
• If secure boot is in play: which keys sign what, where the public keys are fused or stored, and — critically — a documented recovery path for a board whose signature check fails. A secure-boot BSP with no recovery story is a brick generator.

7. The signed image and its bill of materials

• The exact image that was released, plus its signature and the public key to verify it.
• buildhistory output committed for that build: the package list with versions, image size, dependency graph, and the diff against the previous release. This is what makes “what changed between v1.2 and v1.3” answerable in minutes.
• An SBOM — Yocto emits SPDX 2.2 JSON via create-spdx — covering every package in the image with its version and licence. Increasingly this is a contractual and regulatory requirement (the EU Cyber Resilience Act among them), and it is far cheaper to generate at build time than to reconstruct.
• The licence manifest (license.manifest, deploy/licenses/) and the sources for anything under a copyleft licence, or a working bitbake -c archiver configuration that regenerates them.

8. The build environment itself

“Works on my machine” is not a hand-over. Pin the host too:

• A container (the CROPS base or a project Dockerfile) that fixes the host distro, the essential host packages, Python, and locale. Yocto is sensitive to host GCC and host Python; a 2024 build host and a 2027 build host are not equivalent.
• The exact bitbake invocation, target names, and any BB_ENV_PASSTHROUGH additions.
• Expected build resources: disk for TMPDIR and SSTATE_DIR, RAM, rough wall time on a stated machine — so the client can size CI.
• A populated sstate and downloads mirror, or instructions to build one. Without it the first rebuild pulls hundreds of source archives from the internet, and some of those URLs will be dead. An offline DL_DIR archive is the single most valuable non-obvious artefact in the box.

9. Documentation that is task-shaped

Not a wiki dump. Five documents, each answering a question someone will actually ask:

1. Build it — from empty machine to flashable image, copy-paste commands.
2. Flash it — factory path and field path, including the recovery/USB-download procedure for a bricked board.
3. Change the kernel config / add a package / bump a recipe — the routine maintenance loop.
4. Cut a release — versioning, signing, what gets tagged, what gets archived.
5. Known issues and deferred work — the honest list. Every BSP has one; a hand-over without it just means the client finds them the hard way.

What this costs

Producing this is real work — on the order of one to two engineer-weeks on top of the BSP itself, most of it in items 1, 7, and 8. It is worth being explicit about that in a statement of work rather than discovering it at the end. The payoff is entirely deferred: it shows up the first time the client rebuilds without the original team, and it is the difference between an afternoon and a re-engagement.

The trade-off we make deliberately: we do not hand over a build that tracks upstream branches, even though that would look more “up to date” on delivery day. A pinned build is frozen and will drift out of security currency until someone deliberately bumps it — that is the cost. It is the right cost, because a build that silently changes under the client is not a build they own.