Design reviews work best when the author is explicit about the decision that needs feedback. Useful review requests usually include: The system goal and the main constraintsThe block diagram or relevant schematic excerptThe interfaces, loads, rails, or timing targets involvedThe tradeoff you are uns...

If you spot a broken link, outdated article detail, confusing page flow, or a topic you would like covered in more depth, post it here. Include the exact page URLQuote the sentence, figure, or section that looks wrongDescribe the expected correction or missing topicSay whether the issue is technical...

Modern C++ can improve safety and clarity in embedded systems, but only if the team understands what the generated code is doing and where the boundaries are. Use stronger types where they remove ambiguityPrefer compile-time checks where they simplify runtime codeAvoid abstractions that hide timing,...

If your issue lives in a desktop or lab-side tool, include the environment details up front. Distro or OS versionQt version and build systemCompiler, package manager, and deployment targetInstrument or device interfaces in useWhether the failure is UI, timing, protocol, packaging, or deploymentThrea...

Build and CI failures are usually systematic, which is good news if the thread starts with disciplined information. Toolchain version and target tripletGenerator, CMake version, and exact configure commandWhether the failure is compile, link, package, or deployWhether the issue reproduces locally an...

When a board looks dead, do not start by rewriting firmware and do not start by swapping random parts. Start by proving the board is alive enough to deserve software attention. Measure every primary rail and note sequencingCheck reset, enable, and power-good signalsConfirm oscillators and clock outp...

A lot of bad debug decisions come from bad measurements, not bad circuits. Use the shortest practical ground connectionKnow when probe capacitance is changing the signalDo not trust auto scale or auto trigger without thinkingMatch bandwidth limit and sample depth to the problemUse differential probi...

This thread is for the recurring embedded C questions that are easy to answer badly and expensive to answer loosely. What volatile does and does not guaranteeWhy bitfields are often the wrong abstraction for registersHow to keep ISR work bounded and observableWhat belongs in startup code and what sh...

This thread collects the questions that come up over and over in embedded firmware architecture reviews. When is bare metal still the better choice?When does an RTOS reduce risk instead of adding complexity?How should watchdog servicing be structured?Where should retry logic, state machines, and fau...

Communication bugs are usually not mysterious. They are usually configuration mistakes, level mismatches, timing errors, termination problems, or bad assumptions about who owns the bus. Before posting, work through this checklist: Confirm voltage levels, pull-ups, termination, and pin muxingCapture ...

Analog problems often look complicated long before they actually are. Start by checking the quiet basics. Are your references, rails, and grounds doing what you think they are?Did you budget source impedance, bias current, settling time, and ADC acquisition time?Is the noise really analog, or is it ...

If you want layout feedback, this is the baseline information to include so the review can stay technical instead of generic. Layer stackup and board thicknessCritical nets, edge rates, and interface speedsConnector locations and cable environmentPower tree and current levelsAreas you already suspec...

If you are starting a new MCU or SoC thread, post enough context that someone else can reproduce your failure mode instead of guessing blindly. A good first post usually includes the exact device, board or custom hardware revision, toolchain version, debugger, clock source, power rails, and whether ...