LoRa STM32WB55
1.0.0
Wip
Projektstatus:
Die Hauptidee besteht darin, Semtech Lora SX1272MB2DAS Shield auf einer STM32WB55 -Nucleo -Platine zu verwenden. Leider ist der von ST (I-Cube-Lrwan) für diesen Schild verfügbare Code nur für einige Nucleo-Boards (L053RG, L073RZ, L152RE und L476RG) erhältlich.
Die abgeleiteten Ideen sind es, Lora und Ble zu heiraten. Heutzutage sind viele IoT -Objekte aus verschiedenen Gründen (Einstellungen, Provisoning, Fuota, ...) zugänglich, aber vor allem, weil es mit Smartphones kompatibel ist. Die STM32WL -Serie hat kein Ble und die STM32WB -Serie hat keine Lora -Funktionen.
Nun, ich hatte die Möglichkeit, ein Paar mit SX1272 und WB55 zu erstellen und eine zwei -Chip -Kombination für ein flexibles IoT -Projekt zu ermöglichen. Denken Sie daran, dass die WB55 -Serie nicht auf Ble beschränkt ist. Die Coprozessor -Firmware kann 2,4 -GHz -Seitenprotokolle wie Zigbee und Openenthrader verarbeiten. Daher ist die Kombination aus Reichweite und kurzer Reichweite HF -Kommunikation interessant.
Dieses Projekt ist nur ein Port mit vorhandenen Codes und Bibliotheken, kann jedoch für einige Entwickler die Einrichtungszeit sparen, da einige technische Probleme zu lösen sind.
Mit dem kommenden Lora 2.4GHz gilt dies als Übergangsarbeit. Der SX1280 kombiniert die kurze und langfristige Kommunikation in einem einzigen Chip. Vielleicht möchten Sie einen genaueren Blick darauf werfen.
Das ist leicht zu kommen. Der Semtech SX1272MB2XAS LORA MBED Shield ist Arduino -kompatibler Schild, und Nucleo -Boards haben den entsprechenden Stecker. Technischer Brief:
Wie bereits erwähnt, ist die STM32WB55-Serie das Ziel hier und das P-Nucleo-wb55RG ist ein schönes Board, mit dem man spielen kann. Technischer Brief:
Sobald es angeschlossen ist (es ist ein Kinderspiel) hier ist das resultierende Objekt. 
Vergessen Sie niemals, die Antenne zu schließen, bevor Sie die Boards erhöhen. Sie können den RF -Verstärkerausgang beschädigen (obwohl es sich um eine ziemlich geringe Leistung handelt). Natürlich ist der Kauf von jeweils zwei von jedem für die Ping -Pong erforderlich.
| Paket | Version |
|---|---|
| STM32Cubeid | 1.7 |
| STM32CUBEMX | 6.3.0 |
| Fw_wb | 1.12.1 |
| I-Cube-Lrwan | 2.0 |
Der Hauptbestandteil des Codes wird von ST und Semtech Sublicensing abgedeckt. Überprüfen Sie die jeweiligen Vereinbarungen zur ordnungsgemäßen Verwendung:
| Komponente | Copyright | Lizenz |
|---|---|---|
| Ursprüngliche Anwendungsquelle | Stmicroelektronisch | ST Lizenzvereinbarung SLA0044 |
| Lorawan® Stapel | Semtech | BSD überarbeitete lizenzierte für Semtech -Teile |
| Cortex®-M CMSIS | Arm Ltd | BSD-3-Klausel oder Apache-Lizenz 2 |
Meine bevorzugte Entwicklungsumgebung ist Linux, aber auch ST -Tools sind für Mac und Windows verfügbar. Die ersten beiden sind einfacher zu richten, normalerweise keine Probleme oder Fahrerprobleme. Nun, echte Tech -Verständniser wissen das schon.
Obwohl ich kein großer Fan von IDES bin, funktioniert STM32Cudeide in Ordnung und ST -Plugins haben geholfen (MX, Software -Erweiterungen Download, ...). STMICRO bietet ein Software -Erweiterungspaket für einige Lora Shields. Wie oben verknüpft, ist es der I-Cube-Lrwan und enthält Beispielprojekte und Bibliotheken wie SX1272-Treiber mit niedrigem Niveau (über den SPI) und den Lorawan-Stack (1.0.3 kompatibel).
Das Projekt kann in STM32Cudeide ohne Abhängigkeiten leicht geöffnet werden. Der gesamte Code ist nicht erforderlich, um WB oder Lorawan Firmare von ST zu installieren. Öffnen Sie das Projekt und erstellen Sie es (getestet unter Linux und MacOS). Sie benötigen jedoch die für CPU2 installierte BLE -Stack -Firmware. Hier wurde STM32WB5X_BLE_STACK_FUL_FW.bin geblitzt. Jede Stacks -Firmware ist in Projekten/STM32WB_COPRO_WIRELESS_BINARYS/STM32WB5X -Verzeichnissen von STM32Cubewb -Firmware -Paket sowie zum Programmieren der Boards dafür bereitgestellt. Es muss einmal erledigt werden.
Das gesamte Experiment brauchte einige zusätzliche Werkzeuge. Ich habe den mächtigen NRF52840 -USB -Dongle mit NRF Connect für Desktop 3.7.0 (verfügbar unter Linux, Mac und Windows) von Nordic Semiconductor verwendet, um die BLE -Verbindung zu testen. Ich weiß, dass Smartphones das können, ich verwende Lightblue auf iOS oder Android, aber wenn Sie sich mit Uuids oder Geräten benennen, werden die Plattformen dazu, mit ihren zwischengespeicherten Daten verloren zu gehen. Deshalb möchte ich herausfinden, was mit Entwicklungswerkzeugen wie nordischen Geräte los ist.
Für den Lorawan -Teil ist TTN einfach großartig und ich habe mich entschieden, ein kostengünstiges Lorawan -Tor zu kaufen, ein TIG (billiger als Rak -Hüte für Raspberry Pi) für lokale Tests. Das Gateway ist für TTN -Dienste festcodiert, aber es muss eine Möglichkeit geben, sich mit Ihren eigenen LNs zu verbinden.
Das war der allererste Schritt. Dinge zum Laufen bringen und ich habe das Beispiel für das HF -Übertragungsbeispiel für niedrige Ebene dafür gewählt. Das Portieren des ST/Semtech -Codes war eine Frage der Umstellung des WB55 zu::
Pin -Mapping zwischen der Nucleo WB55 -Karte und dem SX1272MB2DAS -Schild:
| SX1272MB2DAS | P-Nucleo-STM32WB55 | Arduino Connector Pin Name |
|---|---|---|
| DIO0 | PC6 | D2 |
| DIO1 | Pa10 | D3 |
| DIO2 | PC10 | D4 |
| DIO3 | PA15 | D5 |
| NSS | PA4 | D10 |
| Sclk | PA5 | D13 |
| Miso | PA6 | D12 |
| Mosi | PA7 | D11 |
| ZURÜCKSETZEN | PC0 | A0 |
Also nichts Unvereinbares auf den ersten Blick. SPI1 -Pin -Set -Streichhölzer, NSS und Reset -Stifte sind auch in Ordnung. Aber hier kommt der erste Hickup mit den IRQ -Linien. PC6 verwendet die Exti6 IRQ -Linie (exti9_5_irqn), das ist in Ordnung, aber PA10, PC10 und PA15 teilen sich die gleiche Exti -IRQ -Linie, dh exti15_10_irqn.
Daher wurde die Definition von Funkgrenzflächen so modifiziert, dass sie mit der Nucleo-WB55-Karte (SX1272MB2DAS_CONF.H) übereinstimmt. Und die IRQ -Handler wurden geändert, um die GPIO -Zustände (DIOX) zu überprüfen, bevor die entsprechenden SX1272 IRQ -Handler aufgerufen werden (siehe STM32WBXX_IT.C -Quelldatei)
RTC hat die Taktquelle auf LSE eingestellt.
Das ursprüngliche Projektdateilayout wurde ebenfalls leicht geändert. Die Integration der Originaldateien wurde in ein MX -generiertes Projekt (SX1272.IOC) erstellt, um die Möglichkeit zur Änderung des Projekts zu erhalten. Einige vorsichtig sollten jedoch als widersprüchlicher Code generiert werden.
Das Programmieren von zwei Boards mit diesem Code funktioniert und wie erwartet wird das erste Board, das eine Pong -Antwort auf eine Ping -Nachricht erhält, zum Meister des anderen wird zum Sklaven . Ich machte den LED -Status dies wider (wie früher im Originalcode geplant). Einer blinzelt rot, wo die andere nach kurzer Zeit die grüne LED blinkt: Video.
Der BLE -Code ist ein vollständig erzeugter MX. Einen, der sofort funktioniert, war nicht einfach, da viele Dinge im MX -Projekt richtig eingestellt werden müssen (das könnte einen separaten Artikel). Zu diesem Zweck habe ich ein Ble Tester -Projekt separat eingerichtet, sobald ich den Code in das LORA -Projekt zusammengefügt habe, um die beiden nebeneinander zu machen.
Die BLE -Testsoftware ist also nur ein HRS -Peripheriecode (Herzfrequenzsensor). Es basiert auf einem völlig anderen Timer -Framework, das als Hardware -Timer -Server (HW_TS) bezeichnet wird. Die Semtech Lora -Bibliothek basiert nicht auf diesem, sondern auf einem STM32_Timer -Dienstprogramm, das selbst auf dem Hal -RTC -Treiber basiert. Ich habe den Utility Library und den RTC -Adapter entfernt, damit das gesamte Projekt nur auf HW_TS angewiesen ist. Die LORA -Bibliothek basiert tatsächlich auf eine Zwischen -API (Timer.H), die leicht neu zu schreiben war, sodass HW_TS stattdessen verwendet wird. Die Ping -Pong -Anwendung dagegen stützt sich auf die frühere Versorgungsbibliothek. Einige Änderungen an diesem Teil ließen den gesamten Code nur auf HW_TS beruhen.
Ich muss die von der Ping -Pong -Anwendung und des BLE -Code definierten TaskIds zusammenführen. Glücklicherweise verwenden die beiden das Dienstprogramm STM32_sequencer . Nach ordnungsgemäßer Fertigstellung habe ich die Lora Ping -Pong -Anwendung und eine HRS -Anwendung, die gleichzeitig und makellos auf dem STM32WB55 -Board ausgeführt wird, erfolgreich gestellt.
Ich habe den Code von app_ble.c geändert, damit der Name des Werbe (sichtbar) auf STM32 UDN basiert, sodass wir gleichzeitig die Boards unterscheiden können.
Für eine nützliche Demo habe ich einen dedizierten GATT -Service geschrieben, damit beide Boards über Ble befragt werden können, sodass Sie wissen, welche Rolle der Lora -Knoten (Master oder Slave) und die Anzahl der gesendeten/empfangenen Ping/Pongs hat. Dafür habe ich den BLE -Code leicht angepasst, sodass Blue LED den BLE -Verbindungszustand widerspiegelt. Der benutzerdefinierte Dienst (nicht von MX generiert, er ist zu chaotisch), hat zwei Eigenschaften, eine, die die Knotenrolle kennen (Master oder Slave nach Pingpong -Synchronisation) und einen anderen, der ein Zähler der empfangenen Ping -Frames (Slave -Knoten) oder Pong -Rahmen (Masterknoten) ist. Hier ist der Screenshot von Nrf Connect, der mit den beiden synchronisierten Boards verbunden ist: 
Nachdem ich es getan habe, habe ich es vorgezogen, mehr Zeit für eine etwas andere LORA -Anwendung zu verbringen, die von BLEL kontrolliert wird, was der nächste Schritt ist.
Der Lorawan Stack ist der von Semtech, der im Expansionspaket I-Cube-Lrwan bereitgestellt wird. Es ist 1,0.3 konform und enthält Zertifizierungssoftwarepaket, wenn die LORA Alliance -Zertifizierung für das endgültige Gerät benötigt wird.
Auch hier basiert der Code auf einem anderen RTC -Wrapper als dem BLE -Stapel, so dass er dafür geändert wurde. Die Anzahl der Timer wurde erhöht, da die anfängliche HW -TimerServer -Einstellung zu begrenzt ist, um die beiden Stapel gleichzeitig auszuführen (HW_IF.H -Datei wurde nach dem geänderten IOC geändert).
Das ursprüngliche Beispiel, Lorawan Endknoten, sendet einen sehr vollständigen Datensatz. Ich habe den Testrahmen drastisch auf einen einfachen Text reduziert.
Das Gerät soll das Netzwerk mithilfe von OTAA beitreten, sodass 3 Elemente benötigt werden: Deveui, Joineui und Appey. Deveui ist eine eindeutige Kennung für ein Hardware -Gerät und wurde aus STM32 "Seriennummer" erstellt. Die Identifikatorin Joineui (oder ehemaliger Appeui) wird für die Anwendungstrennung auf der Serverseite verwendet. Der Appey ist sehr wichtig (ein AES128 -Schlüssel), der sehr heimlich aufbewahrt wird. Der beliebige Quellcode setzen es auf einen Wert, der für die endgültige Verwendung geändert werden muss. Die Geheimhaltung erfolgt mit Semtech Code mit einer sicheren Element -API, in unserem Fall ist es ein virtuelles SE, aber dies ist sehr bequem, wenn Sie zufällig eine tatsächliche verwenden.
Joineui und Appey sind in der Datei se-identity.h fest codiert ( Lorawan_app_key und lorawan_nwk_key müssen die gleichen Werte für OTAA sein. Letzteres wird verwendet, um das Mikrofon zu berechnen und ist erforderlich, damit die joinsRequest auf LNs gültig ist).
Das Testen mit TTN und Ttig Gateway gibt diese:
Für den deklarativen Teil.
Sobald die beiden Boards eine positive Antwort von ihrem jeweiligen JoinRequest hatten.
Ein besonderer GATT -Service wurde geschrieben, um aufzudecken:
| Attribut | Zugang | Kommentar |
|---|---|---|
| Status | Lesen | Ob der JoinRequest abgeschlossen ist oder nicht |
| Deveui | Lesen | Anzeige von Computer Deveui |
| Joineui | Lesen | Auslese von hartcodierten joineui/appeui |
| Daten | Schreiben | Daten, die gesendet werden (16 Bytes max.). Standardeinstellungen zu "STM32WB55 HIER!" |
| Zeitraum | Schreiben | Zeitraum in Sekunden, an denen Daten gesendet werden (Standardeinstellungen bis 10 Sekunden) |
| RSSI | Lesen | Aktualisiert, wenn die Downlink -Nachricht empfangen wird |
| Snr | Lesen | Aktualisiert, wenn die Downlink -Nachricht empfangen wird |
HINWEIS: Legen Sie sich nicht mit der Zeit an, es gibt eine Arbeitszyklusbeschränkung von 1%. Mit den Standardeinstellungen sendet das Modul alle 10 Sekunden 15 Bytes. Bei SF7BW125 kann dies zum niedrigsten Zeitraum von ~ 7 Sekunden durchgeführt werden.
Hier ist eine Illustration der exponierten Eigenschaften, wenn sie damit verbunden sind:
fortgesetzt werden
