LoRa STM32WB55
1.0.0
WIP
項目狀態：
主要思想是能夠在STM32WB55核板上使用Semtech Lora SX1272MB2DAS盾牌。不幸的是，ST（I-Cube-LRWAN）為此盾牌提供的代碼僅適用於幾個核板（L053RG，L073RZ，L152RE和L476RG）。
派生的想法是嫁給洛拉（Lora）和布萊（Ble），如今許多物聯網對象由於各種原因（設置，provisoning，fuota，...）都可以訪問，但主要是因為它與智能手機兼容。 STM32WL意甲沒有BLE，STM32WB Serie沒有Lora功能。
好吧，我有機會使用SX1272和WB55創建了一對，並為靈活的物聯網項目提供了兩個芯片組合。請記住，WB55意甲不僅限於BLE。協處理器固件可以處理2.4GHz側向協議，例如Zigbee和Openthread。因此，遠距離和短距離RF通信的結合很有趣。
該項目只是現有代碼和庫的一個端口，但可能會為某些開發人員節省設置時間，因為有一些技術問題需要解決。
隨著即將到來的Lora 2.4GHz，這被視為過渡工作。 SX1280將在單個芯片中結合短距離通信。您可能想仔細看看。
這很容易獲得。 SEMTECH SX1272MB2XAS LORA MBED SHIELD是Arduino兼容的盾牌，核板具有相應的連接器。技術簡介：
如前所述，STM32WB55意甲是這裡的目標，P-Nucleo-WB55RG是一個不錯的板子。技術簡介：
一旦連接起來（這是一個沒有腦袋），這就是結果對象。 
永遠不要忘記在為板上供電之前插入天線。您可能會損壞RF放大器輸出（儘管功率相當低）。當然，購買兩個是乒乓球的必要條件。
| 包裹 | 版本 |
|---|---|
| STM32Cubeide | 1.7 |
| STM32Cubemx | 6.3.0 |
| FW_WB | 1.12.1 |
| i-cube-lrwan | 2.0 |
該代碼的主要部分由ST和Semtech轉異式覆蓋。查看適當使用的各自協議：
| 成分 | 版權 | 執照 |
|---|---|---|
| 原始應用程序來源 | stmicroelectronic | ST許可協議SLA0044 |
| Lorawan®堆棧 | Semtech | BSD修訂後的Semtech零件許可 |
| Cortex®-M CMSIS | Arm Ltd | BSD-3-差價或Apache許可證2 |
我最喜歡的開發環境是Linux，但ST工具也可用於Mac和Windows。前兩個更容易設置，通常沒有問題或駕駛員問題。好吧，真正精通技術已經知道了。
儘管我不是IDE的忠實粉絲，但STM32Cudeide的工作正常，ST插件有幫助（MX，軟件擴展下載，...）。 Stmicro為某些Lora Shields提供了軟件擴展程序包。如上所述，它是I-Cube-lrwan，並包含示例項目和庫，例如低級SX1272驅動程序（通過SPI）和Lorawan堆棧（1.0.3兼容）。
該項目可以在沒有依賴項的情況下輕鬆地在STM32Cudeide中打開。所有代碼無需從St安裝WB或Lorawan Firmare。打開項目並構建它（在Linux和MacOS上進行了測試）。但是，您需要為CPU2安裝的BLE堆棧固件。在這裡， STM32WB5X_BLE_STACK_FULL_FW.BIN已閃爍。每個堆棧固件都在項目/STM32WB_COPRO_WIRESSE_BINARIES/STM32WB5X目錄中提供STM32CUBEWB固件軟件包以及如何為此編程板。它需要做一次。
整個實驗需要一些額外的工具。我將強大的NRF52840 USB加密狗與NRF Connect一起使用，可用於台式3.7.0（可在Linux，Mac和Windows上可用），從北歐半導體器中進行測試BLE連接。我知道智能手機可以做到這一點，我在iOS或Android上使用LightBlue，但是當您對UUID或設備的名稱弄亂時，平台往往會丟失其緩存的數據，因此我想弄清楚諸如Nordic over的開發工具的情況。
對於Lorawan的部分，TTN很棒，我選擇購買廉價的Lorawan Gateway，Ttig（比Rak Hats更便宜）用於本地測試。該網關是針對TTN服務的，但是必須有一種連接到您自己的LNS的方法。
那是第一步。使事情起作用，我選擇了低級RF傳輸示例。移植ST/SEMTECH代碼是針對重新配置WB55的問題。
Nucleo WB55板和SX1272MB2DAS盾牌之間的引腳映射：
| SX1272MB2DAS | P-Nucleo-STM32WB55 | Arduino Connector PIN名稱 |
|---|---|---|
| dio0 | PC6 | D2 |
| dio1 | PA10 | D3 |
| dio2 | PC10 | D4 |
| dio3 | PA15 | D5 |
| NSS | PA4 | D10 |
| Sclk | PA5 | D13 |
| 味o | PA6 | D12 |
| 莫西 | PA7 | D11 |
| 重置 | PC0 | A0 |
因此，首先看不到任何不兼容。 SPI1 PIN集匹配，NSS和RESET引腳也可以。但是，這是第一個帶有IRQ線路的Hickup。 PC6使用Exti6 IRQ行（Exti9_5_IRQN），這很好，但是PA10，PC10和PA15共享相同的Exti IRQ線，即Exti15_10_IRQN。
因此，對無線電接口定義進行了修改，以匹配Nucleo-WB55板（SX1272MB2DAS_CONF.H）。在調用相應的SX1272 IRQ處理程序之前，已經對IRQ處理程序進行了修改以檢查GPIO（DIOX）狀態（查看STM32WBXX_IT.C源文件）
RTC的時鐘源設置為LSE。
原始項目文件佈局也已進行了稍作修改。原始文件的集成已在MX生成的項目（SX1272.IOC）上進行，以保留更改項目的可能性。但是，某些謹慎的態度應該被視為可能產生的衝突代碼。
用此代碼編程兩個板，正如預期的那樣，第一個接收乒乓球響應ping消息的板變成掌握另一個板，將變成奴隸。我使LED狀態反映了這一點（如原始代碼中以前計劃）。一個人在短時間後閃爍紅色，另一個是綠色的LED閃爍：視頻。
BLE代碼是一個完全生成的MX。馬上必須在MX項目中正確設置一個工作（這可能是單獨的文章），這並不是一件直接的。我為此目的分開設置了一個BLE測試項目，一旦起作用，我就將代碼合併到Lora項目中，以使兩次運行並排。
因此，BLE測試軟件只是HRS（心率傳感器）外圍密碼。它基於一個完全不同的計時器框架，該框架稱為硬件計時器服務器（HW_TS）。 Semtech Lora庫不是基於此庫，而是基於STM32_Timer實用程序，該實用程序本身基於HAL RTC驅動程序。我刪除了實用程序庫和RTC適配器，因此整個項目僅依賴於HW_TS。 LORA庫實際上依賴一個易於重寫的中間API（Timer.H），因此使用HW_TS。另一方面，Ping Pong應用程序依賴於以前的公用事業庫。對此部分進行了一些更改，使整個代碼僅依賴於HW_TS。
我需要合併由PING PONG應用程序和BLE代碼定義的任務。幸運的是，兩者使用STM32_Sequencer實用程序。正確完成後，我成功地製作了Lora Ping Pong應用程序，並在STM32WB55板上同時且完美地運行了HRS BLE應用程序。
我修改了app_ble.c代碼，因此廣告（可見）名稱基於STM32 UDN，因此我們可以同時區分運行的板。
對於有用的演示，我寫了一項專用的Gatt服務，以便可以通過BLE詢問兩個板，以便您知道Lora Node具有哪個角色（主或從）以及已發送/接收的Ping/Pong的數量。為此，我對BLE代碼進行了稍微調整，因此藍色LED反映了BLE連接狀態。自定義服務（不是由MX生成的，太混亂了），具有兩個特徵，一個知道節點角色（Pingpong Synchronization後的主或從屬），另一個是接收到的Ping幀（從屬節點）或Pong Frames（主節點）的櫃檯。這是連接到兩個同步板的NRF連接的屏幕截圖： 
這樣，我寧願花更多的時間在由BLE控制的Lora應用程序上，這是下一步。
Lorawan堆棧是I-Cube-Lwan擴展包中提供的Semtech的堆棧。如果最終設備需要Lora Alliance認證，則為1.0.3符合認證軟件包，包括認證軟件包。
同樣，該代碼依賴於與BLE堆棧不同的RTC包裝器，因此已對其進行了修改。計時器的數量增加了，因為初始HW Timerver設置過於限制，無法同時運行兩個堆棧（修改後的IOC後更改了HW_IF.H文件）。
原始示例洛萬末端節點發送了一組非常完整的數據集，我將測試框架大大減少到了一個簡單的文本。
設備設置為使用OTAA加入網絡，因此需要3個元素：DEVEUI，JAINEUI和APPKEY。 DEVEUI是用於硬件設備的唯一標識符，並且是由STM32“序列號”構建的。 Joineui（或以前的AppEUI）標識符用於服務器端的應用程序分離。 Appkey非常重要（AES128密鑰），該ut被非常秘密地保持。源代碼任意將其設置為必須更改以最終使用的值。保密是使用Semtech代碼使用安全元素API完成的，在我們的情況下，這是虛擬的SE，但是如果您碰巧使用實際的元素，則非常方便。
joineui和appkey在se-nidentity.h文件中進行了硬編碼（ lorawan_app_key和lorawan_nwk_key必須是OTAA的值相同的值，後者用於計算麥克風，而JoineRequest對於在LNS上有效是必要的）。
用TTN和TTIG Gateway進行測試給出了這些：
對於聲明的部分。
一旦兩個董事會得到他們各自的JoinRequest的積極答复。
已經寫了一項特殊的GATT服務來公開：
| 屬性 | 使用權 | 評論 |
|---|---|---|
| 地位 | 讀 | 是否已完成 |
| Deveui | 讀 | 讀數的DEVEUI |
| 大約 | 讀 | 讀取硬編碼的Joineui/appeui |
| 數據 | 寫 | 將發送的數據（16個字節最多）。默認為“ STM32WB55！”！ |
| 時期 | 寫 | 在發送數據的幾秒鐘內（默認為10秒） |
| RSSI | 讀 | 收到下行鏈路消息時更新 |
| snr | 讀 | 收到下行鏈路消息時更新 |
注意：不要弄亂時期，佔空比的限制為1％。使用默認設置，該模塊每10秒發送15個字節。在SF7BW125處，這可以在〜7秒的最低時期完成。
在這裡，與之相關的暴露特徵的例證：
待續
