Entwicklungsübersicht¶
Dieser Bereich zeigt, wie Sie aus einem funktionierenden SF32-Board wartbare Produkt-Firmware entwickeln. Nutzen Sie ihn nach dem ersten erfolgreichen hello_world, um die passende Board-Konfiguration auszuwählen, Build und Flashen reproduzierbar durchzuführen, ein geeignetes Beispiel anzupassen, Produktfunktionen zu integrieren, Fehler zu diagnostizieren und Updates sowie Wiederherstellungswege zu planen.
Nutzen Sie Erste Schritte für die erste erfolgreiche Inbetriebnahme eines Entwicklungsboards, SF32-Produkte zur Auswahl von Chip und Entwicklungsboard, Hardware für Schaltpläne und Serienhardware sowie Lernen für Hintergrundwissen zur Architektur. In diesem Abschnitt finden Sie den technischen Arbeitsablauf und konkrete Umsetzungshinweise für einzelne Aufgaben.
SiFli-Solution
SiFli-Solution ist ein separates Softwarepaket von SiFli, das μForge.io derzeit nicht dokumentiert. Die Hinweise hier beschränken sich auf SiFli-SDK und die unten aufgeführten Community-Pfade. Benötigt Ihr Produkt eine umfassendere Lösung für Displaygeräte, lesen Sie die offizielle Dokumentation zu SiFli Solution und wenden Sie sich direkt an SiFli. Bei einem komplexen Produkt kann dieser Entwicklungsweg eine enge, direkte Zusammenarbeit mit SiFli erfordern.
Eine SiFli-SDK-Referenzkonfiguration einrichten¶
SiFli-SDK ist SiFlis offizielles, auf RT-Thread basierendes Softwarepaket und der Referenzpfad für die SF32-Firmwareentwicklung. Beginnen Sie damit, sofern kein konkreter Grund für die Evaluierung eines anderen Ökosystems spricht: Für Board-Unterstützung, Bluetooth, Grafik, Audio, Speicher, Energiemanagement und Produktionsabläufe bietet es die umfassendste dokumentierte Referenzkonfiguration.
Bevor Sie Produktfunktionen entwickeln, richten Sie eine reproduzierbare Referenzkonfiguration ein und dokumentieren Sie sie:
- Wählen Sie unter Board-Konfiguration die exakt passende SDK-Board-Konfiguration.
- Führen Sie den Ablauf Bauen, Flashen und Überwachen der seriellen Ausgabe erfolgreich aus.
- Dokumentieren Sie SDK-Version oder Commit, Boardnamen, Build- und Flash-Befehle, serielle Einstellungen und ein Startprotokoll.
- Beginnen Sie mit dem nächstliegenden Beispiel, idealerweise mit einem Beispiel, das bereits das anspruchsvollste Subsystem des Produkts nutzt.
Die so festgehaltenen Angaben sind der Bezugspunkt für spätere Änderungen an der Anwendung, Board-Portierungen, fehlgeschlagene Tests und die Wiederherstellung im Feld.
Anleitung nach Aufgabe finden¶
| Aufgabe | Hier beginnen | Danach verwenden |
|---|---|---|
| Firmware bauen und flashen; serielle Ausgabe prüfen | Bauen, Flashen und Überwachen der seriellen Ausgabe | Werkzeuge für skriptgesteuertes Flashen, Trace und Absturzdiagnose. |
| Firmware an ein Entwicklungsboard, Modul oder eine eigene Hardware anpassen | Board-Konfiguration | Der passende Hardware-Leitfaden und das nächstliegende boardspezifische Beispiel. |
| Einen Treiber oder eine Middleware-Schicht in mehreren Projekten wiederverwenden | Komponenten und sf_pkg |
Ein minimales Beispiel und eine dokumentierte Grenze der Konfigurierbarkeit. |
| Eine konkrete Peripherie oder ein Subsystem implementieren | SDK-Anwendungshinweise | Der verlinkte offizielle SDK-Leitfaden mit den genauen APIs, Konfigurationssymbolen und Befehlen. |
| Produktarbeit mit bereits lauffähigem Code beginnen | Beispiele | Die passende Board-Konfiguration, dann nach jeder Änderung testen. |
| Einen Fehler diagnostizieren oder Produktnachweise sammeln | Fehlersuche und Diagnose | Protokollierung und Absturzanalyse. |
| Boot-Layout, Speicher, Updates, USB oder Energieverhalten ändern | Firmware-Themen | Das relevante Thema zu Partitionen, Updates, USB, Energie oder Protokollierung, bevor Code geändert wird. |
SiFli-SDK-Anwendungshinweise¶
Die Anwendungshinweise sind nach Integrationsaufgabe statt nach der Reihenfolge des SDK-Katalogs geordnet. Beginnen Sie mit dem unmittelbar relevanten Subsystem. Prüfen Sie vor dem Anpassen einer Konfiguration oder eines Befehls den angegebenen Geltungsbereich der Chipfamilie, die Board-Konfiguration, das SDK-Release und die Hardwarevoraussetzungen.
| Technischer Bereich | Passender Anwendungshinweis |
|---|---|
| Analog und Sensoren | Messwerte mit GPADC erfassen · Sensoren integrieren und auslesen |
| Speicher und Grafikressourcen | Externen Flash verwenden · Grafikressourcen mit EZIP komprimieren |
| Zuverlässigkeit, Energie und Fehlerdiagnose | Watchdog konfigurieren · Energiesparfunktionen konfigurieren und messen · Protokolle erfassen und Abstürze analysieren |
| RF- und Bluetooth-Validierung | RF-Tests mit SiFli-SDK durchführen · Bluetooth-Signalisierungstests durchführen · Bluetooth-RF-Einzeltests durchführen |
Im Entwicklungsbereich navigieren¶
| Bereich | Zweck |
|---|---|
| SiFli-SDK | Den unterstützten Referenzablauf einrichten: Konfiguration, Build, Flashen, wiederverwendbare Komponenten und Diagnose. |
| SDK-Anwendungshinweise | Das SDK für eine konkrete Aufgabe nutzen, etwa ADC, Sensoren, externen Flash, Energiesparfunktionen, Diagnose sowie RF- und Bluetooth-Tests. |
| Beispiele | Eine funktionierende Implementierung für das konkrete Board und das anspruchsvollste Produkt-Subsystem auswählen und anpassen. |
| Werkzeuge | Werkzeuge für Download, Überwachung, Trace, Absturzdiagnose, Ressourcenaufbereitung und Fertigung auswählen. |
| Firmware-Themen | Querschnittliche Produktentscheidungen zu Partitionen, OTA/DFU, USB, Energiemanagement und Diagnosebelegen treffen. |
| Experimentell / Community | Zephyr, Arduino, MicroPython oder Rust im Rahmen des auf jeder Seite beschriebenen Umfangs und Reifegrads evaluieren. |
Community-Pfade bewusst evaluieren¶
Die Gruppe Experimentell / Community richtet sich an Teams, die aus einem bestimmten Grund über den Referenzpfad des SDK hinausgehen möchten. Daraus folgt keine gleichwertige Unterstützung für den Produktionseinsatz.
| Pfad | In Betracht ziehen, wenn | Einzuordnen als |
|---|---|---|
| Zephyr | Sie Zephyr-APIs, Devicetree, Kconfig oder Board-Anpassungen in einem abgeleiteten (Downstream-)Projekt benötigen. | Ein abgeleiteter (Downstream-), boardspezifischer Evaluierungspfad. |
| Arduino | Sie Sketches oder einen schnellen Peripherie-Prototyp auf einem unterstützten Board benötigen. | Ein Beta-Pfad, der auf bestimmte Boards begrenzt ist. |
| MicroPython | Sie zukünftige Skripting-Unterstützung bewerten. | Eine Statusseite, bis ein reproduzierbarer öffentlicher Port existiert. |
| Rust | Sie HAL-/PAC-Arbeiten bewerten und Korrekturen zum Upstream-Projekt beitragen können. | Ein Community-Projekt in Entwicklung. |
Bevor Sie ein Produkt auf einen dieser Pfade festlegen, prüfen Sie alle benötigten Peripheriegeräte, die Flash-Belegung, die Debug-Methode und die Wiederherstellung auf dem konkreten Entwicklungsboard. Dokumentieren Sie die getestete Revision, Konfiguration, Befehle und Ergebnisse zusammen mit dem Produktquellcode.
Nachweise für eine produktreife Entwicklung¶
Bevor Sie einen Firmware-Pfad als produktreif einstufen, stellen Sie sicher, dass Sie folgende Fragen beantworten können:
- Welcher Chip, welche Revision des Boards oder der kundenspezifischen Hardware und welche Konfiguration wurden getestet?
- Mit welchem SDK, Paket, Branch oder Commit wurde die Firmware erstellt?
- Welche Befehle für Build, Flashen, Überwachung und vollständige Wiederherstellung funktionieren?
- Welches Beispiel oder welcher Test belegt die Funktion jedes benötigten Peripheriegeräts und Produkt-Subsystems?
- Welches Partitionslayout, welches Update-Verhalten, welches Stromverbrauchsziel und welches Vorgehen zur Dekodierung von Absturzprotokollen wurden validiert?
Fehlt eine Antwort, kann die Arbeit weiterhin ein nützlicher Prototyp sein; eine wiederholbare Produkt-Referenzkonfiguration ist sie dann jedoch noch nicht.
Zuletzt aktualisiert: