Plan a Product¶
This guide maps the decisions needed to take an SF32 concept from initial requirements through validation to a production-ready design plan. Follow the stages in order while the chip, module, development board, software stack, and manufacturing approach are still undecided.
Product Planning Path¶
| Stage | Key decision | Start here | Exit criterion |
|---|---|---|---|
| 1. Define requirements | Wireless device role, display, audio, AI, storage, power supply and consumption budget, package area, and target product lifetime. | SF32 Family | A ranked shortlist with explicit must-have interfaces and constraints. |
| 2. Select integration | A custom PCB with the chip mounted directly, a module plus carrier board, or a development board for early validation. | SF32 Product Selector | A preferred device and integration approach, plus the closest available board or module. |
| 3. Prove the software baseline | Toolchain, flash flow, serial output, and one known-good example on the selected or closest board. | Getting Started | A repeatable build-and-flash process with a captured console log. |
| 4. Validate product risks | Product-specific behavior of the display, Bluetooth, audio, AI, and storage, plus the power-supply path and consumption profile. | Tutorials, Learn, and Develop | Measured results for the subsystems that drive cost, power, or schedule risk. |
| 5. Freeze the implementation plan | Schematic, layout, memory/partition plan, BOM, test approach, update/recovery behavior, and manufacturing assumptions. | Design for Production | Reviewed design package and an explicit list of remaining validation items. |
Do Not Skip the Board Validation Loop¶
A family comparison and a successful compile are not enough to select a production device. Validate the closest board before freezing hardware, then record the board name, SDK version, SDK example used, measured behavior, and differences from the intended product. If the final product uses a new display, storage part, battery path, antenna, or module carrier, treat each as a separate validation item.
For a complete worked path, choose the closest Reference Design after the initial hardware and software baseline is established.
Handoff Checklist¶
- The selected part or module meets the product's interface, memory, package, power-supply, and power-consumption constraints.
- A supported board or deliberate custom-hardware validation plan exists.
- The software path and its maturity are accepted by the product team.
- Recovery, OTA/DFU, logging, and factory-programming needs are defined before partition and BOM decisions are frozen.
- The correct hardware design guide, checklist, AVL, and EDA library have been identified.
Auto-generated content
This page was compiled/drafted without an existing source document. Verify technical claims against SiFli's official documentation before relying on them.
Last updated: