English is currently available.
Engineers Gossips DISCUSSION
Modern embedded projects can combine MCU firmware, Linux applications, machine-learning models and several libraries. Keeping only the source folder may no longer be enough to rebuild a working system.
What should a small team archive at each hardware release? Consider a device with a custom PCB and two cooperating processors. How would you link the manufactured board revision to the firmware and model that were actually tested?
Start with a release manifest containing the board revision, source commit, compiler versions, dependency lock files, build options and generated binary hashes. Preserve the linker map and programming configuration too. A binary hash identifies an artifact; it does not explain how to rebuild it. Keeping both the inputs and final artifacts makes later investigation much easier.
For the hardware, include the schematic, layout, project-specific libraries, BOM with manufacturer part numbers and approved substitutions, and the manufacturing package actually submitted. An updated online library can change a footprint without changing your source code. Keep calibration data and serial-specific settings separate from the common firmware image, with a documented method for applying them.
For a two-processor design, version the communication protocol and record supported firmware pairs. Archive the model file, preprocessing parameters and representative validation inputs, subject to the dataset's permissions. A model replacement can change timing and memory use even when its API is unchanged. A useful release test starts from a clean environment and rebuilds, programs and exercises one complete device.
