Dobički:
- Sposobnost analiziranja strukture okvirja/paketa protokolov, kot sta I2C/SPI/UART in TCP/IP, MQTT s podporo za AI
- Sposobnost zožitve napak protokola (časovni razpored, naslavljanje, kontrolna vsota) kot hipotez z AI
- Sposobnost preverjanja interpretacije protokola AI s standardnim dokumentom, meritvami analizatorja (logika/paket)
Protokol je niz pravil, o katerih se dogovorita dve napravi, da se razumeta: s kakšno hitrostjo, v kakšnem vrstnem redu, v kakšni obliki se bosta pogovarjali. Ne glede na to, ali se temperaturni senzor pogovarja z mikrokrmilnikom prek I2C ali naprava s strežnikom v oblaku prek TCP/IP in MQTT, temelji na protokolu. V tej enoti boste videli, kako uporabiti AI za analizo okvirjev/paketov protokola, zožiti napake protokola in razumeti komunikacijski sklad (plasti ena na drugi, od fizične plasti do aplikacije). AI je močan pri razlagi protokolov in ustvarjanju hipotez; toda kaj linija dejansko počne, je znano samo z meritvami njenega analizatorja (logični analizator, analizator protokolov/paketov) in standardnega dokumenta.
Vgrajeni serijski protokoli: I2C, SPI, UART
Čipi na plošči običajno komunicirajo s tremi serijskimi protokoli:
- UART: Dve vrstici (TX/RX), brez linije ure; Obe strani morata biti nastavljeni na enako hitrost (baud rate). Preprosto, vendar je sinhronizacija odvisna od hitrosti.
- SPI: Ura (SCLK), vnos/izhod podatkov (MOSI/MISO) in izbrane (CS) linije; Hiter, polni dupleks, vendar zahteva več zatičev. Polariteta/faza ure (CPOL/CPHA) se mora ujemati na obeh straneh.
- I2C: Dve liniji (SDA/SCL), na podlagi naslova, več naprav na isti liniji; vlečni upori in stanje skupne mase. Počasen, a varčen.
AI zelo dobro razloži, kako ti protokoli delujejo, njihovo okvirno strukturo in tipične vzroke napak. Sistematično navaja možne vzroke (napačen naslov, manjkajoč priključek, neusklajenost hitrosti, odsotnost skupne podlage, spor v liniji, dolžina/kapacitivnost kabla), ko se naprava I2C ne odziva. Toda kaj od tega je resnično, lahko razumemo z merjenjem linije z logičnim analizatorjem in ogledom valov SDA/SCL; AI poda hipotezo, meritve odločajo.
Namig: Pri okvari serijskega protokola vprašajte AI "razvrsti možne vzroke od najverjetnejših do najmanj verjetnih, in vse, kar vidim na analizatorju za vsakega, je potrjeno." Tako naredite meritev ciljno usmerjeno; Namesto da preizkušate vsak razlog enega za drugim, vas pogled analizatorja popelje na pravo vejo.
Omrežni protokoli: TCP/IP, UDP, MQTT, CoAP
Večplastni protokoli pridejo v poštev, ko se naprave povežejo v omrežje in oblak. Sklad TCP/IP je v bistvu večplasten: fizična/podatkovna povezava (Ethernet, Wi-Fi), omrežje (IP: naslavljanje in usmerjanje), transport (TCP: zanesljiv, zaporeden, nadzorovan s pretokom / UDP: hiter, nezaupljiv) in aplikacija (HTTP, MQTT, CoAP). Ključni pojmi:
- TCP proti UDP: TCP kompenzira izgubo in zagotavlja vrstni red, vendar uvaja zakasnitev in stroške; UDP je hiter, vendar nima jamstva za dostavo (za telemetrijo je prednosten avdio/video v realnem času).
- MQTT: lahek sporočilni protokol IoT, ki deluje z modelom objave-naročnine; sporočanje prek tem prek posrednika. Ravni QoS določajo zagotavljanje dostave.
- CoAP: lahek protokol, podoben HTTP-ju, ki temelji na UDP, za omejene naprave.
AI analizira strukturo okvirja/paketa teh protokolov, vam pomaga interpretirati zajem Wireshark (analizator paketov) in pregleda zasnovo teme MQTT. Toda kakšen je resnični promet, se preveri z zajemom paketov, obnašanje strežnika pa se preveri z resničnim testiranjem.
Kontrolna vsota, CRC in okvirjanje
Večina protokolov uporablja kontrolno vsoto ali CRC (Cyclic Redundancy Check), da preveri, ali podatki niso poškodovani: pošiljatelj izračuna vrednost preverjanja iz podatkov, prejemnik izvede isti izračun in primerja. AI opisuje in piše kodo za izračun CRC/kontrolne vsote, vendar so podrobnosti, kot so polinomska izbira, endianness, začetna vrednost itd., specifične za standard; Kodo CRC, ki jo ustvari AI, je treba dobesedno primerjati z uradno definicijo protokola in preveriti z znanim testnim vektorjem.
trije mini kovčki
Primer 1 – Nepopoln dvig. Ekipa ne more zagnati senzorja I2C na mizi; ne prizna naslova naprave (ni ACK). AI navaja manjkajoči vlečni upor in skupno ozemljitev kot najverjetnejši vzrok. Ko pogledamo linijo SDA z logičnim analizatorjem, vidimo, da signal ne more v celoti doseči visoke ravni; Komunikacija se začne, ko se dodajo vlečni upori. Lekcija: AI je izpostavil najverjetnejši vzrok, analizator ga je potrdil.
2. primer — Napačen način SPI. Inženir bere neumne podatke iz naprave SPI. AI kot možen vzrok predlaga neusklajenost polarnosti/faze ure (CPOL/CPHA). V analizatorju se zdi, da ura vzorči drugače kot rob, ki ga naprava pričakuje; Ko se način popravi, postanejo podatki smiselni. Lekcija: Simptom "podatki, a nesmisel" v SPI je najpogosteje neusklajenost načina; meritev to pojasni.
3. primer – nesporazum MQTT QoS. Pripravnik pošlje telemetrijo prek MQTT, vendar vidi, da so nekatera sporočila izgubljena, in vpraša AI. AI navaja, da je QoS 0 »največ enkrat, dostava ni zagotovljena«; Pojasnjuje, da je za zagotavljanje dostave potreben QoS 1/2, vendar to povzroča stroške in zamude. Pripravnik preklopi na QoS 1 na podlagi kritičnosti telemetrije in preveri vedenje posrednika z resničnim testiranjem. Lekcija: Pojasnite možnost protokola AI; Pravilna izbira je narejena glede na aplikacijo in preverjena s testiranjem.
Kopirane predloge pozivov
PREDLOGA ZA NAVIGACIJO NAPAKE PROTOKOLA"[I2C/SPI/UART/TCP/MQTT] komunikacija ima naslednji simptom: [simptom]. Možne vzroke razvrstite od NAJVERJETNEJŠIH do NAJMANJ verjetnih. Za vsak vzrok: (1) zakaj daje ta simptom, (2) vse, kar vidim na analizatorju/meritvi, je POTRJENO, (3) karkoli vidim, je ODLOČENO. NE POSTAVLJAJTE dokončne diagnoze; pojavi se drevo odločitev."
PREDLOGA ZA ANALIZO OKVIRJA/PAKETOV "Razdelite naslednjo vsebino [I2C/SPI/UART niz bajtov / zajem paketov] na polja in opišite vsako polje (naslov, ukaz, podatki, kontrolna vsota/CRC, zastavica). Jasno navedite svojo domnevo o endianness in bitnem vrstnem redu. Upoštevajte, da moram vaš komentar preveriti z uradnim opisom protokola in testnim vektorjem. Podatki: [prilepi]."
PREDLOGA ZA PREVERJANJE CRC/KONTROLNE VSOTE"Opišite izračun CRC/kontrolne vsote za [protokol]: polinom, začetna vrednost, vrstni red bitov, končni
PREDLOGA ZA IZBIRO PROTOKOLA "Izvedite primerjavo transportnega/aplikacijskega protokola za naslednjo aplikacijo: [zahteva: garancija dostave, zakasnitev, moč, pasovna širina, omejitev naprave]. Primerjajte možnosti TCP/UDP in MQTT/CoAP/HTTP s temi kriteriji. NE SVELEJTE jasne izbire; uravnotežite vsako možnost in navedite, da je treba izbiro preveriti z dejanskim testiranjem."
Šibek poziv/močan poziv
ŠIBEK POZIV: "I2C ne deluje, zakaj?"
MOČEN POZIV: "Moj senzor I2C ne sprejme ACK (naslov ni potrjen). Naštejte možne vzroke, začenši z najverjetnejšimi: vlečenje, skupna ozemljitev, napačen naslov, hitrost, kapacitivnost kabla, spor. Za vsak vzrok napišite, kar koli vidim na SDA/SCL na logičnem analizatorju je potrjeno, kar koli vidim, je izločeno. Ne postavljajte diagnoze; želim seznam, ki ga lahko zožim z meritvijo."
Šibek poziv ustvari eno samo ugibanje; Zmogljiv poziv zagotavlja diagnostični zemljevid, ki ga je mogoče zožiti na meritve, naročiti in preveriti.
Primerjalna tabela protokolov
protokol
Vrsta
močna točka
orodje za preverjanje
UART
Serija, brez ure
Enostavno, dve vrstici
Logični analizator
SPI
Serijski, nataknjen
Hiter, polni dupleks
Logični analizator (CPOL/CPHA)
I2C
Serijski, naslovljiv
Veliko naprav, malo zatičev
Analizator (ACK, pull-up)
TCP
omrežje, transport
Zanesljivo, urejeno
Analizator paketov (Wireshark)
UDP
omrežje, transport
Hitro, nizka latenca
analizator paketov
MQTT
Aplikacija
Lahek, pub/sub, QoS
Dnevnik posrednika + zajem paketov
Pozor: AI interpretira zajem protokola je hiter, vendar lahko AI nepravilno prevzame bitni vrstni red ali mejo polja. Vsako analizo preverite glede na uradni opis protokola in znani testni vektor.
Pogoste napake
- Spreminjanje na podlagi napovedi AI brez merjenja vzroka napake. Pogled analizatorja vas pripelje do pravega vzroka.
- Ignoriranje skladnosti s CPOL/CPHA v SPI. "Obstajajo podatki, vendar so nesmiselni" je pogosto nezdružljivost načina.
- Pozabljamo na vzpenjanje in skupno točko na I2C. To je najpogostejši vzrok, da "sploh ne deluje".
- Ob predpostavki parametrov CRC. Polinom, začetek, bitni vrstni red so specifični za standard; Preverjeno je s testnim vektorjem.
- Zmeda MQTT QoS z garancijo dostave. QoS 0 ne jamči; Izbor je narejen in testiran glede na aplikacijo.
Če povzamem
V tej enoti ste uporabili AI kot močno pomoč pri razlagi protokolov, kot so I2C/SPI/UART in TCP/IP, MQTT, analiza okvirja/paketa in sistematično omejevanje vzrokov napak. Vendar so protokoli natančni in vezani na standarde: kaj linija dejansko počne, določi logični/paketni analizator, natančnost analize je določena s formalno definicijo in testnim vektorjem, vzrok napake je določen z meritvijo. Usmerite AI, da poda "najverjetnejši vzrok in meritev, ki ga potrdi"; Naj odločita analizator in standard.
Aplikacijska naloga
Izberite scenarij napake serijskega protokola (npr. ni I2C ACK). Od AI zahtevajte zaporedno diagnostično karto, ki jo je mogoče preveriti z meritvami, s predlogo »zožitev napak protokola«. Nato vzemite vzorčno niz bajtov (npr. okvir za branje senzorja) in ga razmaknite z vzorcem "Razčlenjevanje okvirja/paketa" in upoštevajte predpostavko endianness. Na koncu preverite kodo CRC glede na znani testni vektor s predlogo »CRC/preverjanje kontrolne vsote«.
kontrolni seznam
- [ ] Vzrok napake sem potrdil z meritvijo analizatorja, ne z napovedjo AI.
- [ ] Navedel sem CPOL/CPHA na SPI, naslov/pull-up/skupni talni nadzor na I2C.
- [ ] Primerjal sem razčlenjevanje okvirja/paketa z uradno definicijo protokola.
- [ ] Preveril sem parametre CRC/kontrolne vsote s testnim vektorjem.
- [ ] Izbral sem transportni/aplikacijski protokol v skladu z zahtevami in ga preizkusil z resničnim testiranjem.
- [ ] Pravilno sem razložil pomen garancije dostave za MQTT QoS.