Firmware / software engineering · process deck

Firmware / software process deck

From business analysis and requirements to design documents, implementation, virtual target testing, and real MCU/SoC integration.

Slide 1 of 7 14%

Slide 01 · Route

Firmware / software workflow

Business analysis → requirements → design description → protocols → implementation → virtual target tests → real target integration.

C/C++PythonMATLABSimulinkQEMURenodeDocker

Embedded controller boards mounted on a laboratory test fixture with power supply and wiring — Lab evidenceEmbedded workflow on a real benchRequirements, interfaces, code, and tests stay linked to the target setup.

Slide 02 · Analysis

Business analysis and requirements

We can start before the client has a complete specification. We clarify the goal, constraints, interfaces, risks, and expected behavior.

Business contextUse case, operating scenario, user/system value.

RequirementsFunctions, limits, timing, target constraints, acceptance criteria.

VariantsArchitecture options, toolchain options, implementation path.

Engineering team validating a mobile robotic platform on a laboratory test track — Gate AScope is clearUse cases, constraints, interfaces, and acceptance criteria are fixed before implementation.

Slide 03 · Documentation

Design description

Documentation is the engineering contract for implementation, review, testing, and future porting.

ArchitectureComponents, states, data flow, error handling.

InterfacesSignals, messages, units, ranges, timing.

Testing basisAcceptance criteria, test cases, expected results.

Green PCB with connector rows prepared for engineering validation — ArtifactDesign descriptionThe document connects architecture, interfaces, expected behavior, and test evidence.

Slide 04 · Documentation

Communication protocol and cooperation rules

We describe how modules communicate before code is written or generated.

ProtocolFrame format, fields, IDs, CRC, byte order, update rate.

CooperationProducer/consumer, acknowledgements, retries, faults.

TraceabilityRequirement → design item → code → test.

Small PCB with ribbon cable used as an embedded interface and signal harness — Gate BProtocol before codeFrame format, signal naming, byte order, retries, and faults are agreed before coding.

Slide 05 · Implementation

Implementation path

We select the fastest controlled route: write code manually, generate parts from documents, or use MATLAB/Simulink for portability and scaling.

C/C++ for embedded logic, drivers, protocol handling, and target integration.
Python for prototypes, tools, test scripts, data checks, and automation.
AI-assisted generation for scaffolds, parsers, serializers, tests, and adapters from reviewed documents.
MATLAB/Simulink for models, control logic, generated code, and easier adaptation across variants.

Controller board connected to a laptop and test instruments during firmware development — ImplementationCode, models, tools, reviewC/C++, Python, MATLAB/Simulink, and generated artefacts are checked against the reviewed contract.

Slide 06 · Test

Virtual target integration

Before real hardware, we run integration and tests in reproducible environments.

DockerRepeatable toolchain, build, scripts, and demos.

QEMUBoard-level checks and early software integration.

RenodeMCU/SoC simulation, peripherals, and multi-node scenarios.

Mobile robot platform tested on a marked laboratory track with a laptop nearby — Virtual-firstRepeatable integration loopDocker/QEMU/Renode checks reduce risk before the real target blocks the schedule.

Slide 07 · Target

Real MCU / SoC integration and handover

After virtual fixes, we move to the real target and close the hardware-firmware loop.

Bring-upBuild, flash, debug, logging, diagnostics.

HW/FW testsProtocol, timing, stability, fault handling, regression.

HandoverCode, models, Docker setup, design docs, test evidence.

Engineer holding a populated PCB for real target bring-up and validation — Gate CReady for client reviewRunnability, logs, test evidence, source code, models, and handover package are aligned.

Contact

Send a short firmware / software context

Useful inputs: business goal, target hardware, existing requirements, protocols, signal/interface tables, timing limits, models/code, logs, and expected behavior.

solution@contimech.org