Bluetooth Low Energy-Bibliothek - Kostenlos RTOS
ÜbersichtArchitekturAbhängigkeiten und AnforderungenBibliothekskonfigurationsdateiOptimierungNutzungsbeschränkungenInitialisierungAPI-ReferenzBeispielverwendungPortierungAnhang A: MQTT über BLE GATT-Profil

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bluetooth Low Energy-Bibliothek

Wichtig

Diese Bibliothek wird im Amazon-FreeRTOS-Repository gehostet, das veraltet ist. Wir empfehlen, dass Sie hier beginnen, wenn Sie ein neues Projekt erstellen. Wenn Sie bereits ein vorhandenes FreeRTOS-Projekt haben, das auf dem inzwischen veralteten Amazon-FreeRTOS-Repository basiert, finden Sie weitere Informationen unter. Leitfaden zur Migration des kostenlosen RTOS Github-Repositorys von Amazon

Übersicht

FreeRTOS unterstützt das Veröffentlichen und Abonnieren von MQTT-Themen (Message Queuing Telemetry Transport) über Bluetooth Low Energy über ein Proxygerät, z. B. ein Mobiltelefon. Mit der FreeRTOS Bluetooth Low Energy (BLE) -Bibliothek kann Ihr Mikrocontroller sicher mit dem MQTT-Broker kommunizieren. AWS IoT

BLE-Geräte, die AWS IoT Core über MQTT/HTTP/WebSocket über Cognito eine Verbindung herstellen. AWS

Mithilfe der Mobile SDKs für FreeRTOS-Bluetooth-Geräte können Sie native mobile Anwendungen schreiben, die mit den eingebetteten Anwendungen auf Ihrem Mikrocontroller über BLE kommunizieren. Weitere Informationen über SDKs für Mobilgeräte finden Sie unter Mobile SDKs für FreeRTOS-Bluetooth-Geräte.

Die FreeRTOS BLE-Bibliothek umfasst Dienste für die Konfiguration von Wi-Fi-Netzwerken, die Übertragung großer Datenmengen und die Bereitstellung von Netzwerkabstraktionen über BLE. Die FreeRTOS BLE-Bibliothek umfasst auch Middleware und APIs auf niedrigerer Ebene für eine direktere Kontrolle über Ihren BLE-Stack.

Architektur

Die FreeRTOS BLE-Bibliothek besteht aus drei Ebenen: Dienste, Middleware und Low-Level-Wrapper.

Ebenen der Cloud-Architektur: Benutzeranwendung, Dienste, Middleware, Low-Level-Wrapper, BLE-Stack des Herstellers.

Services

Die FreeRTOS BLE-Serviceschicht besteht aus vier GATT-Diensten (Generic Attribute), die die Middleware-APIs nutzen:

  • Geräteinformationen

  • WLAN-Bereitstellung

  • Network Abstraction

  • Übertragung großer Objekte

Geräteinformationen

Der Geräteinformationsdienst sammelt Informationen über Ihren Mikrocontroller, darunter:

  • Die Version von FreeRTOS, die Ihr Gerät verwendet.

  • Der AWS IoT Endpunkt des Kontos, für das das Gerät registriert ist.

  • Bluetooth Low Energy-MTU (Maximum Transmission Unit).

WLAN-Bereitstellung

Mit dem WLAN-Bereitstellungsservice können Mikrocontroller mit WLAN-Funktionen Folgendes durchführen:

  • Auflisten von Netzwerken in Reichweite

  • Speichern von Netzwerken und Netzwerk-Anmeldeinformationen auf Flash-Speicher

  • Festlegen der Netzwerkpriorität

  • Löschen von Netzwerken und Netzwerk-Anmeldeinformationen vom Flash-Speicher

Network Abstraction

Der Netzwerkabstraktionsdienst abstrahiert den Netzwerkverbindungstyp für Anwendungen. Eine gemeinsame API interagiert mit dem Wi-Fi-, Ethernet- und Bluetooth Low Energy-Hardware-Stack Ihres Geräts, sodass eine Anwendung mit mehreren Verbindungstypen kompatibel ist.

Large Object Transfer

Der Large Object Transfer-Dienst sendet Daten an einen Client und empfängt Daten von einem Client. Andere Dienste, wie Wi-Fi-Bereitstellung und Netzwerkabstraktion, verwenden den Large Object Transfer-Dienst zum Senden und Empfangen von Daten. Sie können auch die Large Object Transfer API verwenden, um direkt mit dem Dienst zu interagieren.

MQTT über BLE

MQTT over BLE enthält das GATT-Profil für die Erstellung eines MQTT-Proxydienstes über BLE. Der MQTT-Proxydienst ermöglicht es einem MQTT-Client, über ein Gateway-Gerät mit dem AWS MQTT-Broker zu kommunizieren. Sie können beispielsweise den Proxydienst verwenden, um ein Gerät, auf dem FreeRTOS ausgeführt wird, über eine Smartphone-App mit AWS MQTT zu verbinden. Das BLE-Gerät ist der GATT-Server und stellt Dienste und Eigenschaften für das Gateway-Gerät bereit. Der GATT-Server verwendet diese exponierten Dienste und Eigenschaften, um MQTT-Operationen mit der Cloud für dieses Gerät durchzuführen. Weitere Informationen finden Sie unter Anhang A: MQTT über BLE GATT-Profil .

Middleware

Die FreeRTOS Bluetooth Low Energy-Middleware ist eine Abstraktion von den APIs auf niedrigerer Ebene. Die Middleware-APIs bilden eine benutzerfreundlichere Schnittstelle zum Bluetooth Low Energy-Stack.

Mithilfe von Middleware-APIs können Sie mehrere Callbacks über mehrere Ebenen in einem einzigen Ereignis registrieren. Die Initialisierung der Bluetooth Low Energy-Middleware initialisiert auch Services und beginnt mit dem Advertising.

Flexibles Callback-Abonnement

Nehmen wir an, Ihre Bluetooth Low Energy-Hardware wird getrennt, und der MQTT über den Bluetooth Low Energy-Service muss die Trennung erkennen. Eine Anwendung, die Sie geschrieben haben, muss diese Verbindungstrennung möglicherweise auch erkennen. Die Bluetooth Low Energy-Middleware kann das Ereignis an verschiedene Teile des Codes weiterleiten, in dem Callbacks registriert wurden, ohne dass die höheren Ebenen um Lower-Level-Ressourcen konkurrieren.

Low-Level-Wrapper

Die Low-Level-FreeRTOS Bluetooth Low Energy-Wrapper sind eine Abstraktion aus dem Bluetooth Low Energy-Stack des Herstellers. Low-Level-Wrapper bieten einen Satz gemeinsamer APIs für die direkte Kontrolle über die Hardware. Die Low-Level-APIs optimieren die RAM-Nutzung, haben jedoch beschränkte Funktionalität.

Verwenden Sie die Bluetooth Low Energy-Service-APIs, um mit den Bluetooth Low Energy-Services zu interagieren. Die Service-APIs benötigen mehr Ressourcen als die Low-Level-APIs.

Abhängigkeiten und Anforderungen

Die Bluetooth Low Energy-Bibliothek hat die folgenden direkten Abhängigkeiten:

  • Bibliothek für lineare Container

  • Eine Plattformschicht, die mit dem Betriebssystem für Thread-Management, Timer, Taktgeberfunktionen und Netzwerkzugriff verbunden ist.

Architekturdiagramm mit den Komponenten: BLE, Liste/Warteschlange, Netzwerk und Uhr, mit Richtungspfeilen, die Interaktionen anzeigen.

Nur der Wi-Fi Provisioning Service hat Abhängigkeiten von der FreeRTOS-Bibliothek:

GATT-Service -Abhängigkeit
WLAN-Bereitstellung WLAN-Bibliothek

Um mit dem AWS IoT MQTT-Broker kommunizieren zu können, benötigen Sie ein AWS Konto und müssen Ihre Geräte als Dinge registrieren. AWS IoT Weitere Informationen zur Einrichtung finden Sie im AWS IoT Entwicklerhandbuch.

FreeRTOS Bluetooth Low Energy verwendet Amazon Cognito für die Benutzerauthentifizierung auf Ihrem Mobilgerät. Um MQTT-Proxydienste verwenden zu können, müssen Sie eine Amazon Cognito Cognito-Identität und Benutzerpools erstellen. Jeder Amazon Cognito Identity muss die entsprechende Richtlinie beigefügt sein. Weitere Informationen finden Sie im Amazon Cognito Entwicklerhandbuch.

Bibliothekskonfigurationsdatei

Anwendungen, die den FreeRTOS MQTT over Bluetooth Low Energy-Dienst verwenden, müssen eine iot_ble_config.h Header-Datei bereitstellen, in der Konfigurationsparameter definiert sind. Nicht definierte Konfigurationsparameter nehmen die in iot_ble_config_defaults.h angegebenen Standardwerte an.

Einige wichtige Konfigurationsparameter sind:

IOT_BLE_ADD_CUSTOM_SERVICES

Ermöglicht es Benutzern, ihre eigenen Services zu erstellen.

IOT_BLE_SET_CUSTOM_ADVERTISEMENT_MSG

Ermöglicht Benutzern, das Advertising anzupassen und Antwortnachrichten zu scannen.

Weitere Informationen finden Sie unter API-Referenz Bluetooth Low Energy (BLE).

Optimierung

Wenn Sie die Leistung Ihres Boards optimieren, sollten Sie Folgendes berücksichtigen:

  • Low-Level-APIs benötigen weniger RAM, bieten jedoch nur eingeschränkte Funktionalität.

  • Sie können den Parameter bleconfigMAX_NETWORK in der iot_ble_config.h-Header-Datei auf einen niedrigeren Wert setzen, um die Menge des verbrauchten Stacks zu verringern.

  • Außerdem können Sie die MTU-Größe auf ihren maximalen Wert erhöhen, um das Puffern von Nachrichten zu begrenzen, den Code schneller ausführen zu lassen und so weniger RAM zu verbrauchen.

Nutzungsbeschränkungen

Standardmäßig setzt die FreeRTOS Bluetooth Low Energy-Bibliothek die eBTpropertySecureConnectionOnly Eigenschaft auf TRUE, wodurch das Gerät in den Modus Nur sichere Verbindungen versetzt wird. Wie unter Bluetooth-Kernspezifikation v5.0, Vol. 3, Teil C, 10.2.4 angegeben, ist für ein Gerät im Modus "Nur sichere Verbindungen" der höchste LE-Sicherheitsmodus "1 Level, Level 4" für den Zugriff auf alle Attribute erforderlich, die höhere Berechtigungen als den niedrigsten LE-Sicherheitsmodus "1 Level, Level 1" aufweisen. Im LE-Sicherheitsmodus 1, Level 4, muss ein Gerät über Ein- und Ausgabefunktionen für den numerischen Abgleich verfügen.

Hier sind die unterstützten Modi und die zugehörigen Eigenschaften:

Modus 1, Level 1 (Keine Sicherheit)
/* Disable numeric comparison */
#define IOT_BLE_ENABLE_NUMERIC_COMPARISON        ( 0 )
#define IOT_BLE_ENABLE_SECURE_CONNECTION         ( 0 )
#define IOT_BLE_INPUT_OUTPUT                     ( eBTIONone )
#define IOT_BLE_ENCRYPTION_REQUIRED               ( 0 )
Modus 1, Level 2 (Nicht authentifizierte Kopplung mit Verschlüsselung)
#define IOT_BLE_ENABLE_NUMERIC_COMPARISON        ( 0 )
#define IOT_BLE_ENABLE_SECURE_CONNECTION         ( 0 )
#define IOT_BLE_INPUT_OUTPUT                     ( eBTIONone )
Modus 1, Level 3 (Authentifizierte Kopplung mit Verschlüsselung)

Dieser Modus wird nicht unterstützt.

Modus 1, Level 4 (Authentifizierte LE Secure-Verbindungen mit Verschlüsselung)

Dieser Modus wird standardmäßig unterstützt.

Weitere Informationen über LE-Sicherheitsmodi finden Sie in der Bluetooth-Kernspezifikation v5.0, Vol. 3, Teil C, 10.2.1.

Initialisierung

Wenn Ihre Anwendung über die Middleware mit dem Bluetooth Low Energy-Stack interagiert, müssen Sie nur die Middleware initialisieren. Die Middleware übernimmt die Initialisierung der niedrigeren Ebenen des Stacks.

Middleware

So wird die Middleware initialisiert

  1. Initialisieren Sie alle Bluetooth Low Energy-Hardwaretreiber, bevor Sie die Bluetooth Low Energy-Middleware-API aufrufen.

  2. Aktivieren Sie Bluetooth Low Energy.

  3. Initialisieren Sie die Middleware mit IotBLE_Init().

    Anmerkung

    Dieser Initialisierungsschritt ist nicht erforderlich, wenn Sie die Demos ausführen. AWS Die Demo-Initialisierung wird vom Netzwerkmanager durchgeführt, der sich in freertos/demos/network_manager befindet.

Low-Level-APIs

Wenn Sie die FreeRTOS Bluetooth Low Energy GATT-Dienste nicht nutzen möchten, können Sie die Middleware umgehen und direkt mit den Low-Level-APIs interagieren, um Ressourcen zu sparen.

So werden die Low-Level-APIs initialisiert

  1. Initialisieren Sie alle Bluetooth Low Energy-Hardwaretreiber, bevor Sie die APIs aufrufen. Die Treiberinitialisierung ist nicht Teil der Bluetooth Low Energy Low-Level-APIs.

  2. Die Bluetooth Low Energy Low-Level-API ermöglicht ein Aktivieren/Deaktivieren des Bluetooth Low Energy-Stacks zur Optimierung von Leistung und Ressourcen. Bevor Sie die APIs aufrufen, müssen Sie Bluetooth Low Energy aktivieren.

    const BTInterface_t * pxIface = BTGetBluetoothInterface();
xStatus = pxIface->pxEnable( 0 );

  3. Der Bluetooth-Manager enthält APIs, die sowohl für Bluetooth Low Energy als auch für klassisches Bluetooth verwendet werden. Die Callbacks für den gemeinsamen Manager müssen als Zweites initialisiert werden.

    xStatus = xBTInterface.pxBTInterface->pxBtManagerInit( &xBTManagerCb );

  4. Der Bluetooth Low Energy-Adapter befindet sich über der allgemeinern API. Sie müssen seine Callbacks auf dieselbe Art initialisieren, wie Sie die gemeinsame API initialisiert haben.

    xBTInterface.pxBTLeAdapterInterface = ( BTBleAdapter_t * ) xBTInterface.pxBTInterface->pxGetLeAdapter();
xStatus = xBTInterface.pxBTLeAdapterInterface->pxBleAdapterInit( &xBTBleAdapterCb );

  5. Registrieren Sie Ihre neue Benutzeranwendung.

    xBTInterface.pxBTLeAdapterInterface->pxRegisterBleApp( pxAppUuid );

  6. Initialisieren Sie die Callbacks an die GATT-Server.

    xBTInterface.pxGattServerInterface = ( BTGattServerInterface_t * ) xBTInterface.pxBTLeAdapterInterface->ppvGetGattServerInterface();
xBTInterface.pxGattServerInterface->pxGattServerInit( &xBTGattServerCb );

    Nachdem Sie den Bluetooth Low Energy-Adapter initialisiert haben, können Sie einen GATT-Server hinzufügen. Es kann immer nur ein GATT-Server registriert werden.

    xStatus = xBTInterface.pxGattServerInterface->pxRegisterServer( pxAppUuid );

  7. Legen Sie Eigenschaften wie "Nur sichere Verbindungen" und MTU-Größe fest.

    xStatus = xBTInterface.pxBTInterface->pxSetDeviceProperty( &pxProperty[ usIndex ] );

API-Referenz

Die vollständige API-Referenz finden Sie unter API-Referenz Bluetooth Low Energy (BLE).

Beispielverwendung

Die folgenden Beispiele zeigen, wie Sie die Bluetooth Low Energy-Bibliothek für Werbung und zur Erstellung neuer Services nutzen können. Vollständige FreeRTOS Bluetooth Low Energy-Demoanwendungen finden Sie unter Bluetooth Low Energy-Demo-Anwendungen.

Werbung

  1. Legen Sie in Ihrer Anwendung die Advertising-UUID fest:

    static const BTUuid_t _advUUID =
{
    .uu.uu128 = IOT_BLE_ADVERTISING_UUID,
    .ucType   = eBTuuidType128
};

  2. Definieren Sie dann die Callback-Funktion IotBle_SetCustomAdvCb:

    void IotBle_SetCustomAdvCb( IotBleAdvertisementParams_t * pAdvParams,  IotBleAdvertisementParams_t * pScanParams)
{
    memset(pAdvParams, 0, sizeof(IotBleAdvertisementParams_t));
    memset(pScanParams, 0, sizeof(IotBleAdvertisementParams_t));

    /* Set advertisement message */
    pAdvParams->pUUID1 = &_advUUID;
    pAdvParams->nameType = BTGattAdvNameNone;

    /* This is the scan response, set it back to true. */
    pScanParams->setScanRsp = true;
    pScanParams->nameType = BTGattAdvNameComplete;
}

    Dieser Callback sendet die UUID in der Advertising-Nachricht und den vollständigen Namen in der Scan-Antwort.

  3. Öffnen Sie vendors/vendor/boards/board/aws_demos/config_files/iot_ble_config.h und legen Sie IOT_BLE_SET_CUSTOM_ADVERTISEMENT_MSG auf 1 fest. Dadurch wird der IotBle_SetCustomAdvCb-Callback ausgelöst.

Hinzufügen eines neuen Services

Ausführliche Beispiele für Services finden Sie unter freertos/.../ble/services.

  1. Erstellen Sie UUIDs für die Merkmale und Deskriptoren des Services:

    #define xServiceUUID_TYPE \
{\
    .uu.uu128 = gattDemoSVC_UUID, \
    .ucType   = eBTuuidType128 \
}
#define xCharCounterUUID_TYPE \
{\
    .uu.uu128 = gattDemoCHAR_COUNTER_UUID,\
    .ucType   = eBTuuidType128\
}
#define xCharControlUUID_TYPE \
{\
    .uu.uu128 = gattDemoCHAR_CONTROL_UUID,\
    .ucType   = eBTuuidType128\
}
#define xClientCharCfgUUID_TYPE \
{\
    .uu.uu16 = gattDemoCLIENT_CHAR_CFG_UUID,\
    .ucType  = eBTuuidType16\
}

  2. Erstellen Sie einen Puffer, um die Handles der Charakteristika und Deskriptoren zu registrieren:

    static uint16_t usHandlesBuffer[egattDemoNbAttributes];

  3. Legen Sie die Attributstabelle an. Um etwas RAM zu sparen, definieren Sie die Tabelle als const.

    Wichtig

    Legen Sie die Attribute immer einer Reihenfolge, in der der Service als erstes Attribut steht.

    static const BTAttribute_t pxAttributeTable[] = {
     {    
         .xServiceUUID =  xServiceUUID_TYPE
     },
    {
         .xAttributeType = eBTDbCharacteristic,
         .xCharacteristic = 
         {
              .xUuid = xCharCounterUUID_TYPE,
              .xPermissions = ( IOT_BLE_CHAR_READ_PERM ),
              .xProperties = ( eBTPropRead | eBTPropNotify )
          }
     },
     {
         .xAttributeType = eBTDbDescriptor,
         .xCharacteristicDescr =
         {
             .xUuid = xClientCharCfgUUID_TYPE,
             .xPermissions = ( IOT_BLE_CHAR_READ_PERM | IOT_BLE_CHAR_WRITE_PERM )
          }
     },
    {
         .xAttributeType = eBTDbCharacteristic,
         .xCharacteristic = 
         {
              .xUuid = xCharControlUUID_TYPE,
              .xPermissions = ( IOT_BLE_CHAR_READ_PERM | IOT_BLE_CHAR_WRITE_PERM  ),
              .xProperties = ( eBTPropRead | eBTPropWrite )
          }
     }
};

  4. Erstellen Sie ein Array von Callbacks. Dieses Array von Callbacks muss der gleichen Reihenfolge folgen wie das oben definierte Tabellenarray.

    Wenn beispielsweise vReadCounter beim Zugriff auf xCharCounterUUID_TYPE ausgelöst wird und vWriteCommand beim Zugriff auf xCharControlUUID_TYPE ausgelöst wird, definieren Sie das Array wie folgt:

    static const IotBleAttributeEventCallback_t pxCallBackArray[egattDemoNbAttributes] =
    {
  NULL,
  vReadCounter,
  vEnableNotification,
  vWriteCommand
};

  5. Erstellen Sie den Service.

    static const BTService_t xGattDemoService = 
{
  .xNumberOfAttributes = egattDemoNbAttributes,
  .ucInstId = 0,
  .xType = eBTServiceTypePrimary,
  .pusHandlesBuffer = usHandlesBuffer,
  .pxBLEAttributes = (BTAttribute_t *)pxAttributeTable
};

  6. Rufen Sie die IotBle_CreateService-API mit der Struktur auf, die Sie im vorherigen Schritt erstellt haben. Die Middleware synchronisiert die Erstellung aller Services, sodass alle neuen Services bereits definiert sein müssen, wenn der IotBle_AddCustomServicesCb-Callback ausgelöst wird.

    1. Legen Sie in vendors/vendor/boards/board/aws_demos/config_files/iot_ble_config.h IOT_BLE_ADD_CUSTOM_SERVICES auf 1 fest.

    2. Erstellen Sie IotBle _ AddCustomServicesCb in Ihrer Anwendung:

      void IotBle_AddCustomServicesCb(void)
{
    BTStatus_t xStatus;
    /* Select the handle buffer. */
    xStatus = IotBle_CreateService( (BTService_t *)&xGattDemoService, (IotBleAttributeEventCallback_t *)pxCallBackArray );
}

Portierung

Ein- und Ausgabeperipheriegeräte des Benutzers

Für den numerischen Abgleich benötigt eine sichere Verbindung sowohl Eingaben als auch Ausgaben. Das Ereignis eBLENumericComparisonCallback kann mit dem Ereignis-Manager registriert werden:

xEventCb.pxNumericComparisonCb = &prvNumericComparisonCb;
xStatus = BLE_RegisterEventCb( eBLENumericComparisonCallback, xEventCb );

Das Peripheriegerät muss den numerischen Hauptschlüssel anzeigen und das Ergebnis des Vergleichs als Eingabe verwenden.

Portieren von API-Implementierungen

Um FreeRTOS auf ein neues Ziel zu portieren, müssen Sie einige APIs für den Wi-Fi Provisioning Service und die Bluetooth Low Energy-Funktionalität implementieren.

Bluetooth Low Energy-APIs

Um die FreeRTOS Bluetooth Low Energy-Middleware verwenden zu können, müssen Sie einige APIs implementieren.

Allgemeine APIs für GAP für Bluetooth Classic und GAP für Bluetooth Low Energy

  • pxBtManagerInit

  • pxEnable

  • pxDisable

  • pxGetDeviceProperty

  • pxSetDeviceProperty (Alle Optionen außer eBTpropertyRemoteRssi und eBTpropertyRemoteVersionInfo sind obligatorisch.)

  • pxPair

  • pxRemoveBond

  • pxGetConnectionState

  • pxPinReply

  • pxSspReply

  • pxGetTxpower

  • pxGetLeAdapter

  • pxDeviceStateChangedCb

  • pxAdapterPropertiesCb

  • pxSspRequestCb

  • pxPairingStateChangedCb

  • pxTxPowerCb

GAP-spezifische APIs für Bluetooth Low Energy

  • pxRegisterBleApp

  • pxUnregisterBleApp

  • pxBleAdapterInit

  • pxStartAdv

  • pxStopAdv

  • pxSetAdvData

  • pxConnParameterUpdateRequest

  • pxRegisterBleAdapterCb

  • pxAdvStartCb

  • pxSetAdvDataCb

  • pxConnParameterUpdateRequestCb

  • pxCongestionCb

GATT-Server

  • pxRegisterServer

  • pxUnregisterServer

  • pxGattServerInit

  • pxAddService

  • pxAddIncludedService

  • pxAddCharacteristic

  • pxSetVal

  • pxAddDescriptor

  • pxStartService

  • pxStopService

  • pxDeleteService

  • pxSendIndication

  • pxSendResponse

  • pxMtuChangedCb

  • pxCongestionCb

  • pxIndicationSentCb

  • pxRequestExecWriteCb

  • pxRequestWriteCb

  • pxRequestReadCb

  • pxServiceDeletedCb

  • pxServiceStoppedCb

  • pxServiceStartedCb

  • pxDescriptorAddedCb

  • pxSetValCallbackCb

  • pxCharacteristicAddedCb

  • pxIncludedServiceAddedCb

  • pxServiceAddedCb

  • pxConnectionCb

  • pxUnregisterServerCb

  • pxRegisterServerCb

Weitere Informationen zur Portierung der FreeRTOS Bluetooth Low Energy-Bibliothek auf Ihre Plattform finden Sie unter Portierung der Bluetooth Low Energy Library im FreeRTOS Porting Guide.

Anhang A: MQTT über BLE GATT-Profil

Einzelheiten zum GATT-Dienst

MQTT over BLE verwendet eine Instanz des GATT-Datenübertragungsdienstes, um MQTT Concise Binary Object Representation (CBOR) -Nachrichten zwischen dem FreeRTOS-Gerät und dem Proxygerät zu senden. Der Datenübertragungsdienst stellt bestimmte Merkmale zur Verfügung, die beim Senden und Empfangen von Rohdaten über das BLE-GATT-Protokoll helfen. Er kümmert sich auch um die Fragmentierung und Zusammenstellung von Nutzlasten, die über der MTU-Größe (Maximum Transfer Unit) von BLE liegen.

Dienst-UUID

A9D7-166A-D72E-40A9-A002-4804-4CC3-FF00

Dienstinstanzen

Für jede MQTT-Sitzung mit dem Broker wird eine Instanz des GATT-Dienstes erstellt. Jeder Dienst hat eine eindeutige UUID (zwei Byte), die seinen Typ identifiziert. Jede einzelne Instanz wird anhand der Instanz-ID unterschieden.

Jeder Dienst wird als primärer Dienst auf jedem BLE-Servergerät instanziiert. Sie können mehrere Instanzen des Dienstes auf einem bestimmten Gerät erstellen. Der MQTT-Proxy-Servicetyp hat eine eindeutige UUID.

Merkmale

Charakteristisches Inhaltsformat: CBOR

Max. Größe des Merkmalswerts: 512 Byte

Merkmal Anforderung Obligatorische Eigenschaften Optionale Eigenschaften Sicherheitsberechtigungen Kurze Beschreibung UUID
Kontrolle M Schreiben None Schreiben braucht Verschlüsselung Wird verwendet, um den MQTT-Proxy zu starten und zu stoppen. A9D7-166A-D72E-40A9-A002-4804-4CC3-FF01
TxMessage M Lesen, Benachrichtigung None Lesen benötigt Verschlüsselung Wird verwendet, um eine Benachrichtigung mit einer Nachricht über einen Proxy an einen Broker zu senden. A9D7-166A-D72E-40A9-A002-4804-4CC3-FF02
RxMessage M Lesen, Schreiben ohne Antwort None Lesen, Schreiben benötigt Verschlüsselung Wird verwendet, um eine Nachricht von einem Broker über einen Proxy zu empfangen. A9D7-166A-D72E-40A9-A002-4804-4CC3-FF03
TX LargeMessage M Lesen, Benachrichtigung None Lesen benötigt Verschlüsselung Wird verwendet, um eine große Nachricht (Nachricht > BLE-MTU-Größe) über einen Proxy an einen Broker zu senden. A9D7-166A-D72E-40A9-A002-4804-4CC3-FF04
RX LargeMessage M Lesen, Schreiben ohne Antwort None Lesen, Schreiben benötigt Verschlüsselung Wird verwendet, um große Nachrichten (Nachricht > BLE-MTU-Größe) von einem Broker über einen Proxy zu empfangen. A9D7-166A-D72E-40A9-A002-4804-4CC3-FF05
Anforderungen an das GATT-Verfahren
Lesen Sie Merkmalswerte zwingend erforderlich
Lesen Sie lange Merkmalswerte zwingend erforderlich
Merkmalswerte schreiben zwingend erforderlich
Schreiben Sie lange Merkmalswerte zwingend erforderlich
Lesen Sie Merkmalsdeskriptoren zwingend erforderlich
Schreiben Sie charakteristische Deskriptoren zwingend erforderlich
Benachrichtigungen zwingend erforderlich
Indikationen zwingend erforderlich
Arten von Nachrichten

Die folgenden Nachrichtentypen werden ausgetauscht.

Art der Nachricht Fehlermeldung Karte mit diesen Schlüssel/Wert-Paaren
0x01 CONNECT

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (1)

  • Schlüssel = „d“, Wert = Typ 3, Textzeichenfolge, Client-ID für die Sitzung

  • Schlüssel = „a“, Wert = Typ 3, Textzeichenfolge, Broker-Endpunkt für die Sitzung

  • Schlüssel = „c“, Wert = Einfacher Werttyp Wahr/Falsch
0x02 CONNACK

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (2)

  • Schlüssel = „s“, Wert = Typ 0 Ganzzahl, Statuscode

0x03 PUBLISH

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (3)

  • Schlüssel = „u“, Wert = Typ 3, Textzeichenfolge, Thema für die Veröffentlichung

  • Schlüssel = „n“, Wert = Typ 0, Ganzzahl, QoS für die Veröffentlichung

  • Schlüssel = „i“, Wert = Typ 0, Ganzzahl, Nachrichten-ID, nur für QoS 1-Veröffentlichungen

  • Schlüssel = „k“, Wert = Typ 2, Byte-Zeichenfolge, Nutzlast für die Veröffentlichung

0x04 PUBACK

  • Wird nur für QoS 1-Nachrichten gesendet.

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (4)

  • Schlüssel = „i“, Wert = Typ 0, Ganzzahl, Nachrichten-ID

0x08 SUBSCRIBE

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (8)

  • Schlüssel = „v“, Wert = Typ 4, Reihe von Textzeichenfolgen, Themen für das Abonnement

  • Schlüssel = „o“, Wert = Typ 4, Array von Ganzzahlen, QoS für das Abonnement

  • Schlüssel = „i“, Wert = Typ 0, Ganzzahl, Nachrichten-ID

0x09 U-BACK

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (9)

  • Schlüssel = „i“, Wert = Typ 0, Ganzzahl, Nachrichten-ID

  • Schlüssel = „s“, Wert = Typ 0, Ganzzahl, Statuscode für das Abonnement

0X0A UNSUBSCRIBE

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (10)

  • Schlüssel = „v“, Wert = Typ 4, Reihe von Textzeichenfolgen, Themen für die Abmeldung

  • Schlüssel = „i“, Wert = Typ 0, Ganzzahl, Nachrichten-ID

0x0B ABMELDEN

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (11)

  • Schlüssel = „i“, Wert = Typ 0, Ganzzahl, Nachrichten-ID

  • Schlüssel = „s“, Wert = Typ 0, Ganzzahl, Statuscode für UnSubscription

0X0C PINGREQ

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (12)

0x0D PINGRESP

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (13)

0x0E VERBINDUNG TRENNEN

  • Schlüssel = „w“, Wert = Typ 0 Ganzzahl, Nachrichtentyp (14)
Eigenschaften der Übertragung großer Nutzlasten
TX LargeMessage

TX LargeMessage wird vom Gerät verwendet, um eine große Nutzlast zu senden, die größer ist als die für die BLE-Verbindung ausgehandelte MTU-Größe.

  • Das Gerät sendet die ersten MTU-Bytes der Nutzlast als Benachrichtigung über das Merkmal.

  • Der Proxy sendet eine Leseanforderung für dieses Merkmal für die verbleibenden Byte.

  • Das Gerät sendet maximal die MTU-Größe oder die verbleibenden Byte der Nutzlast, je nachdem, welcher Wert niedriger ist. Jedes Mal wird der gelesene Offset um die Größe der gesendeten Nutzlast erhöht.

  • Der Proxy liest das Merkmal weiter, bis er eine Nutzlast mit der Länge Null oder eine Nutzlast erhält, die kleiner als die MTU-Größe ist.

  • Wenn das Gerät innerhalb eines bestimmten Timeouts keine Leseanforderung erhält, schlägt die Übertragung fehl und der Proxy und das Gateway geben den Puffer frei.

  • Wenn der Proxy innerhalb eines bestimmten Timeouts keine Leseantwort erhält, schlägt die Übertragung fehl und der Proxy gibt den Puffer frei.

RX LargeMessage

RX LargeMessage wird vom Gerät verwendet, um eine große Nutzlast zu empfangen, die größer ist als die für die BLE-Verbindung ausgehandelte MTU-Größe.

  • Der Proxy schreibt Nachrichten bis zur MTU-Größe nacheinander und verwendet dabei Write with Response für dieses Merkmal.

  • Das Gerät puffert die Nachricht, bis es eine Schreibanforderung mit einer Länge von Null oder einer Länge erhält, die kleiner als die MTU-Größe ist.

  • Wenn das Gerät innerhalb eines bestimmten Timeouts keine Schreibanforderung erhält, schlägt die Übertragung fehl und das Gerät gibt den Puffer frei.

  • Wenn der Proxy innerhalb eines bestimmten Timeouts keine Schreibantwort erhält, schlägt die Übertragung fehl und der Proxy gibt den Puffer frei.