paddy firmware

เฟิร์มแวร์ข้าวเปลือก

นี่คือองค์ประกอบเฟิร์มแวร์สำหรับข้าวเปลือก

มันใช้ Arduino C ++ และได้รับการออกแบบรอบ ๆ เครื่องรัฐ มันถูกกระพริบโดยตรงบนชิปที่รองรับ ประเภท Arduino ที่ใช้สำหรับโครงการนี้คือ IoT Nano 33

งานของรหัสนี้คือการเชื่อมต่อกับนายหน้า MQTT Paddy ผ่าน Wi-Fi หรือแอพ Paddy ผ่าน Bluetooth Low Energy สำหรับการตั้งค่าและการจัดการข้อผิดพลาด รหัสควรควบคุมฮาร์ดแวร์ที่ทำงาน:

1. เปิด/ปิดการสลับอุปกรณ์โหลด
2. การวัดพลังงานสำหรับอุปกรณ์โหลดพร้อมการส่งสถิติเป็นระยะ

แผนภาพเครื่องจักร

ภาพรวม

รหัสของเครื่องรัฐนี้ถูกจัดระเบียบด้วยส่วนประกอบซิงเกิลซึ่งมีการสร้างอินสแตนซ์ครั้งเดียวในเฟิร์มแวร์และนำกลับมาใช้ใหม่ตลอดวงจรชีวิตของโปรแกรม โมดูลเหล่านี้มีดังนี้:

• BLE: จัดการการสื่อสารโดยตรงระหว่าง daemon และอุปกรณ์กลาง
• การควบคุม: เปิดหรือปิดอุปกรณ์โหลดขึ้นอยู่กับคำสั่งที่ได้รับในเวลานั้น
• MQTT: จัดการการสื่อสารทั้งหมดกับโบรกเกอร์และผู้ได้รับมอบหมายทำงานกับส่วนประกอบหรือสถานะอื่น ๆ ในการดึงข้อความ
• พลังงาน: ควบคุมและปรับเทียบหม้อแปลงกระแสไฟฟ้าการวัดกำลัง ทำให้การอ่านเป็นระยะ
• ที่เก็บ: จำลองชิป EEPROM เนื่องจาก Arduino IoT Nano 33 ที่เลือกไม่มี EEPROM จริง จัดเก็บข้อมูลรับรองที่จำเป็น
• Wi-Fi: จัดการการเชื่อมต่อ Wi-Fi และการวัดความแรงของสัญญาณ

เมื่อแต่ละรัฐมีหน้าที่ที่กำหนดไว้ล่วงหน้าจึงเป็นเรื่องง่ายที่จะเข้าใจว่าการไหลแต่ละชิ้นทำอะไร:

• สถานะการบูต: นี่คือสถานะเริ่มต้นที่ไมโครคอนโทรลเลอร์จะเข้าสู่ทันทีที่บูทขึ้น การตรวจสอบฮาร์ดแวร์จะดำเนินการที่นี่โดยเฉพาะโมดูล Wi-Fi และโมดูลพลังงานต่ำบลูทู ธ หากการตรวจสอบเหล่านี้ประสบความสำเร็จและ Daemon สามารถเริ่มต้นส่วนประกอบดังกล่าวได้มันจะย้ายไปยังสถานะ init มิฉะนั้นมันจะเคลื่อนที่ไปสู่การแตกหยุดอยู่ที่นั่นและกระพริบไฟ LED ที่ระบุข้อผิดพลาดของฮาร์ดแวร์ให้กับผู้ใช้
• สถานะเริ่มต้น: สถานะเริ่มต้นเป็นสถานะกลางแรกที่ daemon เข้ามา วัตถุประสงค์คือการเตรียมอุปกรณ์สำหรับฟังก์ชั่นที่เหมาะสมโดยการสอบเทียบโมดูลการวัดพลังงานครั้งแรกโดยการปั่นจักรยานสองสามครั้งคุ้นเคยกับการอ่านอุปกรณ์ไปยังสายไฟ หลังจากนั้นจะได้รับการตรวจสอบว่า daemon มีข้อมูลประจำตัวใด ๆ ที่เก็บไว้ใน EEPROM ที่เลียนแบบหรือไม่ daemon เคลื่อนไปสู่สถานะการเชื่อมต่อด้วยข้อมูลรับรองดังกล่าวหากอดีตเป็นจริงมิฉะนั้นจะป้อนเฟสการตั้งค่า
• สถานะการตั้งค่า: ด้วยพฤติกรรมการปิดกั้นสถานะนี้จะไม่คืบหน้าจนกว่าการกระทำของผู้ใช้จะเสร็จสิ้น เนื่องจาก daemon ไม่มีข้อมูลรับรองใด ๆ ที่นี่จึงไม่มีความคิดว่าจะเชื่อมต่อกับ Wi-Fi หรือนายหน้าได้อย่างไร ซึ่งหมายความว่าในขั้นตอนนี้ Daemon ไม่สามารถใช้ Wi-Fi สำหรับการถ่ายโอนข้อมูลและต้องการวิธีการโดยตรง BLE เหมาะสำหรับสถานการณ์นี้เนื่องจากการเขียนและการอ่านผ่านลักษณะนั้นสามารถทำได้อย่างง่ายดายจากแอพ Paddy ดังนั้นความสามารถ BLE ของอุปกรณ์จึงถูกใช้เพื่อปล่อยลักษณะเหล่านี้:

• อนุกรม (อ่านอย่างเดียว): คุณลักษณะที่ปล่อยหมายเลขซีเรียลของอุปกรณ์
• SSID (เขียนอย่างเดียว): ตัวระบุชุดบริการสำหรับเครือข่าย Wi-Fi
• รหัสผ่าน (เขียนเท่านั้น): รหัสผ่านของจุดเชื่อมต่อ Wi-Fi
• ชื่อผู้ใช้ Enterprise (Write-only): หาก Wi-Fi ต้องการเทคนิคการตรวจสอบความถูกต้องขององค์กรเช่น EAP หรือ PEAP ชื่อผู้ใช้สำหรับผู้ใช้
• รหัสผ่านองค์กร (เขียนอย่างเดียว): หาก Wi-Fi ต้องการเทคนิคการตรวจสอบความถูกต้องขององค์กรเช่น EAP หรือ PEAP รหัสผ่านสำหรับผู้ใช้
• JWT (เขียนอย่างเดียว): โทเค็นเว็บ JSON ที่ใช้โดย Daemon เพื่อเชื่อมต่อกับนายหน้า
• รีเซ็ต (เขียนอย่างเดียว): เมื่อคุณลักษณะนี้ถูกเขียนถึง daemon จะรีเซ็ตข้อมูลประจำตัวของมัน

ในการดำเนินการต่อไปคุณลักษณะ JWT และข้อมูลรับรองจะต้องถูกเขียนลงโดยอุปกรณ์มือถือของผู้ใช้ผ่านแอพ Paddy จะต้องสังเกตว่าเพื่อความเรียบง่ายเฟิร์มแวร์จะตรวจจับขั้นตอนนี้เมื่อเสร็จสิ้นการเขียนลงในลักษณะ SSID เท่านั้น ด้วยเหตุนี้การเขียนสามารถเกิดขึ้นได้ในลำดับใด ๆ ยกเว้น SSID หนึ่งซึ่งจะต้องเขียนเพื่อใช้งานล่าสุดสำหรับพฤติกรรมที่คาดการณ์ได้ เพื่อแยกแยะระหว่างโหมดการอนุญาตการรวมกันของลักษณะที่เป็นลายลักษณ์อักษรให้ผลการกำหนดค่าสามครั้งเมื่อมันมาถึงการอนุญาต Wi-Fi: ไม่ปลอดภัย (SSID เท่านั้น), ปลอดภัย (SSID + รหัสผ่าน) และ Enterprise (SSID + Enterprise Passwate รหัสผ่าน Enterprise)

• การเชื่อมต่อสถานะ: สถานะนี้ค่อนข้างง่ายเนื่องจากทำงานได้ในขณะที่ Daemon เชื่อมต่อกับนายหน้าแบ็กเอนด์ ในความสำเร็จในการเชื่อมต่อมันส่งมอบรัฐให้กับออนไลน์และกลับไปสู่ความล้มเหลว
• สถานะออนไลน์: สถานะ“ การทำงาน” ของ daemon ซึ่งแสดงถึงแผ่นที่ใช้งานได้อย่างสมบูรณ์ ที่นี่สามารถโต้ตอบกับนายหน้าได้โดยรับข้อความ MQTT และส่งพวกเขา Daemon มีหน้าที่เล็กน้อยในขณะที่อยู่ในสถานะนี้:

• ฟังข้อความ MQTT คือเปิดปิดรีเซ็ตและหมุนหัวข้อ เมื่อได้รับหนึ่งในข้อความเหล่านี้มันจะดำเนินการอย่างเหมาะสม
• ส่งข้อความปิงแบบเก็บรักษาไปยังนายหน้า ข้อความเหล่านี้มีวัตถุประสงค์ทางสถิติอย่างหมดจดและไม่จำเป็นต้องทำให้การเชื่อมต่อมีชีวิตอยู่ พวกเขาใช้เพื่อติดตามสถานะของ Daemon จากแอพ ในน้ำหนักบรรทุกของข้อความเหล่านี้ความแรงของสัญญาณ Wi-Fi จะถูกถ่ายทอด
• ข้อมูลการใช้งานการใช้พลังงานเป็นระยะ ๆ ไปยังนายหน้า
• ตรวจสอบว่าอุปกรณ์ยังคงเชื่อมต่อกับนายหน้าหรือไม่ หากอุปกรณ์ไม่ได้เชื่อมต่ออีกต่อไปให้ไปที่ backoff

• Backoff State: ในขณะที่สถานะนี้ทำหน้าที่เป็นช่องว่างภายในก่อนที่ Daemon จะทำการเชื่อมต่อ แต่ยังเป็นหน้าต่างสำหรับผู้ใช้ที่จะรีเซ็ต daemon ผ่านการเชื่อมต่อ BLE โดยตรง ตัวอย่างเช่นในกรณีที่ daemon ถูกย้ายจากสถานที่ที่มีการเชื่อมต่อ Wi-Fi อื่นมันมีข้อมูลรับรองอยู่แล้ว แต่ไม่ถูกต้อง ดังนั้นเมื่อ daemon มาถึงสถานะ backoff มันจะเปิดหน้าต่าง 60 วินาทีซึ่งผู้ใช้สามารถรีเซ็ตผ่าน BLE โดยตรง อย่างไรก็ตามหากตัวนับ 60 วินาทีหมด Daemon จะลองเชื่อมต่อกับเซิร์ฟเวอร์อีกครั้งโดยย้ายไปยังสถานะการเชื่อมต่อ

ไดอะแกรมวงจร