Bluetooth-SDK-Beispiele¶
Die SiFli-SDK-Bluetooth-Beispiele sind gezielte Ausgangspunkte für ein Profil, eine Rolle oder einen Funkablauf; sie sind keine fertige Produkt-Firmware. Beginnen Sie mit dem Projekt, das die technisch anspruchsvollste Produktanforderung abdeckt. Bringen Sie das unveränderte Beispiel auf dem Zielboard zum Laufen und ergänzen Sie anschließend jeweils eine Produktanforderung.
Diese Seite ordnet die Beispiele für Classic Bluetooth, BLE und LE-Audio-Broadcast aus der SF32LB58x-Dokumentation nach Entwicklungsaufgabe. Der Pfad sf32lb58x kennzeichnet den Dokumentationsbereich und ist keine Zusage, dass jedes Beispiel auf jedem SF32LB58x-Board oder einer anderen SF32-Familie unterstützt wird. Die URL latest wird fortlaufend aktualisiert. Prüfen Sie für den vorgesehenen SDK-Release oder Commit den Abschnitt Supported Platforms der jeweiligen Projektseite und verwenden Sie nur die dort genannten Boardnamen und Build-Anweisungen. Ist die Unterstützung für das konkrete Board und den SDK-Stand nicht ausdrücklich belegt, kennzeichnen Sie sie als ungeprüft; leiten Sie sie weder aus der URL noch aus einem anderen Beispiel noch aus einem ähnlich benannten Board ab. Auch bei der Angabe „all platforms“ muss das Beispiel vor der Produktentwicklung mit dem tatsächlichen SDK-Stand und der Boardkonfiguration gebaut werden. menuconfig-Einstellungen, Testausrüstung und Einschränkungen stehen ebenfalls auf der jeweiligen Projektseite.
Mit dem richtigen Bluetooth-Pfad beginnen¶
| Produktbedarf | Geeigneter Ausgangspunkt | Vor der Produktintegration validieren |
|---|---|---|
| Ein benutzerdefinierter BLE-Service oder eine Verbindung zu einer Companion-App | BLE Peripheral | Advertising, Verbindungsaufbau, die Dienstschnittstelle und ihr Verhalten, Wiederverbindung sowie Validierung mit dem Telefon |
| Das Gerät muss gegenüber dem Telefon als Peripheral und gegenüber einem Sensor als Central agieren | BLE Central and Peripheral | Gleichzeitige GAP-Rollen und die Zuordnung der GATT-Client- und -Server-Rollen |
| Zuverlässige BLE-Datenübertragung | BLE Throughput oder BLE File Transfer | Der benötigte Nutzdatenfluss, die Verbindungseinstellungen und das Wiederherstellungsverhalten |
| Bluetooth-Firmware-Update | Peripheral with OTA oder Central and Peripheral with Pingpong OTA | Update-Rollen, Wiederherstellung nach einem unterbrochenen Update, Partitionen und Rollback-Plan |
| Serielle Verbindung oder Netzwerkzugang über das Telefon mit Classic Bluetooth | SPP oder PAN | Das serielle Profil bzw. der Netzwerkzugang über das Telefon, Kompatibilität mit Gegenstellen und Wiederverbindungsverhalten |
| HCI-Transport über UART zwischen Host und BT/BLE-Controller | HCI over UART (BT/BLE) | Host-/Controller-Grenze, UART-Transport sowie Konfiguration des Zielcontrollers und Zielboards |
| Classic-Bluetooth-Audio oder -Anrufe | Music Sink, Music Source oder HFP | Audio-Routing, Taktung, Pufferung, Interoperabilität mit Telefonen und Energiebudget |
| LE-Audio-Broadcast | BAP Broadcast Source oder BAP Broadcast Sink | Broadcast-Rolle, Audio-Pipeline, Testempfänger oder -sender und Zeitreserve |
Ein Beispiel als Nachweisgrundlage in Betrieb nehmen¶
Protokollieren Sie vor Änderungen am Projekt die genaue SDK-Version, den Boardnamen, die Konfiguration, das Gegenstellengerät oder die App, die Funkeinstellungen und die erwarteten Logmeldungen. Gehen Sie anschließend wie folgt vor:
- Bauen und flashen Sie das unveränderte Beispiel mit dem exakten Boardnamen und den Anweisungen, die für den passenden SDK-Release angegeben sind. Ist die Zuordnung zwischen Dokumentation und SDK-Stand oder die Boardunterstützung nicht belegt, behandeln Sie die Kompatibilität vor der Anpassung als ungeprüft.
- Prüfen Sie das zentrale Funkverhalten: Geräteerkennung, Verbindung, Übertragung, Streaming oder Empfang, je nach Anwendungsfall.
- Wiederholen Sie den Test nach Reset, Trennung, Wiederverbindung sowie Aus- und Einschalten.
- Ergänzen Sie jeweils einen produktspezifischen Service, Benutzerablauf, Audiopfad oder eine Energiesparrichtlinie.
- Testen Sie erneut unter der kombinierten Produktlast, einschließlich Display, Sensoren, Speicher, Audio und Übergängen in Energiesparzustände, sofern zutreffend.
Ein funktionierendes Beispiel zeigt nur den darin abgedeckten Ablauf. Es belegt nicht, dass Sicherheitsrichtlinie, Funkreichweite, Latenz, Stromverbrauch oder Interoperabilität des Produkts bereits für die Freigabe ausreichen.
BLE-Beispiele¶
Verwenden Sie BLE-Beispiele für Companion-App-Verbindungen, interoperable GATT-Services, Beacons, Datenübertragung und BLE-basiertes OTA. Wählen Sie zunächst ein rollenorientiertes Beispiel und fügen Sie ein Profilbeispiel nur hinzu, wenn das Produkt diesen standardisierten Service benötigt.
| Entwicklungsaufgabe | Offizielle Beispiele | Mit diesen Projekten prüfen |
|---|---|---|
| Grundlegende Rollen und Dienstzugriff | Peripheral, Central and Peripheral, Multi-Connection | Advertising, Scanning, Verbindungsverwaltung und die richtige Zuordnung von Central und Peripheral |
| Telefonintegration | AMS, ANCS, Dual-Core ANCS | Apple-Medien- oder Benachrichtigungsintegration und der erforderliche Pairing-Ablauf auf dem Telefon |
| Standard-GATT-Profile | BASC, CPPC, CSCPC, DISS, HRPC, CTS | Servicerolle, Definition der GATT-Charakteristiken und Interoperabilität des Standardprofils mit Geräten anderer Hersteller |
| Eingabe und Gegensprechfunktion | HID, BLE Talkback | Das Interaktionsmodell, bevor Produkt-UI oder Sprachverhalten hinzukommen |
| Pairing und Wiederverbindung | BLE Pair | Bonding, Identitätsbehandlung und den erneuten Pairing-Ablauf des Produkts |
| Advertising und Geräteerkennung | iBeacon, Periodic Advertising, Periodic Advertising Sync | Das erforderliche Broadcast- oder Synchronisationsverhalten, ohne eine GATT-Verbindung vorauszusetzen |
| Datenübertragung und OTA | File Transfer, Throughput, Peripheral with OTA, Central and Peripheral with Pingpong OTA | Nutzdaten, Verbindungsparameter, Update-Rollen, Wiederherstellung nach Unterbrechung und End-to-End-Validierung |
Behandeln Sie den gemessenen Durchsatz nicht als Produktdatenrate. Er hängt von der gewählten PHY, den Verbindungseinstellungen, dem Verhalten der Gegenstelle, der RF-Umgebung, der Hostaktivität und dem Nutzdatenmuster ab. Ebenso ist ein ANCS- oder AMS-Beispiel ein Ausgangspunkt für die Telefonintegration und keine Garantie für jede iOS-Version oder jeden Berechtigungszustand auf Nutzerseite.
Classic-Bluetooth-Beispiele¶
Classic-Bluetooth-Projekte sind relevant, wenn ein Produkt BR/EDR-Profile, Audio, seriellen Transport oder IP-Netzwerkzugang über ein Telefon benötigt. Eine erfolgreiche Demonstration auf dem Entwicklungsboard ist nur der Ausgangspunkt; validieren Sie die Interoperabilität mit den tatsächlichen Gegenstellengeräten und der Produktlast.
| Entwicklungsaufgabe | Offizielle Beispiele | Mit diesen Projekten prüfen |
|---|---|---|
| Host-/Controller-Transport oder serielles Classic-Bluetooth-Profil | HCI over UART (BT/BLE), SPP | Die Host-/Controller-Grenze und der UART-Transport für HCI oder das Verhalten des seriellen SPP-Profils |
| Audio-Streaming und Mediensteuerung | A2DP Multi-Connection, A2DP Sharing, AVRCP Cover Art, Music Sink, Music Sink with Relay, Music Source | Die vorgesehene Source-/Sink-Topologie, das Audio-Routing, den Pfad der Mediensteuerung und das Ressourcenbudget |
| Anrufe und Sprachverbindungen | 3-SCO, HFP, HFP Relay | Anruftopologie, Audio-Latenz, Mikrofon-/Lautsprecherpfad und Telefonverhalten |
| Netzwerkfreigabe über das Telefon und OTA | PAN, PAN OTA | Freigabe der Telefonverbindung, IP-Verkehr, Wiederverbindung und OTA-Übertragung |
Zum PAN-Netzwerkmodell und zur Einrichtung auf dem Telefon siehe Bluetooth PAN. Informationen zu Audio-Routing, Pufferverwaltung und Validierung unter Systemlast finden Sie in der Audioübersicht und im Artikel Audio-Server und Pufferung.
LE-Audio-Broadcast-Beispiele¶
Der Dokumentationspfad sf32lb58x belegt für sich genommen keine Boardkompatibilität; prüfen Sie im Abschnitt Supported Platforms die genaue SDK-Revision und das Zielboard. Beim Beispiel für die Verbindung von Classic Bluetooth und BAP bezeichnet der README-Titel einen Sender, während Pfad und Übersicht einen Empfänger beschreiben. Die Implementierung im geprüften SDK-Stand verarbeitet Classic A2DP und startet einen BAP-Broadcast-Sender. Dieser Befund gilt nur für den verlinkten Commit und nicht automatisch für jeden über latest bereitgestellten SDK-Release. Prüfen Sie vor dem Build README, Quellcode und Boardkonfiguration für den tatsächlich verwendeten SDK-Release oder Commit. Leiten Sie weder Rolle noch Boardunterstützung aus der kopierten Empfängerbeschreibung ab.
Die zbt-Projekte enthalten LE-Audio-Broadcast-Source- und -Sink-Beispiele auf Basis des Basic Audio Profile (BAP). Betrachten Sie Sender (Source) und Empfänger (Sink) als zusammengehörigen Systemtest: Broadcast-Konfiguration, Audioquelle, Empfangsgerät, Taktsynchronisierung und RF-Bedingungen beeinflussen gemeinsam das Ergebnis.
| Anwendungsfall | Offizielles Beispiel | Zuerst nachzuweisen |
|---|---|---|
| Einen Broadcast-Audiostream empfangen | BAP Broadcast Sink | Verhalten des Empfängers, Audio-Ausgabepfad und Testkonfiguration des Broadcasts |
| Einen Broadcast-Audiostream senden | BAP Broadcast Source | Audio-Pipeline des Senders, Broadcast-Konfiguration und ein nachweislich kompatibler Empfänger |
| Classic Bluetooth und LE-Audio-Broadcast überbrücken | BAP Broadcast Source with Classic Bluetooth | Die beiden Audiobereiche, ihre Datenübergabe und die Zeit- und Ressourcenreserve bei gleichzeitigem Betrieb |
Produktvalidierung über das Beispiel hinaus¶
| Prüfbereich | Aus dem Ausgangsbeispiel übernehmen | Für das Produkt neu validieren |
|---|---|---|
| Funkverhalten | Das unterstützte Board und die vorgesehene Rolle oder das Profil des Beispiels | Antenne, Gehäuse, Reichweite, RF-Koexistenz, Gegenstellengeräte und Plan für Zulassungsprüfungen |
| Verbindungsrichtlinie | Der grundlegende Advertising-, Scan- oder Verbindungsablauf | Produktlatenz, Zielwert für den Energieverbrauch, Wiederverbindungsstrategie und Zustandswechsel |
| Sicherheit | Das Pairing- oder Bonding-Setup des Beispiels | Authentifizierungsanforderungen, Schlüsselspeicherung, Datenschutz, Werksreset und nutzerseitige Wiederherstellung |
| Daten und Audio | Der demonstrierte Paket- oder Stream-Fluss | Nutzdatenformat und Austauschregeln, Fehlerbehandlung, Latenz, Pufferung, Codec-Konfiguration und Speicherreserve |
| Validierungsnachweis | Build-Einstellungen, Protokolle und erwartetes Verhalten | Wiederholbare Telefon-/Zubehör-Matrix, Messkurve der Leistungsaufnahme, Wiederherstellung nach Trennung und Regressionstest |
Verwandte Ressourcen¶
- Bluetooth-Übersicht für Entscheidungen zu Rollen, Profilen, Sicherheit, Verbindungsparametern und Koexistenz auf Produktebene.
- Bluetooth-Prozessor für Host-/Controller-Grenzen und Energiesparverhalten.
- Bluetooth PAN für IP-Netzwerkverbindungen über das Telefon und PAN-basiertes OTA.
- Audio-SDK-Beispiele für lokale Erfassungs-, Codec- und Wiedergabebeispiele, die Bluetooth-Audio ergänzen.
- Beispiele für den domänenübergreifenden SDK-Beispielkatalog.
Zuletzt aktualisiert: