Develop Overview¶
Develop turns a working SF32 board into maintainable product firmware. Use it after the first successful hello_world to select a board configuration, build and flash repeatably, adapt a close example, integrate product features, diagnose failures, and plan updates and recovery.
Use Getting Started for the first board run, SF32 Products to select the device and development board, Hardware for schematics and production hardware, and Learn for architectural background. Use this section when you need the engineering workflow and task-specific implementation guidance.
SiFli-Solution
SiFli-Solution is a separate SiFli software package that μForge.io does not currently document. The guidance here is limited to SiFli-SDK and the community paths listed below. If your product needs a more complete display-device solution, consult the official SiFli Solution Documentation and engage SiFli directly. A complex product using this route may need deep, direct SiFli involvement.
Establish a SiFli-SDK Baseline¶
SiFli-SDK is SiFli's official, RT-Thread-based software package and the reference development path for SF32 firmware. Start there unless you have a deliberate reason to evaluate another ecosystem: it provides the broadest documented baseline for board support, Bluetooth, graphics, audio, storage, power management, and production work.
Before building product features, establish and record one reproducible baseline:
- Select the exact SDK board configuration in Board Configuration.
- Run the Build, Flash, Monitor loop successfully.
- Save the SDK release or commit, board name, build command, flash command, serial settings, and a boot log.
- Start from the closest example, especially one that already exercises the product's hardest subsystem.
The resulting record is the reference point for later application changes, board ports, test failures, and field recovery.
Find Guidance by Task¶
| Task | Start here | Then use |
|---|---|---|
| Build, download, and read serial output every day | Build, Flash, Monitor | Tools for scripted download, trace, and crash utilities. |
| Match firmware to a development board, module, or custom hardware | Board Configuration | The relevant Hardware guide and the closest board-specific example. |
| Reuse a driver or middleware layer across projects | Components and sf_pkg |
A minimal example and a documented configuration boundary. |
| Implement a concrete peripheral or subsystem | SiFli-SDK App Notes | The linked official SDK usage guide for exact APIs, configuration symbols, and commands. |
| Start product work from code that already runs | Examples | The matching board configuration, then test after each change. |
| Diagnose a failure or collect product evidence | Debugging and Diagnostics | Logging and Crash Analysis. |
| Change boot layout, storage, updates, USB, or power behavior | Firmware Topics | The relevant partition, update, USB, power, or logging topic before changing code. |
SiFli-SDK Application Notes¶
The application-note collection is organized by integration task rather than SDK catalogue order. Begin with the immediate subsystem. Before adapting a configuration or command, check the stated chip-family scope, board configuration, SDK release, and hardware prerequisites.
| Engineering area | Application-note starting point |
|---|---|
| Analog and sensors | Sample with GPADC · Integrate and Read Sensors |
| Storage and graphics assets | Use External Flash · Compress Graphics Assets with EZIP |
| Reliability, power, and debugging | Configure the Watchdog · Configure and Measure Low Power · Capture Logs and Analyze Crashes |
| RF and Bluetooth validation | Run SiFli SDK RF Tests · Run Bluetooth Signaling Tests · Run Bluetooth Single-Item RF Tests |
Navigate the Develop Section¶
| Area | Purpose |
|---|---|
| SiFli-SDK | Establish the supported reference workflow: configuration, build, flashing, reusable components, and diagnostics. |
| SiFli-SDK App Notes | Apply the SDK to a focused task such as ADC, sensors, external Flash, low power, diagnostics, RF, or Bluetooth testing. |
| Examples | Select and adapt a working implementation for the exact board and hardest product subsystem. |
| Tools | Choose download, monitor, trace, crash, asset, and production tools for the workflow. |
| Firmware Topics | Make cross-cutting product decisions about partitions, OTA/DFU, USB, power management, and diagnostic evidence. |
| Experimental / Community | Evaluate Zephyr, Arduino, MicroPython, or Rust with the scope and maturity limits stated on each page. |
Evaluate Community Paths Deliberately¶
The Experimental / Community group is for teams with a reason to work beyond the reference SDK path. It does not imply equivalent production support.
| Path | Consider it when | Treat it as |
|---|---|---|
| Zephyr | You need Zephyr APIs, devicetree, Kconfig, or downstream board work. | A downstream, board-specific evaluation path. |
| Arduino | You need sketches or a quick peripheral prototype on its supported board. | A beta, board-scoped path. |
| MicroPython | You are assessing future scripting support. | A status page until a reproducible public port exists. |
| Rust | You can evaluate HAL/PAC work and contribute upstream fixes. | A community work-in-progress path. |
Before committing a product to one of these paths, validate every required peripheral, Flash layout, debug method, and recovery procedure on the exact board. Keep the tested revision, configuration, commands, and results with the product source.
Product-Ready Development Evidence¶
Before treating a firmware path as product-ready, make sure you can answer:
- Which chip, board or custom-hardware revision, and configuration were tested?
- Which SDK, package, branch, or commit produced the firmware?
- Which build, flash, monitoring, and full-recovery commands work?
- Which example or test proves each required peripheral and product subsystem?
- Which partition layout, update behavior, power target, and crash-decoding path have been validated?
If an answer is missing, the work may still be a useful prototype, but it is not yet a repeatable product baseline.