Bluetooth-Übersicht¶

Übersicht¶

Dieser Leitfaden erklärt, wie sich Bluetooth für SF32-Produkte planen und implementieren lässt. Im Mittelpunkt stehen praktische Entwurfsentscheidungen: BLE oder Dual-Mode-Bluetooth, GATT-Service-Design, Profilwahl, Abstimmung der Verbindungsparameter, Pairing und Sicherheit, LE Audio sowie die Koexistenz mit Grafik-, Audio- und Sensorverarbeitung.

SF32 trennt die Anwendungsverarbeitung von zeitkritischen Aufgaben des Bluetooth-Controllers. Der Anwendungsprozessor übernimmt normalerweise Produktlogik und UI; ein Bluetooth- oder Low-Power-Prozessor übernimmt das Timing der Verbindungsschicht und die Funkplanung. Auf welchem Prozessor der Host-Stack und die GATT-Services laufen, hängt vom Gerät und der SDK-Konfiguration ab. Gehen Sie nicht davon aus, dass alle Services auf dem Anwendungsprozessor laufen. Prüfen Sie die Kernkonfiguration und die Kommunikation zwischen den Kernen im gewählten Beispiel.

Eine ausführlichere Erklärung des zugrunde liegenden Subsystems finden Sie unter Bluetooth-Prozessor.

Nutzen Sie diesen Leitfaden, um das drahtlose Verhalten des Produkts festzulegen: benötigte Rollen und Profile, die erwartete Reaktionsfähigkeit und Akkulaufzeit sowie die Aufgabenverteilung zwischen Telefon, Funk und Anwendungs-Firmware. Er ersetzt nicht die Interoperabilitätstests mit den vorgesehenen Telefonen und Zubehörgeräten.

Die Konnektivitätsanforderungen des Produkts festlegen¶

Bevor Sie GATT-Code schreiben, legen Sie fest, was das Produkt tatsächlich benötigt:

• Nur BLE, oder Dual-Mode-Bluetooth (BT Classic + BLE)?
• Bluetooth-Audio — Classic (A2DP/AVRCP/HFP) oder LE Audio?
• Typisches Verbindungsintervall, Latenz- und Durchsatzanforderungen.
• Wie oft der Anwendungsprozessor aufwachen muss und wie lange er jeweils im Schlafzustand bleiben kann.
• Ob das Produkt mit vorhandenen telefonseitigen Services (Benachrichtigungen, Medienkontrolle, Anrufe) interoperieren muss oder nur mit einer eigenen Companion-App.
• Erwartete Reichweite, Antennen-/Gehäusebeschränkungen und RF-Zulassungsziele.
• Ob Firmware-Updates über Bluetooth ausgeliefert werden.

Diese Antworten bestimmen die Geräteauswahl, die passenden SDK-Beispiele und wie lange die Haupt-CPU im Schlafzustand bleiben kann.

BLE, Classic oder Dual-Mode wählen¶

Bluetooth Low Energy (BLE)¶

BLE ist für die meisten vernetzten Wearables und Sensoren die beste Ausgangswahl: Der Datenverkehr tritt sporadisch und ereignisgesteuert auf, der durchschnittliche Energiebedarf ist niedrig, und gängige mobile Betriebssysteme unterstützen BLE breit. Typische BLE-orientierte Produkte sind Fitnessarmbänder, Gesundheitssensoren, Beacons sowie Konfigurations- und Steuerverbindungen zu einer Companion-App.

Classic Bluetooth und Dual-Mode¶

Ergänzen Sie Classic Bluetooth, wenn das Produkt Audio-Streaming (A2DP/AVRCP), Freisprechen (HFP), serielle Datenverbindungen (SPP) oder die Kompatibilität mit vorhandenen Classic-Profilen benötigt. Dual-Mode-Designs stellen höhere Anforderungen an Funkplanung und Koexistenz als reine BLE-Designs. Genau diese Last soll der dedizierte Bluetooth-Prozessor vom übrigen System isolieren.

Nicht jedes Mitglied der SF32-Familie unterstützt Dual-Mode-Bluetooth. Prüfen Sie daher vor der Festlegung auf eine Teilenummer die Gerätetabelle im Artikel Bluetooth-Prozessor.

Das richtige SF32-Gerät wählen¶

Wählen Sie das Gerät anhand der benötigten Konnektivitätsfunktionen des Produkts aus, nicht allein nach der Taktfrequenz.

Wenn das Produkt mehr als nur Konnektivität benötigt, gleichen Sie die Anforderungen an Display, Speicher und KI mit der Grafikübersicht und der Seite KI-Beschleuniger ab.

GATT-Services und das Sibles-Framework¶

SiFli-SDK stellt Sibles zum Registrieren und Nutzen von GATT-Services bereit. GATT definiert die Hierarchie aus Services und Charakteristiken sowie den Zugriff auf Attribute; GAP regelt Advertising, Geräteerkennung, Verbindungsaufbau und die zugehörigen Rollen. Beide Bereiche ergänzen sich; GATT ist keine auf GAP aufgesetzte Schicht. Verwenden Sie ein passendes SDK-Beispiel als Ausgangspunkt, statt eine GATT-Datenbank von Grund auf zu erstellen.

Das SDK liefert Beispielimplementierungen mehrerer Standard- und herstellerspezifischer Profile, darunter:

Übernehmen Sie Registrierung, Ereignisbehandlung und Sicherheitsprüfungen aus dem am besten passenden Beispiel. Behalten Sie bei der Implementierung eines Standardprofils dessen UUIDs und Verhalten bei; verwenden Sie einen eigenen Service mit eigenen UUIDs, wenn das Datenmodell des Produkts dies erfordert. Ziel ist, erprobte Infrastruktur wiederzuverwenden, nicht jedes App-Protokoll in ein Standardprofil zu pressen.

Classic-Bluetooth-Profile¶

Für Dual-Mode-Produkte stellt das SDK Beispiel-Profilimplementierungen bereit für:

• SPP — einfache bidirektionale serielle Daten, nützlich für Legacy- oder Nicht-GATT-Companion-Apps.
• A2DP (Sink und Source) — Bluetooth-Audio-Streaming.
• AVRCP — Wiedergabesteuerung (Play/Pause/Titel/Lautstärke) neben einer A2DP-Verbindung.
• HFP — Freisprechen mit den Rollen HF (Freisprechgerät) und AG (Audio-Gateway). Das dokumentierte HFP-Beispiel implementiert HF; prüfen Sie AG-Unterstützung separat in der gewählten SDK-Konfiguration.
• PAN — Netzwerk über Bluetooth, einschließlich eines PAN-basierten OTA-Zustellbeispiels.

Audio- und Legacy-Profile stellen meist höhere Anforderungen an Zeitverhalten und Durchsatz als einfache BLE-Verbindungen. Planen Sie dafür ausreichend Zeit für Koexistenztests ein (siehe Koexistenz).

Bluetooth-Audio und LE Audio¶

Es gibt zwei unterschiedliche Pfade, abhängig vom Audio-Ansatz:

• Classic-Bluetooth-Audio — A2DP für Streaming, AVRCP für die Wiedergabesteuerung, HFP für Anrufe. Ausgereift, breit kompatibel mit vorhandenen Telefonen und Headsets.
• LE Audio — das Basic Audio Profile (BAP) definiert Verfahren zur Verwaltung von LE-Audio-Streams sowohl im Unicast- als auch im Broadcast-Betrieb. Das SDK enthält Broadcast-Source- und -Sink-Beispiele sowie ein Beispiel, das LE-Audio-Broadcast mit Classic Bluetooth kombiniert. Es eignet sich für Produkte, die während einer Übergangsphase beide Technologien unterstützen müssen.

Beide Wege benötigen stabiles Zeitverhalten, Pufferung und eine zuverlässige Übertragung der Audiodaten, üblicherweise per DMA. Wählen Sie SF32LB52x/56x/58x, wenn deren unterstützte Bluetooth-Audiorollen und SDK-Konfigurationen die Produktanforderungen erfüllen. SF32LB55x unterstützt nur BLE und kann kein Classic-Bluetooth-Audio bereitstellen; das bedeutet jedoch nicht, dass lokale Audiofunktionen fehlen. Hinweise zu DMA und Pufferung finden Sie in der Audioübersicht und im Artikel Bluetooth-Prozessor.

Implementierungsmuster für Sibles-Services¶

Ein wartbarer BLE-Service folgt üblicherweise diesem Muster:

So bleiben GATT-Service, Schnittstelle zur Telefon-App, Sicherheitsrichtlinie und Energieverhalten aufeinander abgestimmt.

Advertising- und Verbindungsparameter¶

Verbindungs- und Advertising-Parameter sind die wichtigsten Stellschrauben, um Latenz, Durchsatz und Energiebedarf gegeneinander abzuwägen.

Diese Parameter gelten für BLE-ACL-Verbindungen, nicht für alle Bluetooth-Audiotransporte. Classic-Audio verwendet das BR/EDR-Zeitverhalten; LE Audio verwendet das isochrone Zeitverhalten von CIS oder BIS. Übertragen Sie ein BLE-GATT-Verbindungsintervall nicht direkt auf diese Audiopfade. Die LE-Einführung der Bluetooth SIG erläutert die unterschiedlichen Transporte.

Beacon-Produkte (mit iBeacon-kompatiblem Advertising) und Anwendungsfälle mit periodischem Advertising, einschließlich der Synchronisierung für groß angelegte oder unidirektionale Broadcasts, werden durch eigene SDK-Beispiele unterstützt und benötigen keine vollständige GATT-Verbindung.

Verbindungsintervall, Peripheral-Latenz und Supervision-Timeout müssen eine gültige Kombination bilden, die Controller und Gegenstelle akzeptieren. Eine angeforderte Aktualisierung ist noch kein Nachweis ihrer Übernahme. Protokollieren Sie die ausgehandelten Werte und testen Sie mit dem vorgesehenen Telefon oder Zubehör, einschließlich abgelehnter Aktualisierungen und der Rückkehr zu den Leerlaufeinstellungen.

Parameterempfehlungen je Produktphase¶

Verwenden Sie für unterschiedliche Phasen unterschiedliche Bluetooth-Parameter statt einer einzigen Kompromisseinstellung:

Dokumentieren Sie die Übergänge zwischen den Phasen. Viele scheinbar „zufällige“ Bluetooth-Probleme mit Energieverbrauch oder Latenz entstehen, weil das Produkt nach einem Zustandswechsel in der falschen Phase bleibt.

Pairing, Bonding und Sicherheit¶

BLE kann ohne Pairing eine Verbindung herstellen. Beim Pairing werden Sicherheitsschlüssel erzeugt; Bonding speichert sie für spätere Verbindungen. Legen Sie für jeden Service fest, ob Verschlüsselung, Authentifizierung und dauerhaft gespeicherte Bonds erforderlich sind, statt Bonding pauschal für jedes Produkt vorauszusetzen:

• Entscheiden Sie frühzeitig, ob das Produkt Just Works, Passkey-Eingabe oder numerischen Vergleich benötigt. Just Works schützt nicht vor Man-in-the-Middle-Angriffen (MITM): Eine verschlüsselte Verbindung ist nicht zwangsläufig authentifiziert. Wählen Sie das Verfahren passend zu den I/O-Fähigkeiten beider Geräte und den Sicherheitsanforderungen des Produkts; siehe Bluetooth-GAP-Sicherheitsanforderungen.
• Bei ANCS ist die Freigabe auf dem Telefon von Link-Verschlüsselung und Bonding zu unterscheiden. Berücksichtigen Sie verweigerte oder widerrufene Freigaben. ANCS und AMS können während einer Verbindung verfügbar werden oder verschwinden. Überwachen Sie Service Changed und suchen Sie den Service erneut; Pairing garantiert keine dauerhafte Verfügbarkeit.
• Speichern Sie Bonding-Informationen gemäß dem vom SDK empfohlenen Speicher-/Partitionsansatz, damit Bonds Neustarts und OTA-Updates überstehen.
• Definieren Sie einen Ablauf für erneutes Pairing und „Gerät vergessen“ sowohl in der Produkt-UI als auch auf dem Telefon.
• Behandeln Sie die Sicherheitsrichtlinie (Verschlüsselungsanforderungen, I/O-Fähigkeit, Schlüsselgröße) als Produktentscheidung, nicht als unbeachteten Standardwert.

Mehrfachverbindungen und Rollen¶

Das SDK demonstriert gleichzeitige Central- und Peripheral-Rollen sowie mehrere gleichzeitige Verbindungen. Ein Produkt kann als BLE-Peripheral mit einem Telefon und als Central mit einem Sensor verbunden sein oder mehrere Companion-Verbindungen verwalten. Prüfen Sie die Rollenkombination und die maximale Verbindungszahl für das Gerät, die Controller-Firmware, die SDK-Konfiguration, die Puffer und die gesamte Funklast. Ein Beispiel garantiert keine einheitliche Verbindungskapazität für die ganze Familie.

Wenn das Produkt den Durchsatz nahe an die maximale Datenrate der Verbindung bringen muss, verwenden Sie zunächst das SDK-Durchsatzbeispiel als Referenz, bevor Sie eine Einschränkung im Anwendungscode vermuten.

OTA-Firmware-Updates über Bluetooth¶

Es gibt zwei gängige Übertragungswege:

• DFU-artige Updates über BLE, integriert in eine Peripheral-Verbindung (das Beispiel peripheral_with_ota zeigt, wie OTA in eine normale Peripheral-GATT-Rolle eingebunden wird).
• PAN OTA, das Firmware über eine Bluetooth-PAN-Netzwerkverbindung für Dual-Mode-Produkte liefert, die PAN bereits für Daten nutzen.

Planen und testen Sie vor der Auslieferung für beide Wege das Partitionslayout, die Wiederherstellung nach Fehlern und das Rollback. Prüfen Sie für BLE-OTA ein kürzeres Verbindungsintervall und eine Peripheral-Latenz von null während der Übertragung; stellen Sie danach die normalen Energiespareinstellungen wieder her. PAN-OTA nutzt Classic Bluetooth. Optimieren Sie Durchsatz und Wiederherstellung nach Fehlern dafür separat, statt BLE-Verbindungsparameter zu übernehmen.

Koexistenz mit anderen Systemlasten¶

Bluetooth läuft auf SF32 selten allein — es teilt sich das System mit Grafik, Audio, Sensoren und manchmal externem WLAN. Der dedizierte Bluetooth-Prozessor übernimmt den Großteil der zeitkritischen Link-Verarbeitung. Die Koexistenz auf Anwendungsebene muss dennoch berücksichtigt werden:

• Lange kritische Abschnitte oder deaktivierte Interrupts auf dem Anwendungsprozessor können die hostseitige Bluetooth-Verarbeitung verzögern.
• Display- und PSRAM-Verkehr konkurrieren mit Bluetooth-Audio-Puffern um Speicherbandbreite.
• Sensorinterrupts, die den Anwendungsprozessor zu oft wecken, können die Energieersparnis zunichtemachen, die dadurch entsteht, dass er schläft, während der Bluetooth-Prozessor die Verbindung abwickelt.

Für die Systemsicht siehe Koexistenz mit anderen Systemlasten. Testen Sie realistische, besonders anspruchsvolle Kombinationen (z. B. aktives Display, Audio und eine stark ausgelastete BLE-Verbindung) statt jedes Subsystem isoliert.

RF, Interoperabilität und Zertifizierungsvorbereitung¶

Bluetooth-Firmware sollte mit derselben Disziplin validiert werden wie RF-Hardware:

• Testen Sie mit Telefonen verschiedener Hersteller, unterschiedlichen Betriebssystemversionen und in mehreren Wiederverbindungsszenarien, nicht nur mit einem Entwicklungstelefon.
• Prüfen Sie das Verhalten nach veralteten Bonds, telefonseitigem „Gerät vergessen“, geräteseitigem Werksreset und OTA.
• Validieren Sie Reichweite und Paketstabilität im endgültigen Gehäuse mit Akku, Display und Ladegerät sowie in typischen Trage- und Haltepositionen.
• Halten Sie RF-Testmodi, Kalibrierungszugang und Protokolle für Produktion und Zulassungsunterstützung verfügbar.
• Reservieren Sie bei Produkten mit vielen Profilen genügend Zeit für Qualifikations- und Profiltests. Eine funktionierende Demo-App belegt noch keine Interoperabilität.

Bluetooth-Fehler eingrenzen¶

Häufige Fehler¶

• Auswählen reiner BLE-Hardware, nachdem das Produkt bereits Classic-Audio benötigt.
• Unnötiges Neuimplementieren der Service-Infrastruktur oder Erzwingen eines eigenen Datenmodells in einem ungeeigneten Standardprofil.
• Belassen der Peripheral-Latenz bei 0 für Verbindungen, die die meiste Zeit inaktiv sind.
• Ignorieren von Koexistenztests bis zur späten Integration, wenn Display/Audio/Bluetooth erstmals kombiniert werden.
• Behandeln von Pairing und Bonding als nachträgliche Frage der Nutzerführung, statt den Ablauf von Anfang an zu gestalten.
• Auslassen der RF-Bring-up-Validierung (Antenne, Anpassnetzwerk, Quarzgenauigkeit) bis zu den finalen Leiterplattenrevisionen.
• Annehmen, reines Firmware-Tuning könne ein schlechtes RF-Layout kompensieren.

Inbetriebnahme-Checkliste¶

• Prüfen Sie, ob das Produkt nur BLE oder Dual-Mode benötigt, und wählen Sie das passende SF32-Gerät.
• Ermitteln Sie die am besten passenden SDK-Beispiele für Profile und Services des Produktanwendungsfalls.
• Legen Sie die Zielwerte für Advertising- und Verbindungsparameter bei Geräteerkennung, aktiver Nutzung und im Leerlauf fest.
• Gestalten Sie den Ablauf für Pairing, Bonding und „Gerät vergessen“.
• Validieren Sie RF-Layout, Antennenanpassung und Quarzgenauigkeit an realer Hardware.
• Nehmen Sie die gewählten Profile (GATT-Services, A2DP/AVRCP/HFP oder LE-Audio-Broadcast) mit einem realen Telefon oder Referenz-Host in Betrieb und testen Sie sie.
• Testen Sie die Koexistenz mit Display, Audio und Sensoren unter realistischer kombinierter Last.
• Planen und testen Sie den OTA-Zustellpfad, falls Firmware-Updates über Bluetooth ausgeliefert werden.
• Messen Sie die Leistungsaufnahme im verbundenen Leerlauf und prüfen Sie, ob der Anwendungsprozessor wie erwartet in den Schlafzustand wechselt.

Wichtigste Erkenntnisse¶

• Entscheiden Sie zuerst zwischen reinem BLE und Dual-Mode-Bluetooth. Davon hängen die Gerätewahl und das weitere Vorgehen mit dem SDK maßgeblich ab.
• Beginnen Sie mit den vorhandenen GATT-Services und Classic-Profilbeispielen des SDK (HRPC, DISS, CTS, HID, ANCS/AMS, SPP, A2DP, AVRCP, HFP, PAN), statt von Grund auf zu bauen.
• Verbindungsintervall, Peripheral-Latenz, Supervision-Timeout und TX-Leistung sind die wichtigsten Stellschrauben, um Latenz, Durchsatz und Energiebedarf auszubalancieren.
• Prüfen Sie bei Bluetooth-Audio die benötigte Classic- oder LE-Audio-Rolle für das konkrete Gerät und die SDK-Konfiguration. Entwerfen und testen Sie anschließend Pufferung und Koexistenz; eine Aussage über die gesamte Familie ersetzt diese Prüfung nicht.
• Bluetooth ist ein Thema auf Systemebene: RF-Layout, Takte, Nutzerführung beim Pairing und Koexistenz mit Grafik, Audio und Sensoren sind ebenso wichtig wie der GATT-Code selbst.

Für eine aufgabenorientierte Übersicht der aktuellen Classic-Bluetooth-, BLE- und LE-Audio-SDK-Projekte siehe Bluetooth-SDK-Beispiele.

Für eine praktische Methode zur Messung und Analyse der Bluetooth-Leistungsaufnahme eines Zielgeräts siehe Bluetooth-Leistungsaufnahme messen und analysieren.

Zuletzt aktualisiert: 2026-10-19