เกี่ยวกับ Zigbee EZSP UART | เทคโนโลยี Owon

ผู้แต่ง：TorchIoTBootCamp
ลิงก์：https://zhuanlan.zhihu.com/p/339700391
จาก：Quora

1. บทนำ

Silicon Labs นำเสนอโซลูชันโฮสต์+NCP สำหรับการออกแบบเกตเวย์ Zigbee ในสถาปัตยกรรมนี้ โฮสต์สามารถสื่อสารกับ NCP ได้ผ่านอินเทอร์เฟซ UART หรือ SPI โดยทั่วไปแล้ว UART จะถูกใช้ เนื่องจากง่ายกว่า SPI มาก

Silicon Labs ยังได้จัดทำโครงการตัวอย่างสำหรับโปรแกรมโฮสต์ ซึ่งก็คือตัวอย่างโฮสต์เกตเวย์ Z3ตัวอย่างนี้ทำงานบนระบบคล้าย Unix ลูกค้าบางรายอาจต้องการตัวอย่างโฮสต์ที่สามารถทำงานบน RTOS ได้ แต่โชคไม่ดีที่ขณะนี้ยังไม่มีตัวอย่างโฮสต์ที่ใช้ RTOS ผู้ใช้จำเป็นต้องพัฒนาโปรแกรมโฮสต์ของตนเองโดยใช้ RTOS

สิ่งสำคัญคือต้องเข้าใจโปรโตคอลเกตเวย์ UART ก่อนที่จะพัฒนาโปรแกรมโฮสต์ที่กำหนดเอง สำหรับ NCP ที่ใช้ UART และ NCP ที่ใช้ SPI โฮสต์จะใช้โปรโตคอล EZSP เพื่อสื่อสารกับ NCPอีเอสพีเป็นคำย่อของโปรโตคอลซีเรียล EmberZnetและได้กำหนดไว้ในยูจี100สำหรับ NCP ที่ใช้ UART จะมีการนำโปรโตคอลเลเยอร์ล่างมาใช้งานเพื่อส่งข้อมูล EZSP ได้อย่างน่าเชื่อถือผ่าน UART นั่นคือเถ้าโปรโตคอล ย่อมาจากโฮสต์ซีเรียลแบบอะซิงโครนัส. สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับ ASH โปรดดูที่ยูจี101และยูจี115.

ความสัมพันธ์ระหว่าง EZSP และ ASH สามารถแสดงได้ด้วยแผนภาพต่อไปนี้:

รูปแบบข้อมูลของ EZSP และโปรโตคอล ASH สามารถแสดงได้ด้วยแผนภาพต่อไปนี้:

ในหน้านี้ เราจะแนะนำกระบวนการสร้างเฟรมข้อมูล UART และเฟรมคีย์บางส่วนที่ใช้บ่อยในเกตเวย์ Zigbee

2. การสร้างกรอบ

กระบวนการสร้างกรอบโดยทั่วไปสามารถแสดงได้ด้วยแผนภูมิต่อไปนี้:

ในแผนภูมิข้อมูลนี้หมายถึงกรอบ EZSP โดยทั่วไป กระบวนการสร้างกรอบมีดังนี้: |ไม่มี|ขั้นตอน|อ้างอิง|

|1|เติมกรอบ EZSP|UG100|

|2|การสุ่มข้อมูล|ส่วนที่ 4.3 ของ UG101|

|3|เพิ่มไบต์ควบคุม|บทที่ 2 และบทที่ 3 ของ UG101|

|4|คำนวณ CRC|ส่วนที่ 2.3 ของ UG101|

|5|การยัดไบต์|ส่วนที่ 4.2 ของ UG101|

|6|เพิ่มธงสิ้นสุด|ส่วนที่ 2.4 ของ UG101|

2.1. กรอกกรอบ EZSP

รูปแบบเฟรม EZSP แสดงอยู่ในบทที่ 3 ของ UG100

โปรดทราบว่ารูปแบบนี้อาจเปลี่ยนแปลงได้เมื่ออัปเกรด SDK เมื่อรูปแบบเปลี่ยนแปลง เราจะกำหนดหมายเลขเวอร์ชันใหม่ให้กับรูปแบบนี้ หมายเลขเวอร์ชัน EZSP ล่าสุดคือ 8 เมื่อเขียนบทความนี้ (EmberZnet 6.8)

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

เพื่อให้บรรลุผลดังกล่าว คำสั่งแรกระหว่างโฮสต์และ NCP จะต้องเป็นคำสั่งเวอร์ชัน กล่าวอีกนัยหนึ่ง โฮสต์จะต้องดึงเวอร์ชัน EZSP ของ NCP ก่อนการสื่อสารอื่นใด หากเวอร์ชัน EZSP แตกต่างจากเวอร์ชัน EZSP ของฝั่งโฮสต์ การสื่อสารจะต้องถูกยกเลิก

ข้อกำหนดโดยนัยเบื้องหลังนี้คือรูปแบบของคำสั่งเวอร์ชันสามารถไม่เคยเปลี่ยนแปลงรูปแบบคำสั่งเวอร์ชัน EZSP เป็นดังนี้:

คำอธิบายของฟิลด์พารามิเตอร์และรูปแบบของการตอบสนองเวอร์ชันสามารถดูได้ในบทที่ 4 ของ UG100 ฟิลด์พารามิเตอร์คือเวอร์ชัน EZSP ของโปรแกรมโฮสต์ เมื่อเขียนบทความนี้คือ 8

ที่มา：TorchIoTBootCamp
链接：https://zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

2.2 การสุ่มข้อมูล

กระบวนการสุ่มแบบละเอียดอธิบายไว้ในส่วนที่ 4.3 ของ UG101 เฟรม EZSP ทั้งหมดจะถูกสุ่ม การสุ่มจะจำกัดเฉพาะเฟรม EZSP และลำดับสุ่มเทียม

ด้านล่างนี้เป็นอัลกอริทึมในการสร้างลำดับแบบสุ่มเทียม

แรนด์0 = 0×42
ถ้าบิต 0 ของแรนดี้เป็น 0 แรนดี้+1 = แรนดี้ >> 1
ถ้าบิต 0 ของแรนดี้คือ 1, แรนดี้+1 = (แรนดี้ >> 1) ^ 0xB8

2.3. เพิ่มไบต์ควบคุม

ไบต์ควบคุมเป็นข้อมูลขนาดหนึ่งไบต์ และควรเพิ่มลงในส่วนหัวของเฟรม รูปแบบแสดงด้วยตารางด้านล่าง:

โดยรวมแล้วมีไบต์ควบคุม 6 ประเภท สามประเภทแรกใช้สำหรับเฟรมทั่วไปที่มีข้อมูล EZSP ได้แก่ DATA, ACK และ NAK ส่วนสามประเภทสุดท้ายใช้โดยไม่ใช้ข้อมูล EZSP ทั่วไป ได้แก่ RST, RSTACK และ ERROR

รูปแบบของ RST, RSTACK และ ERROR มีอธิบายไว้ในหัวข้อ 3.1 ถึง 3.3

2.4. คำนวณ CRC

CRC 16 บิตจะคำนวณจากไบต์ตั้งแต่ไบต์ควบคุมจนถึงจุดสิ้นสุดของข้อมูล CRCCCITT มาตรฐาน (g(x) = x16 + x12 + x5 + 1) จะถูกกำหนดค่าเริ่มต้นเป็น 0xFFFF ไบต์ที่มีนัยสำคัญที่สุดจะอยู่ก่อนไบต์ที่มีนัยสำคัญน้อยที่สุด (โหมดบิ๊กเอนเดียน)