Auteur: TorchIoTBootCamp
Keppeling: https://zhuanlan.zhihu.com/p/339700391
Fan: Quora
1. Ynlieding
Silicon Labs hat in host + NCP-oplossing oanbean foar Zigbee-gateway-ûntwerp. Yn dizze arsjitektuer kin de host kommunisearje mei de NCP fia UART- as SPI-ynterface. Meastentiids wurdt UART brûkt om't it folle ienfâldiger is dan SPI.
Silicon Labs hat ek in foarbyldprojekt levere foar it hostprogramma, dat is de stekproefZ3GatewayHost. De stekproef rint op in Unix-lykas systeem. Guon klanten kinne wol in host-sample dy't kin rinne op in RTOS, mar spitigernôch is d'r foar it momint gjin RTOS-basearre hostmonster. Brûkers moatte har eigen hostprogramma ûntwikkelje basearre op RTOS.
It is wichtich om it UART-gatewayprotokol te begripen foardat jo in oanpast hostprogramma ûntwikkelje. Foar sawol UART-basearre NCP as SPI-basearre NCP, brûkt de host it EZSP-protokol om te kommunisearjen mei de NCP.EZSPis koart foarEmberZnet Serial Protocol, en it is definiearre ynUG100. Foar UART-basearre NCP wurdt in legere laachprotokol ymplementearre om EZSP-gegevens betrouber oer UART te dragen, dat is deASHprotokol, koart foarAsynchronous Serial Host. Foar mear details oer ASH, ferwize asjebleaft neiUG101enUG115.
De relaasje tusken EZSP en ASH kin wurde yllustrearre troch it folgjende diagram:
It gegevensformaat fan 'e EZSP en it ASH-protokol kin wurde yllustrearre troch it folgjende diagram:
Op dizze side sille wy it proses yntrodusearje foar it framen fan de UART-gegevens en guon kaaiframes dy't faak wurde brûkt yn Zigbee-gateway.
2. Frameing
It algemiene frameproses kin wurde yllustrearre troch de folgjende diagram:
Yn dit diagram betsjutte de gegevens it EZSP-frame. Yn 't algemien binne de framingprosessen: |Nee|Stap|Referinsje|
|:-|:-|:-|
|1|Folje it EZSP-frame|UG100|
|2|Data willekeurich|Seksje 4.3 fan UG101|
|3|Foegje de kontrôlebyte ta|haad2 en haadstik3 fan UG101|
|4|Berekkenje de CRC|Seksje 2.3 fan UG101|
|5|Byte Stuffing|Seksje 4.2 fan UG101|
|6|De einflagge taheakje|Seksje 2.4 fan UG101|
2.1. Folje it EZSP-frame yn
It EZSP-frameformaat wurdt yllustrearre yn Haadstik 3 fan UG100.
Tink derom dat dit formaat kin feroarje as de SDK upgrades. As it formaat feroaret, sille wy it in nij ferzjenûmer jaan. It lêste EZSP-ferzjenûmer is 8 as dit artikel skreaun is (EmberZnet 6.8).
Om't it EZSP-frameformaat ferskille kin tusken ferskate ferzjes, is d'r in ferplichte eask dat de host en NCPMOATTEwurkje mei deselde EZSP ferzje. Oars kinne se net kommunisearje lykas ferwachte.
Om dat te berikken moat it earste kommando tusken de host en de NCP it ferzjekommando wêze. Mei oare wurden, de host moat de EZSP-ferzje fan 'e NCP ophelje foar elke oare kommunikaasje. As de EZSP-ferzje oars is mei de EZSP-ferzje fan 'e hostside, moat de kommunikaasje ôfbrutsen wurde.
De ymplisite eask efter dit is dat it formaat fan it ferzjekommando kinNEVER feroarje. It kommando-opmaak fan EZSP-ferzje is lykas hjirûnder:
链接：https://zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注昄凂
2.2. Data Randomization
It detaillearre randomisaasjeproses wurdt beskreaun yn paragraaf 4.3 fan UG101. It hiele EZSP-frame sil willekeurich wurde. De randomisaasje is nei eksklusyf-OR it EZSP-frame en in pseudo-willekeurige folchoarder.
Hjirûnder is it algoritme foar it generearjen fan de pseudo-willekeurige folchoarder.
- rand0 = 0×42
- as bit 0 fan randi 0 is, randi+1 = randi >> 1
- as bit 0 fan randi 1 is, randi+1 = (randi >> 1) ^ 0xB8
2.3. Foegje de Control Byte ta
De kontrôle byte is ien byte gegevens, en moat wurde tafoege oan de kop fan it frame. It formaat wurdt yllustrearre mei de tabel hjirûnder:
Yn totaal binne d'r 6 soarten kontrôlebytes. De earste trije wurde brûkt foar mienskiplike frames mei EZSP-gegevens, ynklusyf DATA, ACK en NAK. De lêste trije wurde brûkt sûnder mienskiplike EZSP-gegevens, ynklusyf RST, RSTACK en ERROR.
De opmaak fan de RST, RSTACK en ERROR wurde beskreaun yn paragraaf 3.1 oant 3.3.
2.4. Berekkenje de CRC
In 16-bit CRC wurdt berekkene op bytes fan 'e kontrôlebyte oant it ein fan' e gegevens. De standert CRCCCITT (g(x) = x16 + x12 + x5 + 1) wurdt inisjalisearre nei 0xFFFF. De meast wichtige byte giet foar de minst signifikante byte (big-endian modus).
2.5. Byte Stuffing
Lykas beskreaun yn paragraaf 4.2 fan UG101, binne d'r guon reservearre bytewearden brûkt foar spesjale doelen. Dizze wearden kinne fûn wurde yn 'e folgjende tabel:
As dizze wearden yn it frame ferskine, sil in spesjale behanneling dien wurde oan de gegevens. - Foegje de escape-byte 0x7D yn foar de reservearre byte - Draai de bit5 fan dy reservearre byte om
Hjirûnder binne wat foarbylden fan dit algoritme:
2.6. Foegje de einflagge ta
De lêste stap is om de einflagge 0x7E ta te foegjen oan 'e ein fan it frame. Dêrnei kinne de gegevens nei de UART-poarte stjoerd wurde.
3. De-framing Proses
As gegevens wurde ûntfongen fan 'e UART, moatte wy gewoan de omkearde stappen dwaan om it te ûntsiferjen.
4. Referinsjes
Post tiid: Febrewaris 08-2022