Die Bluetooth- Technologie bricht energisch ihren Platz im Internet der Dinge. Ein Teil dieser Technologie, Bluetooth LE ( Bluetooth Low Energy , auch bekannt als Bluetooth Smart , auch bekannt als BLE ), positioniert sich direkt als ideale Wahl für IoT ( Internet der Dinge ). Schwer zu widersprechen. BLE weiß bereits, wie man den Internetverkehr weiterleitet, Koordinaten in Räumen ermittelt, industrielle speicherprogrammierbare Steuerungen anschließt, WEB- Server unterstützt, Waagen, Thermometer, Herzfrequenzmesser, Oximeter, Blutdruckmessgeräte und viele andere Dinge anschließt. C bleViele Probleme, die mit Wi-Fi- Lösungen verbunden sind, werden automatisch behoben . Nicht lange vor dem Moment, in dem Geräte mit BLE mithilfe einer ZigBee- ähnlichen Technologie im MESH-Netzwerk organisiert werden können . Dies spiegelt sich bereits in der Bluetooth- Spezifikation 5.0 wider .

Daher habe ich bei der Entwicklung meines IoT- Moduls BLE bedingungslos der Verwendung von Wi-Fi vorgezogen . Ich werde den peripheren Teil des BLE- Netzwerks am Beispiel des K66BLEZ- Debugging-Moduls betrachten .

Hier möchte ich meinen Entwicklungsweg von der fast vollständigen Unkenntnis von BLE bis zur Serienproduktion beschreiben.

Die Vertrautheit mit dem K66BLEZ1- Modul wurde in folgenden Artikeln begonnen:

.
. FatFs
.

Das K66BLEZ- Modul verwendet den von NXP hergestellten MKW40Z160- Chip ( 48 MHz Cortex-M0 +, 160 KB Flash, 20 KB RAM ) als BLE- Transceiver . Der Chip ist insofern interessant, als er zusammen mit BLE auch als Transceiver von Signalen des Standards 802.15.4 fungieren kann . Und der Standard 802.15.4 ist , wie Sie wissen, der Träger der ZigBee- Technologie . Der ZigBee- Stack selbst für den MKW40Z wurde noch nicht veröffentlicht, es wird jedoch bereits eine Firmware angeboten, bei der 802.15.4 gleichzeitig mit BLE funktioniert . Ein Diagramm eines Teils eines Moduls mit einem BLE-Chip ist unten gezeigt.

(Klicken zum Vergrößern)

Anstelle des Chips MKW40 bereits Chip MKW41 mit einem Volumen von 128 KB RAM, 512 KB FlashKapazität und Unterstützung für alle gängigen Protokolle: BLE 4.2, BLE die Mesh, die ZigBee, Thread A, die IPv6 - 6LoBLE . Es gibt noch keine offene Dokumentation zum neuen Chip, aber er verspricht, mit MKW40 pin-kompatibel zu sein.

Der MKW40 BLE-Chip auf dem Modul wird über SPI- und I2C-Schnittstellen mit dem Hauptmikrocontroller MK66 verbunden. Die I2C-Schnittstelle verbindet den Chip auch mit dem Ladechip. Der Hauptkommunikationskanal ist auf der SPI-Schnittstelle mit einer Bitrate von 6 Mbit / s implementiert.

Das Debuggen des Programms im MKW40-Chip kann über die SWD-Schnittstelle mit dem JTAG-Adapter und über die Debugging-Schnittstelle UART0 erfolgen, die ebenfalls an den Debugger-Anschluss X4 ausgegeben wird.
NXP bietet mehr als zwei Dutzend Beispiele für die Implementierung verschiedener Anwendungen auf dem MKW40-Chip, darunter: Druck, Glukose, Temperatur, Näherungssensoren, Herzfrequenzmesser usw. Es gibt Anwendungen für drahtlosen UART und drahtlosen Bootloader.

Ich habe das NXP-Framework für diese Chips gründlich überarbeitet und neue Profile mit Demoprogrammen auf Windows-PCs erstellt, für die auf der PC-Seite kein separater Adapter erforderlich ist. Aber dazu später mehr.

Bluetooth LE ist schwer zu lernen. Der Grund ist die umfangreiche Spezifikation und eine große Anzahl ihrer kurzen Paraphrasen in der Dokumentation der Hersteller, die sofort mit einer ungewöhnlichen Terminologie beginnen. Fangen wir also damit an.

Dekodierung und Übersetzung von Begriffen und Abkürzungen, Slang.

Pairing — (). BLE . , PIN .
Bonding — (). BLE .
Device authentication — () , .
Advertising — BLE (). , , , .
Scanning — BLE . , .
Profile — . , , .
UUID — universally unique identifier. 128- .
BLE Host — . BLE , . GAP, GATT, GATT, L2CA.
BLE Controller — . BLE - Bluetooth.
HCI — Host Controller Interface. API BLE BLE .
GAP — Generic Access Profile, . layer (). . , BLE .
GATT — Generic Attribute Profile, . . — (, , ...) , , .. , UUID.
L2CA — Logical Link Control and Adaptation Layer. . , , , , . BLE .
SMP — Security Manager Protocol. . L2CA.
LTK — Long-Term Key. BLE .
IRK — Identity Resolving Key. .
CSRK — Connection Signature Resolving Key. .
RAND — 64- , LTK
EDIV — 16- , LTK
MITM — man-in-the-middle. .
Message integrity — .
— , . BSP (board support package), HAL (hardware abstraction layer), OSA (OS abstraction layer), (middleware) : , , .

Bei der Auswahl eines Chips für BLE habe ich eine kleine Analyse der Angebote der bekanntesten Hersteller durchgeführt. Am meisten interessierte mich die Komposition der vorgeschlagenen Software, Frameworks und Tools zum Debuggen von Zusammenstellungen, Zusammenstellungen und Assemblierungen für Projekte unter dem ARM-Kern. Ein wichtiger Faktor war die Kontinuität mit der IAR-Umgebung und dem RTOS MQX- Framework, die bei der Entwicklung der Anwendung auf dem Hauptprozessor des Moduls verwendet werden.

NORDIC SEMICONDUCTOR

Es stellt ein SDK für den Chip nRF51822 mit dem Kern der Cortex - M0 . Zusammengestellt in IAR, KEIL, GCC. Der BLE-Stapel wird durch eine monolithische Bibliothek ohne Quellcode namens SoftDevice dargestellt, in der alle APIs implementiert sind: GAP, GATT, L2CA, HCI. Um diese Bibliothek herum ist ein Framework mit Treibern aufgebaut. Das Framework enthält zwei RTOS: Keils RL-ARM RTX und FreeRTOS . Das Framework verwendet die Protobuf- Serialisierungstechnologie und das Segger RTT- Debugging .

Zusätzlich wird das nrf5 IoT SDK angeboten.. Es enthält die Quellcodes der Protokolle MQTT, COAP, TLS (aus dem MBED-Projekt), cJSON, lwip (kostenloser TCP / IPv4 / IPv6-Protokollstapel), Socket-Schnittstelle und IPv6-Adapter. Es gibt auch 6LoWPAN , jedoch ohne Quellcode.

Texas Instruments

Auf ARM werden nur 2-Kern-BLE-Chips CC2640 ( Cortex-M3 und Cortex-M0 ) hergestellt. Die entsprechenden Spezifikationen sind jedoch Bluetooth 4.2 . Zum Herunterladen wird SDK SimpleLink Bluetooth Low Energy Software Stack 2.2.0 bereitgestellt. Es wird von der eigenen Entwicklungsumgebung von Code Composer Studio kompiliert in der IAR-Umgebung. Es wird mit einem eigenen RTOS TI-RTOS 2.16 und einem entwickelten Framework für die BLE-Stack-Bibliotheken geliefert. SDK als eines der Szenarien beinhaltet die Verwendung eines externen Anwendungsprozessors - Simple Application Processor (SAP). Der CC2640- Chip selbst wird als Simple Network Processor (SNP) bezeichnet. Zwischen ihnen wird die Kommunikation unter einem Protokoll hergestellt, das als Unified Network Processor Interface bezeichnet wird(NPI). Auf der CC2640-Seite wird unbedingt TI-RTOS verwendet, auf der SAP-Prozessorseite können Sie RTOS nach eigenem Ermessen verwenden. Der Quellcode für das NPI-Protokoll wird mit dem SDK sowohl für die SAP-Seite als auch für die SNP-Seite geliefert. Dies ist die SimpleLink- Technologie .

Der BLE-Stack selbst ist in 3 vorkompilierte Bibliotheken ohne Quellen unterteilt: Host, Controller, HCI. Alle drei Bibliotheken arbeiten nur mit dem Cortex-M3-Prozessor, der Teil des CC2640-Chips ist. Zusätzlich zum Studium von TI-RTOS muss der Benutzer einen speziellen Softwaremechanismus oder ein spezielles Protokoll für die Interaktion mit dem BLE-Stack namens iCall studieren.

Mikrochip-Atmel

stellt ATBTLC1000 Bluetooth LE-Chips auf dem Cortex-M0-Kern her . Der gesamte Chipstapel wird in den ROM geschrieben. Auf der Atmel-Website wurden keine offenen Tools zum Programmieren dieser Chips gefunden. Stattdessen schlägt Atmel vor, einen externen Mikrocontroller für die Interaktion mit dem ATBTLC1000 zu verwenden. Software für einen externen Mikrocontroller und Beispiele finden Sie im Atmel Software Framework. Kompiliert in Atmel Studio (Shell für GCC) oder in IAR.

Cypress Semiconductor Corp.

produziert eine Familie programmierbarer BLE-Chips basierend auf dem Cortex-M0-Kern - PSoC 4: PSoC 4XX8 und PRoC CYBL1XX7X, die die Bluetooth 4.2- Spezifikation unterstützen . Projekte für Chips werden in einem speziellen IDE PSoC Creator erstellt. Die Chips von Cypress unterscheiden sich darin, dass es keine vorgefertigte Peripheriekonfiguration (UART, SPI, I2S, PWM usw.) gibt. Sie muss aus Bibliothekselementen in einem Schaltungseditor mit zusätzlichen Softwarebibliotheken erstellt werden. Dies soll eine gewisse Flexibilität bieten. Obwohl es dem Entwickler viel Arbeit hinzufügt. Ein konfiguriertes Projekt kann mit einer der folgenden Toolchains kompiliert werden: GCC, IAR, Keil. BLE gibt es eine der Bibliotheken. Der BLE-Stapel wird als vorkompilierte monolithische Bibliothek ohne Quellcodes geliefert, die den BLE-Host, den BLE-Controller und die HCI kombinieren. Das Unternehmen veröffentlichte jedoch den Quellcode für Android- und iOS-Anwendungen, die mit BLE arbeiten.

Siliziumlabore

stellt EFR32 Blue Gecko Bluetooth Smart SoCs auf der Basis des ARM Cortex-M4-Kerns her , der die Bluetooth 4.2- Spezifikation unterstützt . EFR32BG1P332F256GMxx-Chips können eine Leistung von bis zu 19,5 dBm liefern und einen separaten 868-MHz-Funkkanal mit einer Leistung von bis zu 20 dBm und einer Empfindlichkeit von 121,4 dBm kombinieren. Der Silicon Labs-Chip ist eine riesige Auswahl alternativer Pin-Funktionen und ein System namens Peripheral Reflex System(PRS). Obwohl die Peripherie nicht wie Cypress-Chips erstellt werden kann, ihre Verbindung zu den Pins jedoch nahezu willkürlich ist, ermöglicht das Vorhandensein von PRS die Interaktion miteinander, ohne dass ein Prozessor beteiligt ist. Der BLE-Stapel von Silicon Labs kann Ergebnisse der Profilerstellung von Bluetooth Developer Studio akzeptierenwas unten diskutiert wird. Silicon Labs bietet zwei Bluetooth-Stacks an. Eines davon ist für Bluegiga-Module konzipiert und unterstützt neben BLE auch reguläres Bluetooth. Der zweite Stapel entspricht der Spezifikation 4.2 und nur LE. Der BLE-Stapel wird als monolithische vorkompilierte Bibliothek ohne Quellen geliefert. Für die Option mit einem externen Mikrocontroller werden ein serielles Protokoll und eine API in den Quellen angeboten. Sowohl GCC, IAR als auch Keil können kompilieren. Alles wird in einer einzigen Entwicklungsumgebung erledigt. Simplicity Studio V4 . Das zugehörige Stack-Framework wird von RTOS nicht unterstützt. Im Quellcode von Simplicity Studio finden Sie jedoch Perlen wie Speex mit 8 kbit / s, die für die Übertragung von Sprache über BLE geeignet sind, sowie eine leistungsstarke Fenster-GUI von Segger.

STMicroelectronics

stellt Cortex-M0- basierte BlueNRG- Netzwerkcontroller-Chips her, die einen BLE-Stapel gemäß der Bluetooth 4.1- Spezifikation enthalten . Die Chips selbst sind nicht programmierbar, verfügen jedoch über eine serielle Anwendungsbefehlsschnittstelle (ACI), über die ein externer Mikrocontroller mit ihnen kommunizieren muss. Für ACI wurde ein Framework entwickelt, das als Teil der proprietären Entwicklungsumgebung STM32Cube von ST integriert werden kann.

CSR PLC

stellt keine BLE-Chips auf ARM Cortex her, ist aber an der Implementierung des MESH-Netzwerks auf Bluetooth- Modulen interessiert . Das Video ist hier . Die Quellcodes verschiedener BLE-Anwendungen für Android und iOS sind angelegt. Es gibt ein SDK.

Renesas

macht BLE-Chips auf seinem 16-Bit- RL78- Kern . Der BLE-Stack wird nur an Premium-Benutzer ausgegeben. Alle ihre eigenen - Compiler, RTOS, Host-Mikrocontroller. Es gibt jedoch ein Plug-In für Bluetooth Developer Studio

Dialog Halbleiter

bieten, wie sie behaupten, die kleinsten BLE-Chips an . Die Chips mit Flash-Speicher DA14583 (der Rest ist nur mit ROM) können jedoch nicht als die kleinsten bezeichnet werden - 5 x 5 mm. Der Kern des Cortex-M0 . Maximale Leistung 0 dBm . Unterstützung für Bluetooth 4.1- Spezifikation . Um das SDK von der Firma zu erhalten, müssen Sie sich registrieren und den Test bestehen. Aber mit solchen Chipparametern habe ich nicht einmal versucht, ein SDK zu bekommen.

Also die Quellen von MQTT, COAP, TLS, SPEEX, LwIP und so weiter. Diejenigen in verschiedenen SDKs sind für uns von geringem Interesse. Sie können frei auf Github gefunden werden, ohne an bestimmte Frameworks gebunden zu sein. Die Unterstützung für die Bluetooth 4.2-Spezifikation macht wenig, da es noch nicht möglich ist, sie auf einem PC zu verwenden.

Nischen-RTOS wie TI-RTOS oder spezielle Scheduler machen es uns schwer, sie zu meistern. Wir versuchen, solche Entscheidungen zu vermeiden.

Ich war erfreut, dass ich mich für die Lösung von Kinetis entschieden habe.

Was ist interessant am NXP Bluetooth LE-Stack für die Kinetis-Familie?

Der BLE-Stack für Kinetis wird wie andere in Form von vorkompilierten Bibliotheken geliefert. Um diese Bibliotheken herum wird ein Multitasking-Framework aufgebaut, das unabhängig vom Betriebssystem Treiber und eine Ebene der Hardwareabstraktion im Quellcode enthält. Das Framework kann so konfiguriert werden, dass es ohne Betriebssystem funktioniert, oder es kann verwendet werden. Ab sofort wird das Framework für FreeRTOS angepasst. Es interagiert jedoch mit FreeRTOS über einen zusätzlichen Satz von Funktionen, die als Abstraktionsschicht des Betriebssystems bezeichnet werden (OS-Abstraktion, OSA).

Dank OSA können Sie anstelle von FreeRTOS jedes andere Betriebssystem ersetzen, das Nachrichtenwarteschlangen, Präemptionen, Flags und Timer unterstützt. Zum Beispiel RTOS MQX. Stack wird seltsamerweise nur in der IAR-Umgebung kompiliert. Zum Glück ist dies in meinem Fall kein Problem.

Interessanter ist, dass der Stack in zwei Bibliotheken unterteilt ist - BLE-Host und BLE-Controller. Und die BLE-Hostbibliothek kann auf einem anderen Chip arbeiten.

Die Bibliotheken interagieren in diesem Fall über das HCI-Protokoll miteinander. Das heißt, Wo andere Hersteller ein anderes Kommunikationsprotokoll für die Interaktion der Anwendung auf dem externen Mikrocontroller mit dem BLE-Stack entwickeln (denken Sie an SimpleLink), bietet NXP eine Standardlösung an. Und vor allem können wir mit diesem Ansatz, bei dem der BLE-Host auf einen leistungsstärkeren externen Mikrocontroller umgestellt wird, die Funktionen unserer GATT-Datenbank und -Dienste erheblich verbessern.

Kurz über BLE

Eine offene Bluetooth-Spezifikation Version 4.2 finden Sie hier . Die Beschreibung der unteren BLE-Ebene ( Controller- Ebene ) ist darin als „Vol.6 Core System Package [Low Energy Controller-Volume]“ ab Seite 2544 enthalten. Die obere Ebene ( Host- Ebene ) mit einer Beschreibung des ATT-Protokolls und des GATT-Profils befindet sich in „Vol.3 Core System Package [Host Volume] ”des Dokuments ab Seite 1693.

Verwendeter Frequenzbereich

(Zum Vergrößern anklicken)

Drei Frequenzen (in der obigen Abbildung sind die Kanalnummern 37.38.39 angegeben) sind für adresslose Rundfunkpakete und der Rest für die Übertragung von Paketen beim Einrichten logischer Kommunikationskanäle zwischen Geräten vorgesehen. Ein bekanntes Merkmal von Bluetooth ist, dass bei der Übertragung von Paketen jedes nachfolgende Paket mit einer anderen Frequenz übertragen wird, die pseudozufällig aus der Liste der zulässigen ausgewählt wird.

Alle Daten in BLE-Paketen können verschlüsselt und authentifiziert werden. Eine dynamische zufällige Erzeugung von Geräteadressen und deren Identifizierung unter Verwendung von Hashing wird ebenfalls verwendet, d.h. Nachdem wir die Adresse des Geräts auf Sendung abgefangen haben, können wir sie nicht länger als 15 Minuten verwenden, da sich die Adresse gemäß einem uns in dieser Zeit unbekannten Algorithmus ändert.

BLE-Module können als unidirektionale Sender arbeiten, d.h. Senden Sie einfach einige Daten in Form von Werbepaketen, z. B. Temperatur, ohne eine bidirektionale Verbindung herzustellen. Hierzu kann der Datentyp in Werbepaketen verwendet werden, die als herstellerspezifische Daten gekennzeichnet sind . Ein Computer oder Tablet kann Daten von Hunderten solcher Sender ohne unnötige vorbereitende Schritte zum Suchen, Herstellen einer Verbindung, Eingeben eines PIN-Codes usw. empfangen.
Eine andere Möglichkeit, Daten ohne Installation eines Kommunikationskanals zu übertragen, ist die Übertragung im Anforderungs-Antwort-Modus (die Anforderung ist das ScanRequest- Paket , die Antwort des Moduls ist das ScanResponce- Paket ). Diese BLE unterscheidet sich erheblich von Wi-Fi, wo selbst für das einfachste Thermometer eine Verbindung hergestellt werden muss, die die Ressourcen des Routers beansprucht.

BLE-Protokollstapel

Die folgende Abbildung zeigt BLE, wie es ein Mikrocontroller-Programmierer sieht. Der BLE-Stack besteht aus zwei Softwareteilen: Host und Controller . Die Host- Software befasst sich mit Funktionen auf hoher Ebene zum Organisieren und Verwalten von Daten, Verbindungen, und der Controller verwaltet die physische Peripherie des Transceivers, arbeitet mit geheimen Schlüsseln und befasst sich mit anderen Funktionen auf niedriger Ebene. Die genannten Teile werden über die HCI- Softwareschnittstelle ( Host Controller Interface ) verbunden. In einer PC-Implementierung wird der Host- Teil auf einem Computer und der Controller- Teil auf einem Hardware-Transceiver ausgeführtBluetooth und das HCI- Protokoll werden meistens über USB übertragen . Bei der Implementierung auf dem Mikrocontroller arbeiten beide Teile auf demselben Chip, und die HCI- Schnittstelle wird einfach in eine direkte Datenübertragung von der Host-Task (Softwaremodul) zur Controller-Task (Softwaremodul) und umgekehrt umgewandelt.
In der Tat sieht der Programmierer mehrere Sätze von API auf Arbeits Host : bekannt als das GATT , die GAP, L2CA, einem SMP, der HCI . Mit der GAP-API wird der Betriebsmodus des Geräts eingestellt - Zentral, Peripherie, Beobachter, Sender und die Verbindung wird bei Bedarf hergestellt. Und mit der GATT-APIDas direkte Senden und Empfangen nützlicher Daten und deren Analyse werden durchgeführt.

(Zum Vergrößern anklicken)

Die meisten vorhandenen Geräte unterstützen derzeit BLE 4.1, obwohl Version 4.2 vorhanden ist.

Alle Unterschiede von Version 4.2 gegenüber der vorherigen beziehen sich speziell auf Verbesserungen im BLE-Teil: erhöhte Geschwindigkeit, die Fähigkeit zur Übertragung von IP-Protokoll- und HTTP-Verkehr, erhöhter kryptografischer Schutz und Unkenntlichkeit für externe Beobachter.

Ein wichtiges Merkmal von BLE im Vergleich zu Wi-Fi ist die Angabe nicht nur des Kommunikationskanals, sondern auch der Anwendungen, die ihn selbst verwenden. Dies wird als Profile und Dienste bezeichnet. Profile mit Diensten beschreiben die Rollen von Geräten, den Zweck der Daten, die Zusammensetzung und das Format der Daten, den Datenschutz, die Reihenfolge, Arten und Ereignisse des Austauschs und nicht nur die Art und Weise, wie die Daten übertragen werden. Auf diese Weise können Sie das Rad nicht neu aus den Protokollen erfinden, wenn Sie beispielsweise einen Körpertemperatursensor oder einen Pulsmesser entwickeln. Spezifikationen wurden bereits angegeben, es bleibt nur auf der Geräteseite, um die notwendigen Felder zum Senden der Messergebnisse auszufüllen. Kunden solcher Geräte in Form von Smartphones, Tablets, PCs oder Küchengeräten erkennen diese Daten automatisch und zeigen sie an oder verwenden sie entsprechend. Alles dankdass alle Hersteller die gleichen BLE-Spezifikationen bezüglich der Darstellung von Temperatur- oder Herzfrequenzdaten und der Arbeit mit ihnen befolgen. Es gibt jedoch noch Raum für die Vorstellungskraft des Entwicklers, da Profile Mechanismen zur Erweiterung der Funktionalität aufweisen.

Das Folgende ist eine grobe Hierarchie von Attributen in einem BLE-Gerät.

(Zum Vergrößern anklicken)

Unten finden Sie einen etwas detaillierteren typischen Attributbaum. Dies ist kein vollständiger Baum, die meisten werden weggelassen, da er zu viel Platz beanspruchen würde. Farben markieren Baumebenen, jedes Attribut hat eine eindeutige Nummer - UUID. Das Aufzeichnen von Standardnummern wird auf 16 Bit reduziert. In dieser Abbildung sind alle Zahlen Standard. GAP- und GATT-Profile werden ebenfalls als Services mit ihren Standardfunktionen dargestellt. Jeder Dienst kann über ein eigenes Sicherheitsmodell und eine eigene Berechtigung verfügen. Der gesamte Baum im Gerät wird als Datenbank namens GATT-Datenbank gespeichert, normalerweise in Form einer einfachen Tabelle mit Querverweisen.

(Zum Vergrößern anklicken)
Serviceeigenschaften haben viele Eigenschaften, wie unten gezeigt. Hier muss man sich für die Tautologie entschuldigen, aber in BLE gibt es wirklich eine Art Terminologiekrise. Mit einem Wort, die Merkmale des dazugehörigen Dienstes können das Lesen, Schreiben, die Notwendigkeit von Benachrichtigungen, Bestätigungen, Signaturen usw. spezifizieren.

(Zum Vergrößern anklicken)

BLE ist eine seriöse Technologie. Es wurde so viel getan, um Sicherheit und maximale Formalisierung zu gewährleisten, was wiederum das Erreichen der Kompatibilität erleichtern sollte.

Der Datenaustausch zwischen BLE-Geräten erfolgt durch Schreiben und Lesen der Werte der Merkmale. Streaming-Kanäle wie TCP oder UART sind nicht hier. Und wenn die Geräte über sie verfügen, werden sie von Software-Add-Ons einer höheren Ebene organisiert.

Entwicklungswerkzeuge

Entwicklungstools mit der vorgeschlagenen Bluetooth Special Interest Group (Bluetooth SIG) -Site - https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools

Die folgenden nützlichen Tools werden auf der Site der Hauptstandardisierungsorganisation - Bluetooth SIG - angeboten :

Bluetooth Developer Studio

Bluetooth Developer Studio ist ein Tool, mit dem Sie Profile, Dienste, Merkmale und Deskriptoren korrekt erstellen und in die Implementierung eines BLE- Geräts einfügen können , d. H. Erstellen Sie eine Datenbank. Wenn Sie einen zusätzlichen Hardware-Bluetooth-Adapter für 99 US-Dollar kaufen , können Sie mit dem Programm Bluetooth-Protokollpakete abfangen , entschlüsseln und anzeigen. Das Programm kann auch die erstellten Dienste debuggen und testen.

Weil in BLEGenehmigte Profile werden ausführlich beschrieben, auch kleinere Fehler in Bezug auf Format, Nummerierung, Zugänglichkeit usw. In diesen Profilen treten Kompatibilitätsprobleme auf. Bei nicht standardmäßigen Profilen ist es jedoch sehr schwierig, auf ein Tool zu verzichten, das einen Baum von Diensten, Merkmalen und Deskriptoren in Übereinstimmung mit allen Spezifikationen genau erstellt. Es ist leicht, die Namen von Diensten, Merkmalen, Deskriptoren und deren eindeutigen Multi-Byte-Nummern ( UUID) zu verwechseln .

Das Ergebnis des Tools sind insbesondere die generierten XML- Dateien, die Profile, Dienste, Merkmale und Deskriptoren im Projekt des Benutzers beschreiben. Diese XML-Dateien werden direkt von Silicon Labs Simplicity IDE verwendet, um sie für ihre Chips in eingebettete Projekte zu integrieren.

(Zum Vergrößern anklicken)

Ein weiteres Ergebnis des Tools kann der Quellcode für das Gerät sein, das mit der BLE- Datenbank arbeitet . Dafür muss der Benutzer sein Plugin in JavaScript schreiben . Das Programm bietet auch Plug-in - Benutzer Zugriff auf die Datenbank über eine spezielle API zu JavaScript .
Es gibt eine Reihe vorgefertigter Plug-Ins , die verschiedene Quelltextdateien generieren, die für die Kompilierung in Umgebungen und Software-Frameworks von Drittanbietern geeignet sind.

Es gibt noch keine Plugins für Lösungen, die auf dem NXP Kinetis KW40Z Connectivity Software Framework basieren .

Anwendungsbeschleuniger

Application Accelerator 2.1 - eine Reihe von Demo-Projekten mit Quelltexten für verschiedene Android 6- Betriebssysteme . 0 , Blackberry , iOS 9 , Tizen 2 . 4 und Windows 10 . Unter Windows 10 gelten Projekte nur für die Visual Studio- Entwicklungsumgebung für die UWP- Architektur (Universal Windows Platform). Das heißt, Diese Projekte können nicht unter Windows Forms oder WPF c .NET Frameworks kompiliert werden . Und Brücken für die Übersetzung regulärer Windows-Anwendungen in UWPgerade erstellt werden.

Es ist zu beachten, dass UWP das Platzieren von Anwendungen im Windows Store ermöglicht , jedoch keine einfache ausführbare EXE- Datei erstellt, die Sie einfach kopieren und ausführen können. Der erste Start einer UWP- Anwendung wird immer von einer Installation begleitet. All dies schafft Schwierigkeiten für den Entwickler. Und die Funktionalität der Demonstrationsprojekte lässt zu wünschen übrig.

(Zum Vergrößern anklicken)

Oben sehen Sie einen Screenshot der einzigen Demo-Anwendung für Windows - BLEServiceBrowser .

Gateway Smart Satarter Kit

Das Starter Kit die Smart - Gateway - Projekt Gateway - BLE - Geräte an den WEB - Server und selbst WEB - Server implementiert die Benutzerschnittstelle für die Netzwerk - BLE - Geräte. Alles ist in Node.js implementiert. Es wird vorgeschlagen, auf einem Raspberry Pi 2 Modell B- Mikrocomputer mit dem Raspbian Jessie- Betriebssystem bereitzustellen . Der direkte Anschluss des Raspberry Pi an BLE- Geräte erfolgt über die Bluetooth-HCI- Schnittstelle von Sockets auf L2CAP- Ebene und USB-HCIAdapter. Um unter Windows ausgeführt zu werden, müssen Sie einen speziellen Ersatz für den Standard- Bluetooth-HCI- Treiber installieren . Die Lösung funktioniert aufgrund des begrenzten HCI-Treibers mit einer sehr begrenzten Anzahl von Arten von Hardwareadaptern.

Peryton

Unter den kommerziellen Tools ist das Analyseprogramm ein interessanter BLE-Verkehrsanalysator von Perytons . Der Analysator läuft auf Windows-PCs ab Version 7. Dies ist ein wichtiger Punkt, da native BLE-Treiber für Windows erst ab Version 8 funktionieren. Der Analysator arbeitet mit einer begrenzten Liste von Hardware-BLE-Adaptern .

Bei der Arbeit mit Adaptern gibt es auch Einschränkungen bei der Analyse, die durch die Verkehrsverschlüsselung in BLE verursacht werden.

(Zum Vergrößern anklicken)

Selbst mit der Testversion des Programms können Sie jedoch viele Vorteile erzielen. Das Programm wird von Demonstrationsaufzeichnungen von Interceptions begleitet, die reale Geräte austauschen. Diese Datensätze geben nach dem Laden in das Programm ein detailliertes Bild des Betriebs des gesamten BLE-Protokollstapels. Das Anzeigen eines solchen Abfangens ersetzt das Erkunden der gesamten Bluetooth-Spezifikation.

Bushund

Wenn Sie nur irgendwie die Aktivität zwischen dem Computer und dem BLE-Gerät überwachen müssen und auf eine detaillierte Analyse des Protokolls verzichten können, ist der bekannte Windows-Treiber-Verkehrsabfangjäger namens Bus Hound ausreichend .

Im folgenden Screenshot sehen Sie den Stream der empfangenen Werbepakete. Die Ungleichmäßigkeit der Paketempfangszeitintervalle ist deutlich sichtbar. Dies weist auf einen signifikanten Paketverlust hin. Das Timeout-Intervall für das BLE-Gerät wurde auf 20 ms eingestellt.

(Zum Vergrößern anklicken) Der folgende

Screenshot zeigt die Darstellung des BLE-Geräts im Bus Hound-Fenster nach dem Pairing mit einem PC. Für jeden Gerätedienst wird nach dem Peering ein logischer Kommunikationskanal angezeigt. Hier sehen Sie die UUID des Geräts und der Dienste.

BLE Verkehrsanalysator (Sniffer) USB-KW40Z

Dies ist ein Tool aus dem Kinetis Development Support Kit. Deshalb werde ich näher darauf eingehen. NXP- Sniffer-Seite .

Der Sniffer wurde von NXP (oder besser gesagt dem früheren Freescale) entwickelt und kann kostengünstig in beliebten Online-Funkkomponentengeschäften erworben werden: Mouser, Digi-Key, Farnell ... Er wird von NXP als Tool zur Überwachung von Funkpaketen angeboten, die von BLE-Geräten gesendet werden.

Mit diesem Gerät können Sie die Struktur von Paketen untersuchen, sie in einem Protokoll aufzeichnen und die Verkehrsdichte analysieren. Die Sniffer-Schaltung ist offen für Studien, aber das Mikrocontroller-Programm wird als Binärdatei geliefert. Mit Sniffer können Sie Pakete nach Adresswerten filtern.

Sie können die PC-Software für den Sniffer über die folgende Suchabfrage auf der Website www.nxp.com herunterladen - Kinetis_Protocol_Analyzer_Adapter.exe

Da der Sniffer neben der Hauptfunktion auch eine Debugging-Plattform für verschiedene Anwendungen sein kann, werden binäre grundlegende Firmware-Dateien daran angehängt Sie können die Sniffer-Funktionalität nach dem Experimentieren wiederherstellen. Dateien werden mit dem KW40Z Connectivity Software- Paket geliefert , das von www.nxp.com für die Suchabfrage KW40Z_Connectivity_Software heruntergeladen wird. Die Dateien heißen Sniffer_processing_core_usbkw40z_k22f.bin (für den Mikrocontroller MK22FN512 auf der Sniffer- Karte ) und Sniffer_radio_core_usbkw40z_kw40z.bin(für den Mikrocontroller MKW40Z auf der Sniffer-Karte). Dateien werden mit SWD-Debuggern programmiert: JLink, STLink, OpenSDA ...

Von der PC-Seite wird das Gerät als zusammengesetztes USB-Gerät mit einem COM-Port und einem Debug-Port gemäß der Spezifikation OpenSDA mit CMSIS-DAP-Firmware wahrgenommen. In der IAR-Umgebung können Sie den MKW40Z-Sniffer-Chip frei programmieren und debuggen, indem Sie seinen anderen MK22FN512-Chip als Träger für die Funktionalität des Debug-Adapters verwenden. Beide Chips auf der Platine verfügen jedoch über Standard-SWD-Anschlüsse für einen externen Debug-Adapter.

Sniffer garantiert nicht den Empfang aller in der Luft übertragenen Pakete. Es ist leicht zu überfluten, wonach keine Pakete mehr akzeptiert werden. Daher wird empfohlen, die Filterung nach Adresse zu aktivieren, um nur Pakete vom interessierenden Knoten mit relativ seltenem Datenverkehr zu empfangen.

Das folgende Fenster zeigt das Paketanalysatorprogramm. Das Fenster enthält das Abfangen auf allen drei Kanälen:

(Zum Vergrößern anklicken)

Bei der Installation der Analysesoftware auf einem PC wird ein virtueller Ethernet-Adapter erstellt, der über den virtuellen COM-Port des Sniffers aufgenommene Pakete in Ethernet-Pakete konvertiert. In meinem Fall erhielt ein solcher virtueller Adapter automatisch einen einfachen Namen - Ethernet.
Um die Pakete anzuzeigen, müssen Sie zusätzlich das Wireshark Ethernet Packet Sniffer-Programm installieren.

Ansicht des Hauptfensters des Wireshark-Programms während der Überwachung des Datenverkehrs. Wireshark beschreibt ausführlich alle Bitfelder des LE LL-Protokollpakets (Link Layer). Nach dem Herstellen einer Verbindung zwischen den Geräten und dem Starten des L2CAP-Protokolls wird der Paketinhalt jedoch nicht erkannt, da er verschlüsselt übertragen wird.