Learn Overview¶
Use Learn to make subsystem and architecture decisions before they become hard to reverse in firmware or hardware. These pages explain how SF32 building blocks fit together, including when a general-purpose CPU should hand work to a graphics engine, wireless controller, AI accelerator, or other dedicated hardware. They also identify what to validate when graphics, wireless, audio, AI, memory, and power must coexist in one product.
Use Getting Started for the first successful board run, Tutorials for guided exercises, Develop for software workflows and examples, and the SF32 Family for part selection and production design.
Start with Your Design Question¶
| If you need to… | Start here | Then explore |
|---|---|---|
| Understand the processor, memory, and hardware-offload model | Architecture Overview | STAR-MC1, PSRAM vs. Other Embedded Memory Types, and PTM when they are relevant to the selected device. |
| Build a display UI or choose an asset/framebuffer strategy | Graphics Overview | Display Controller, ePicasso, eZip, and TurboPixel for the relevant display, rendering, and compression decisions. |
| Connect a phone, accessory, or audio device | Bluetooth Overview | Bluetooth Processor for controller/application boundaries, then Bluetooth PAN when the product needs phone-backed IP transport. |
| Add on-device inference | AI Overview | AI Accelerator, then the memory, latency, and power checks required by the model and pipeline. |
| Capture, play, or process sound | Audio Overview | Audio Server and Buffering, plus Bluetooth guidance when the product streams audio or carries calls wirelessly. |
| Meet a battery-life target | Low-Power Overview | Power Measurement and Validation, then the Bluetooth, graphics, audio, and AI pages for each subsystem's power behavior. |
Use the Pages Together¶
Most real products cross several groups. A wearable with a display, BLE, microphone, and battery budget should not treat those as isolated features: display refresh affects memory traffic and active time; Bluetooth scheduling affects wake frequency; audio and AI affect buffers and latency; each decision changes the power budget.
Use the pages as a design loop:
- Start from the dominant product requirement and the selected device. Confirm that the required display, Bluetooth, AI, audio, memory, and low-power capabilities are actually documented for that device.
- Set the processor and memory boundaries before application integration. Define the working-set, framebuffer, model, and audio-buffer placement; keep latency-critical work in the appropriate low-latency memory; and use dedicated hardware only where its capability and integration constraints fit the product.
- Follow the overview for the dominant subsystem into its detailed implementation page. Treat cross-links to Bluetooth, memory, and low power as design dependencies, not optional background reading.
- Validate the complete combination on the intended hardware. Use the workflows in Develop and the measurements called out in the relevant Learn pages to test functional behavior, latency, bandwidth, RF behavior, and power together.
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.