Develop Overview¶
This section is for firmware developers who have moved past the first hello_world run and need to build, flash, debug, update, and ship software on SF32 devices.
Use Getting Started for the first successful board run. Use Tutorials for guided hands-on learning, the SF32 Family to choose chips, modules, and dev kits, and Learn for conceptual guides. Use Develop when you need the working details: platform maturity, toolchains, board names, flash flows, examples, and firmware architecture.
For the current board-by-platform status, use the canonical Software Support Matrix. It is the shared support reference for Getting Started and Develop; platform pages provide the detailed setup and limitations.
Choose a Development Path¶
| Path | Best for | Status |
|---|---|---|
| SiFli-SDK | Reference SF32 firmware, RT-Thread, Bluetooth, graphics, audio, storage, power, and production board support. | Official SiFli path. |
| CodeKit | SiFli-SDK development inside VS Code. | Official SiFli extension. |
| Zephyr | Zephyr APIs, devicetree, downstream board work, and portable RTOS experiments. | OpenSiFli downstream work exists for SF32LB52 DevKit LCD. |
| Arduino | Sketches and quick tests through Arduino IDE or Arduino CLI. | OpenSiFli beta ArduinoCore-zephyr package exists for SF32LB52 DevKit LCD. |
| MicroPython | REPL-driven scripting and quick experiments. | No official SF32 MicroPython flow found yet. |
| Rust | Embedded Rust exploration with sifli-hal / sifli-pac. |
Community / work-in-progress. |
Recommended Default¶
Start with SiFli-SDK unless you have a clear reason not to. It is the vendor reference path and the best place to validate boards, flash flows, serial output, and hardware features before you evaluate another ecosystem.
Move to another platform when the tradeoff is worth it:
| If you need | Consider |
|---|---|
| Official SF32 feature coverage and production firmware | SiFli-SDK |
| SiFli-SDK with a guided editor workflow | CodeKit |
| Zephyr devicetree, Kconfig, and RTOS APIs | Zephyr downstream |
| Arduino IDE sketches on SF32LB52 DevKit LCD | ArduinoCore-zephyr beta |
| Interactive Python scripting | Wait for official MicroPython artifacts |
| Embedded Rust experimentation | sifli-rs, with production caution |
Develop Section Map¶
| Area | Use it when |
|---|---|
| Software Paths | You need framework-specific setup, build, flash, and limitations. |
| Tools | You need flashing, logs, crash analysis, image tooling, RF/audio tools, or factory utilities. |
| Firmware Topics | You need boot layout, partitions, OTA, USB, power, logging, or crash-analysis guidance. |
| Examples | You need a known SDK or Zephyr sample to start from. |
Recommended Progression¶
- Validate the board with SiFli-SDK.
- Decide whether the product should stay on SiFli-SDK, move to Zephyr, use Arduino for prototyping, or wait for a more mature path.
- Learn the flash and monitor tools before changing application code.
- Understand the partition table before touching OTA, filesystem, or bootloader behavior.
- Start product features from a close example, not from a blank project.
- Record the exact board name, SDK/package version, flash command, and serial port that worked.
What Good Looks Like¶
Before a platform path is ready for a product decision, you should be able to answer:
- Which exact board name or FQBN is used?
- Which release, branch, package version, or commit was tested?
- Which command builds the firmware?
- Which command flashes the firmware?
- Which serial port and baud rate show logs?
- Which examples are known to run on the target board?
- Which peripherals are supported, experimental, or missing?
- How do you recover a board after a failed flash?
If any answer is missing, treat that platform as exploratory until the gap is closed.
Source Policy¶
Concrete commands, package names, board names, baud rates, and runner details in this section come from public SiFli/OpenSiFli materials where available. If a page recommends work that SiFli still needs to finish, it says so in a SiFli Team Should Add section or in Documentation Assumptions and Open Items.
Accuracy Notes¶
This section avoids presenting undocumented work as finished product support. Where a path is beta, downstream-only, or not found, the page says so directly. The companion page Documentation Assumptions and Open Items records items that need SiFli confirmation before they should be treated as official user guidance.
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.