เช็ด
สถานะโครงการ:
แนวคิดหลักคือการใช้ Semtech Lora SX1272MB2DAS Shield บนกระดานนิวเคลียส STM32WB55 น่าเสียดายที่รหัสที่มีให้โดย ST (I-Cube-Lrwan) สำหรับโล่นี้มีให้สำหรับบอร์ดนิวเคลียสเพียงไม่กี่ตัวเท่านั้น (L053RG, L073RZ, L152RE และ L476RG)
ความคิดเชิงอนุพันธ์คือการแต่งงานกับ Lora และ BLE ทุกวันนี้วัตถุ IoT จำนวนมากสามารถเข้าถึงได้ด้วยเหตุผลหลายประการ (การตั้งค่าที่พิสูจน์แล้ว Fuota, ... ) แต่ส่วนใหญ่เป็นเพราะเข้ากันได้กับสมาร์ทโฟน STM32WL Serie ไม่มี BLE และ STM32WB Serie ไม่มีความสามารถของ LORA
ฉันมีโอกาสสร้างคู่กับ SX1272 และ WB55 และอนุญาตให้มีการรวมชิปสองชุดสำหรับโครงการ IoT ที่ยืดหยุ่น โปรดทราบว่า WB55 Serie ไม่ได้ จำกัด อยู่ที่ BLE เฟิร์มแวร์ coprocessor สามารถจัดการโปรโตคอล Sideway 2.4GHz เช่น ZigBee และ Openthread ดังนั้นการรวมกันของการสื่อสาร RF ในระยะยาวและระยะสั้นจึงน่าสนใจ
โครงการนี้เป็นเพียงพอร์ตของรหัสและไลบรารีที่มีอยู่ แต่อาจประหยัดเวลาในการตั้งค่าสำหรับนักพัฒนาบางคนเนื่องจากมีปัญหาทางเทคนิคบางอย่างที่จะแก้ไข
ด้วย Lora 2.4GHz ที่กำลังจะมาถึงสิ่งนี้จะถือว่าเป็นงานในช่วงเปลี่ยนผ่าน SX1280 จะรวมการสื่อสารระยะสั้นและระยะยาวในชิปเดียว คุณอาจต้องการดูอย่างใกล้ชิด
นั่นเป็นเรื่องง่ายที่จะมา Semtech SX1272MB2XAS LORA MBED Shield เป็นโล่ที่เข้ากันได้กับ Arduino และบอร์ดนิวเคลียสมีขั้วต่อที่สอดคล้องกัน บทสรุปทางเทคนิค:
ดังที่ได้กล่าวไว้ STM32WB55 Serie เป็นเป้าหมายที่นี่และ P-nucleo-WB55RG เป็นบอร์ดที่ดีที่จะเล่นด้วย บทสรุปทางเทคนิค:
เมื่อเชื่อมต่อ (มันไม่มีเกมง่าย) นี่คือวัตถุที่เกิดขึ้น 

อย่าลืมเสียบเสาอากาศก่อนที่จะเปิดบอร์ด คุณอาจทำลายเอาต์พุตแอมพลิฟายเออร์ RF (แม้ว่าจะเป็นพลังงานที่ค่อนข้างต่ำ) แน่นอนว่าการซื้อสองรายการนั้นเป็นสิ่งจำเป็นเล็กน้อยสำหรับปิงปอง
| บรรจุุภัณฑ์ | รุ่น |
|---|---|
| STM32Cubeide | 1.7 |
| STM32CUBEMX | 6.3.0 |
| fw_wb | 1.12.1 |
| i-cube-lrwan | 2.0 |
ส่วนสำคัญของรหัสได้รับการคุ้มครองโดย ST และ Semtech sublicensing ตรวจสอบข้อตกลงที่เกี่ยวข้องสำหรับการใช้งานที่เหมาะสม:
| ส่วนประกอบ | ลิขสิทธิ์ | ใบอนุญาต |
|---|---|---|
| แหล่งที่มาของแอปพลิเคชันดั้งเดิม | Stmicroelectronic | ข้อตกลงสิทธิ์การใช้งาน ST SLA0044 |
| Lorawan®กองซ้อน | Semtech | BSD แก้ไขใบอนุญาตสำหรับชิ้นส่วน semtech |
| Cortex®-M CMSIS | ARM LTD | BSD-3-Clause หรือ Apache License 2 |
สภาพแวดล้อมการพัฒนาที่ฉันโปรดปรานคือ Linux แต่เครื่องมือ ST มีให้สำหรับ Mac และ Windows เช่นกัน สองคนแรกนั้นง่ายต่อการตั้งค่าโดยปกติจะไม่มีปัญหาหรือปัญหาคนขับ เอาล่ะความเข้าใจของเทคโนโลยีจริงรู้อยู่แล้ว
แม้ว่าฉันจะไม่ได้เป็นแฟนตัวยงของ IDES แต่ STM32Cudeide ก็ใช้งานได้และปลั๊กอิน ST ช่วยได้ (MX, การขยายการขยายซอฟต์แวร์, ... ) STMICRO จัดเตรียมแพ็คเกจขยายซอฟต์แวร์สำหรับโล่ LORA ดังที่เชื่อมโยงไว้ด้านบนมันคือ i-cube-lrwan และมีตัวอย่างโครงการและห้องสมุดเช่นไดรเวอร์ SX1272 ระดับต่ำ (ผ่าน SPI) และ Lorawan Stack (เข้ากันได้ 1.0.3)
โครงการสามารถเปิดได้อย่างง่ายดายใน STM32Cudeide โดยไม่ต้องพึ่งพา รหัสทั้งหมดไม่จำเป็นต้องติดตั้ง WB หรือ LoRawan Firmare จาก ST เปิดโครงการและสร้างมัน (ทดสอบบน Linux และ MacOS) อย่างไรก็ตามคุณต้องใช้เฟิร์มแวร์ BLE สแต็กที่ติดตั้งสำหรับ CPU2 ที่นี่ STM32WB5X_BLE_STACK_FULL_FW.BIN ได้รับการกะพริบแล้ว เฟิร์มแวร์สแต็คทุกตัวมีให้ใน โครงการ/STM32WB_COPRO_WIRELESS_BINARIES/STM32WB5X DIRECTIORY ของแพ็คเกจเฟิร์มแวร์ STM32CUBEWB รวมถึงวิธีการโปรแกรมบอร์ดสำหรับสิ่งนี้ มันจะต้องทำ ครั้งเดียว
การทดลองทั้งหมดต้องการเครื่องมือพิเศษบางอย่าง ฉันใช้ดองเกิล USB NRF52840 อันยิ่งใหญ่กับ NRF Connect สำหรับเดสก์ท็อป 3.7.0 (มีอยู่บน Linux, Mac และ Windows) จาก Nordic Semiconductor เพื่อทดสอบการเชื่อมต่อ BLE ฉันรู้ว่าสมาร์ทโฟนสามารถทำเช่นนั้นได้ฉันใช้ LightBlue บน iOS หรือ Android แต่เมื่อคุณทำผิดเกี่ยวกับ UUIDS หรือชื่ออุปกรณ์แพลตฟอร์มมักจะหายไปเมื่อข้อมูลแคชของพวกเขาดังนั้นฉันจึงชอบคิดว่าเกิดอะไรขึ้นกับเครื่องมือพัฒนาเช่น Nordic
สำหรับส่วน Lorawan TTN นั้นยอดเยี่ยมมากและฉันเลือกที่จะซื้อเกตเวย์ Lorawan ราคาไม่แพง TTIG (ราคาถูกกว่าหมวก RAK สำหรับ Raspberry Pi) สำหรับการทดสอบในท้องถิ่น เกตเวย์นั้นได้รับการบันทึกไว้สำหรับบริการ TTN แต่จะต้องมีวิธีเชื่อมต่อกับ LNS ของคุณเอง
นั่นเป็นขั้นตอนแรก การทำให้สิ่งต่าง ๆ ใช้งานได้และฉันเลือกตัวอย่างการส่งสัญญาณ RF ระดับต่ำสำหรับสิ่งนั้น การย้ายรหัส ST/Semtech เป็นเรื่องของการจัดการกับการกำหนดค่า WB55 เป็น: ใหม่เป็น:
การทำแผนที่ PIN ระหว่างบอร์ดนิวเคลียส WB55 และ SX1272MB2DAS Shield:
| SX1272MB2DAS | P-Nucleo-STM32WB55 | ชื่อพินตัวเชื่อมต่อ Arduino |
|---|---|---|
| DiO0 | PC6 | D2 |
| DiO1 | PA10 | D3 |
| DiO2 | PC10 | D4 |
| DiO3 | PA15 | D5 |
| NSS | PA4 | D10 |
| SCLK | PA5 | D13 |
| มิโซะ | PA6 | D12 |
| Mosi | PA7 | D11 |
| รีเซ็ต | PC0 | A0 |
ในตอนแรกไม่มีอะไรเข้ากันไม่ได้ การจับคู่ชุดพิน Spi1, NSS และหมุดรีเซ็ตก็โอเคเช่นกัน แต่นี่คือ hickup ครั้งแรกกับสาย IRQ PC6 ใช้บรรทัด exti6 irq (exti9_5_irqn) ไม่เป็นไร แต่ PA10, PC10 และ PA15 แชร์บรรทัด exti irq เดียวกันนั่นคือ exti15_10_irqn
ดังนั้นคำจำกัดความของอินเตอร์เฟสวิทยุได้รับการแก้ไขเพื่อให้ตรงกับบอร์ด Nucleo-WB55 (SX1272MB2DAS_CONF.H) และตัวจัดการ IRQ ได้รับการแก้ไขเพื่อตรวจสอบสถานะ GPIO (DIOX) ก่อนที่จะเรียกใช้ตัวจัดการ SX1272 IRQ ที่สอดคล้องกัน (ตรวจสอบไฟล์ต้นฉบับ STM32WBXX_IT.C)
RTC มีการตั้งค่าแหล่งนาฬิกาเป็น LSE
เค้าโครงไฟล์โครงการต้นฉบับได้รับการแก้ไขเล็กน้อย การรวมไฟล์ต้นฉบับได้ถูกสร้างขึ้นในโครงการ MX ที่สร้างขึ้น (SX1272.IOC) เพื่อรักษาความเป็นไปได้ในการเปลี่ยนโครงการ อย่างไรก็ตามบางอย่างควรใช้ความระมัดระวังเป็น รหัสที่ขัดแย้งกัน อาจสร้างขึ้น
การเขียนโปรแกรมสองบอร์ดด้วยรหัสนี้ทำงานและตามที่คาดไว้บอร์ดแรกที่ได้รับการตอบสนอง pong ต่อข้อความ ping กลายเป็น หลัก อีกฝ่ายกลายเป็น ทาส ฉันสร้างสถานะ LED สะท้อนสิ่งนี้ (ตามที่วางแผนไว้ในรหัสต้นฉบับ) หนึ่งคือกระพริบสีแดงที่ซึ่งอีกอันมี LED สีเขียวกระพริบหลังจากเวลาสั้น ๆ : วิดีโอ
รหัส BLE เป็น MX ที่สร้างขึ้นอย่างสมบูรณ์ การมีสิ่งหนึ่งที่ทำงานได้ทันทีไม่ได้ตรงไปตรงมาเนื่องจากมีหลายสิ่งหลายอย่างที่ต้องตั้งค่าไว้อย่างเหมาะสมในโครงการ MX (ซึ่งอาจเป็นบทความแยกต่างหาก) ฉันตั้งค่าโครงการทดสอบ BLE แยกกันเพื่อจุดประสงค์นั้นเมื่อมันทำงานฉันรวมรหัสเข้ากับโครงการ LORA เพื่อให้ทั้งสองวิ่งเคียงข้างกัน
ดังนั้นซอฟต์แวร์ทดสอบ BLE จึงเป็นเพียงรหัสต่อพ่วง (เซ็นเซอร์อัตราการเต้นของหัวใจ) มันขึ้นอยู่กับเฟรมเวิร์กตัวจับเวลาที่แตกต่างอย่างสิ้นเชิงซึ่งเรียกว่าฮาร์ดแวร์จับเวลาเซิร์ฟเวอร์ (HW_TS) ห้องสมุด Semtech Lora ไม่ได้ขึ้นอยู่กับห้องนี้ แต่อยู่ในยูทิลิตี้ STM32_Timer ซึ่งขึ้นอยู่กับไดรเวอร์ HAL RTC ฉันลบอะแดปเตอร์ยูทิลิตี้และอะแดปเตอร์ RTC เพื่อให้โครงการทั้งหมดอาศัย HW_TS เท่านั้น Lora Library อาศัย API ระดับกลาง (timer.h) ซึ่งเป็นเรื่องง่ายที่จะเขียนใหม่ดังนั้นจึงใช้ hw_ts แทน แอปพลิเคชั่นปิงปองในทางกลับกันขึ้นอยู่กับห้องสมุดยูทิลิตี้ในอดีต การเปลี่ยนแปลงเล็กน้อยในส่วนนั้นทำให้รหัสทั้งหมดขึ้นอยู่กับ HW_TS เท่านั้น
ฉันต้องรวม TaskIds ที่กำหนดโดยแอปพลิเคชันปิงปองและรหัส BLE โชคดีที่ทั้งสองใช้ยูทิลิตี้ STM32_Sequencer เมื่อทำอย่างถูกต้องแล้วฉันก็ทำแอปพลิเคชัน Lora Ping Pong ได้สำเร็จ และ แอปพลิเคชัน HRS BLE ที่ทำงานพร้อมกันและไร้ที่ติบนบอร์ด STM32WB55
ฉันแก้ไขรหัส APP_BLE.C ดังนั้นชื่อโฆษณา (มองเห็น) จะขึ้นอยู่กับ STM32 UDN เพื่อให้เราสามารถแยกความแตกต่างของบอร์ดที่ทำงานได้ในเวลาเดียวกัน
สำหรับการสาธิตที่มีประโยชน์ฉันเขียนบริการ GATT โดยเฉพาะเพื่อให้บอร์ดทั้งสองสามารถสอบปากคำผ่าน BLE เพื่อให้คุณสามารถรู้ได้ว่าบทบาทใดที่ Lora Node มี (Master หรือ Slave) และจำนวนของ Ping/Pong ที่ส่ง/รับ สำหรับสิ่งนี้ฉันปรับรหัส BLE เล็กน้อยเพื่อให้ LED สีน้ำเงินสะท้อนสถานะการเชื่อมต่อ BLE บริการที่กำหนดเอง (ไม่ได้สร้างโดย MX มันยุ่งเกินไป) มีสองลักษณะหนึ่งที่ต้องรู้บทบาทโหนด (ต้นแบบหรือทาสหลังจากการซิงโครไนซ์ปงปง) และอีกอย่างหนึ่งที่เป็นตัวนับของเฟรมปิงที่ได้รับ (โหนดทาส) หรือเฟรม pong (โหนดหลัก) นี่คือภาพหน้าจอของ NRF Connect ที่เชื่อมต่อกับบอร์ดที่ซิงโครไนซ์ทั้งสอง: 
เสร็จแล้วฉันชอบที่จะใช้เวลามากขึ้นในแอปพลิเคชัน LORA ที่แตกต่างกันเล็กน้อยซึ่งควบคุมโดย BLE ซึ่งเป็นขั้นตอนต่อไป
Lorawan Stack เป็นหนึ่งใน Semtech ที่ให้ไว้ในแพ็คเกจการขยายตัว I-Cube-Lrwan เป็นไปตามมาตรฐาน 1.0.3 และรวมถึงแพ็คเกจซอฟต์แวร์การรับรองหากจำเป็นต้องมีการรับรอง LORA Alliance สำหรับอุปกรณ์สุดท้าย
อีกครั้งรหัสขึ้นอยู่กับเสื้อคลุม RTC ที่แตกต่างจากสแต็ค BLE ดังนั้นจึงได้รับการแก้ไขแล้ว จำนวนตัวจับเวลาเพิ่มขึ้นเนื่องจากการตั้งค่า HW TimerServer เริ่มต้นนั้น จำกัด เกินไปสำหรับการเรียกใช้สแต็คสองสแต็กพร้อมกัน (ไฟล์ HW_IF.H เปลี่ยนไปหลังจากแก้ไข IOC)
ตัวอย่างดั้งเดิมโหนด Lorawan End ส่งชุดข้อมูลที่สมบูรณ์มากฉันลดกรอบการทดสอบลงในข้อความอย่างง่าย
อุปกรณ์ถูกตั้งค่าให้เข้าร่วมเครือข่ายโดยใช้ OTAA ดังนั้นจึงจำเป็นต้องมี 3 องค์ประกอบ: Deveui, Joineui และ Appkey Deveui เป็นตัวระบุที่ไม่ซ้ำกันสำหรับอุปกรณ์ฮาร์ดแวร์และสร้างขึ้นจาก STM32 "หมายเลขซีเรียล" ตัวระบุ joineui (หรืออดีต appeui) ใช้สำหรับการแยกแอปพลิเคชันทางฝั่งเซิร์ฟเวอร์ appkey มีความสำคัญมาก (คีย์ AES128) ที่ MUTS จะถูกเก็บไว้อย่างลับๆ ซอร์สโค้ดตั้งค่าเป็นค่าที่ต้องเปลี่ยนสำหรับการใช้งานขั้นสุดท้าย Secrecy ทำโดยรหัส semtech โดยใช้ Element API ที่ปลอดภัยในกรณีของเรามันเป็นเสมือนจริง แต่สิ่งนี้สะดวกมากถ้าคุณใช้รหัสจริง
Joineui และ Appkey เป็น hardcoded ในไฟล์ se-identity.h ( lorawan_app_key และ lorawan_nwk_key จะต้อง เป็นค่าเดียวกันสำหรับ OTAA หลังจะใช้ในการคำนวณไมค์และจำเป็นสำหรับการเข้าร่วมเพื่อให้ถูกต้องบน LNS)
การทดสอบกับ TTN และ TTIG Gateway ให้สิ่งเหล่านี้:

สำหรับส่วนที่ประกาศ

เมื่อบอร์ดทั้งสองได้รับคำตอบในเชิงบวกจากการเข้าร่วมของพวกเขา
มีการเขียนบริการ GATT พิเศษเพื่อเปิดเผย:
| คุณลักษณะ | เข้าถึง | การแสดงความคิดเห็น |
|---|---|---|
| สถานะ | อ่าน | ไม่ว่าการเข้าร่วมจะเสร็จสมบูรณ์หรือไม่ |
| คนรัก | อ่าน | การอ่านค่า deveui ที่คำนวณ |
| joineui | อ่าน | การอ่านค่า hardcoded joineui/appeui |
| ข้อมูล | เขียน | ข้อมูลที่จะถูกส่ง (16 ไบต์สูงสุด) ค่าเริ่มต้นเป็น "STM32WB55 ที่นี่!" |
| ระยะเวลา | เขียน | ระยะเวลาในวินาทีที่ข้อมูลถูกส่ง (ค่าเริ่มต้นถึง 10 วินาที) |
| RSSI | อ่าน | อัปเดตเมื่อได้รับข้อความ Downlink |
| SNR | อ่าน | อัปเดตเมื่อได้รับข้อความ Downlink |
หมายเหตุ: อย่ายุ่งกับช่วงเวลามีข้อ จำกัด รอบการทำงาน 1% ด้วยการตั้งค่าเริ่มต้นโมดูลจะส่ง 15 ไบต์ทุก ๆ 10 วินาที ที่ SF7BW125 สามารถทำได้ในช่วงเวลาต่ำสุดที่ ~ 7 วินาที
นี่คือภาพประกอบของลักษณะที่เปิดเผยเมื่อเชื่อมต่อกับมัน:

ที่จะดำเนินการต่อ