Добивки:
- Ability to analyze the frame/packet structure of protocols such as I2C/SPI/UART and TCP/IP, MQTT with AI support
- Ability to narrow down protocol errors (timing, addressing, checksum) as hypotheses with AI
- Ability to verify AI's protocol interpretation with standard document, analyzer (logic/packet) measurement
Протоколот е збир на правила за кои два уреди се согласуваат за да се разберат: со која брзина, по кој редослед, во кој формат ќе разговараат. Дали сензорот за температура зборува со микроконтролер преку I2C или уред разговара со облак сервер преку TCP/IP и MQTT се заснова на протокол. Во оваа единица, ќе видите како да користите вештачка интелигенција за да ги анализирате рамките/пакетите на протоколот, да ги стесните грешките во протоколот и да го разберете стекот на комуникациите (слоеви еден врз друг, од физичкиот слој до апликацијата). AI is powerful at explaining protocols and generating hypotheses; но што всушност прави една линија се знае само по мерењето на неговиот анализатор (логички анализатор, протокол/пакет анализатор) и стандарден документ.
Вградени сериски протоколи: I2C, SPI, UART
Chips on a board generally talk to three serial protocols:
- UART: две линии (TX/RX), без линија на часовникот; Двете страни мора да бидат поставени на иста брзина (стапка на бауд). Едноставно, но синхронизацијата зависи од брзината.
- SPI: Часовник (SCLK), влез/излез на податоци (MOSI/MISO) и изберете (CS) линии; Брз, целосно дуплекс, но бара повеќе иглички. Поларитетот/фазата на часовникот (CPOL/CPHA) мора да одговара на двете страни.
- I2C: Две линии (SDA/SCL), базирани на адреса, повеќе уреди на иста линија; отпорници за повлекување и заедничка состојба. Бавно, но економично.
AI explains very well how these protocols work, their framework structure, and typical failure causes. Систематски ги набројува можните причини (неточна адреса, недостасува повлекување, неусогласеност на брзината, отсуство на заедничка основа, караница во линија, должина на кабел/капацитивност) кога уредот I2C не реагира. Но, кое од овие е реално може да се разбере со мерење на линијата со логички анализатор и гледање на брановите SDA/SCL; ВИ ја дава хипотезата, мерењето одлучува.
Совет: во случај на неуспех на сериски протокол, прашајте ја вештачката интелигенција „да ги рангира можните причини од најверојатни до најмалку веројатни, и што и да видам на анализаторот за секоја е потврдено“. На овој начин го правите мерењето насочено; Instead of trying each reason one by one, the analyzer view takes you to the right branch.
Мрежни протоколи: TCP/IP, UDP, MQTT, CoAP
Слоевит протоколи влегуваат во игра кога уредите се поврзуваат со мрежата и облакот. Магацинот TCP/IP е во суштина слоевит: физичка/податочна врска (Ethernet, Wi-Fi), мрежа (IP: адресирање и рутирање), транспорт (TCP: сигурен, секвенцијален, контролиран со проток / UDP: брз, недоверлив) и апликација (HTTP, MQTT, CoAP). Клучни концепти:
- TCP vs UDP: TCP компензира за загубата и гарантира редослед, но воведува латентност и надземни трошоци; UDP е брз, но нема гаранција за испорака (аудио/видео во реално време се претпочита за телеметрија).
- MQTT: Лесен протокол за IoT пораки што работи со моделот објавување-претплати; пораки преку теми преку брокер. QoS нивоата поставуваат гаранција за испорака.
- CoAP: лесен протокол базиран на UDP сличен на HTTP за ограничени уреди.
Вештачката интелигенција ја анализира структурата на рамката/пакетот на овие протоколи, ви помага да го интерпретирате снимањето на Wireshark (анализатор на пакети) и да го прегледа дизајнот на темата MQTT. Но, она што е вистинскиот сообраќај се потврдува со фаќање пакети, а однесувањето на серверот се потврдува со вистинско тестирање.
Checksum, CRC and framing
Повеќето протоколи користат контролна сума или CRC (Cyclic Redundancy Check) за да проверат дали податоците не се оштетени: испраќачот пресметува вредност за верификација од податоците, примачот ја прави истата пресметка и споредува. Вештачката интелигенција опишува и запишува код за пресметување на CRC/проверка, но деталите како што се избор на полином, ендијанност, почетна вредност итн. се специфични за стандардот; Кодот CRC генериран од AI мора да се спореди дословно со официјалната дефиниција на протоколот и да се потврди со познат тест вектор.
три мини футроли
Случај 1 - Нецелосно повлекување. Тимот не може да работи сензор I2C на табла; не ја потврдува адресата на уредот (нема ACK). Вештачката интелигенција како најверојатна причина ги наведува недостатокот на отпорник за повлекување и заедничка основа. Кога се гледа линијата SDA со логички анализатор, се гледа дека сигналот не може целосно да го достигне високото ниво; Комуникацијата започнува кога ќе се додадат отпорници за повлекување. Лекција: ВИ ја истакна најверојатната причина, анализаторот ја потврди.
Случај 2 - Погрешен режим на SPI. Еден инженер чита џагор податоци од SPI уред. AI предлага несовпаѓање на поларитетот/фазата на часовникот (CPOL/CPHA) како можна причина. Во анализаторот, се чини дека часовникот се мостри поинаку од работ што го очекува уредот; Кога режимот се коригира, податоците стануваат значајни. Лекција: Симптомот „податоци, но глупости“ во SPI е најчесто несовпаѓање на режимот; мерењето го прави ова јасно.
Случај 3 - MQTT QoS недоразбирање. Практикантот испраќа телеметрија преку MQTT, но гледа дека некои пораки се изгубени и ја прашува вештачката интелигенција. AI наведува дека QoS 0 е „најмногу еднаш, испораката не е загарантирана“; Објаснува дека QoS 1/2 е потребен за гаранција за испорака, но ова воведува надземни трошоци и доцнење. Практикантот се префрла на QoS 1 врз основа на критичноста на телеметрија и го потврдува однесувањето на брокерот со вистинско тестирање. Лекција: Објаснете ја опцијата за протокол на AI; Правилниот избор се прави според апликацијата и се проверува со тестирање.
Шаблони за копирање на брзините
шаблон за навигација за неуспех во ПРОТОКОЛ"[I2C/SPI/UART/TCP/MQTT] комуникацијата го има следниов симптом: [симптом]. Рангирајте ги можните причини од НАЈВЕРОЈАТНО до Најмалку веројатни. За секоја причина: (1) зошто го дава овој симптом, (2) што и да видам на анализаторот на анализаторот (види/ме) ELIMINATED. DO NOT MAKE a definitive diagnosis; I narrow down by measurement. decision tree emerges."
РАМКИ/ШАБЕЛ ЗА АНАЛИЗА НА РАМКИ/ПАКЕТ „Скршете ја следнава содржина [I2C/SPI/UART бајт низа / фаќање пакети] во полиња и опишете го секое поле (адреса, команда, податоци, контролна сума/CRC, знаменце). Јасно наведете ја вашата претпоставка за ендијалноста и редоследот на битови. Имајте предвид дека треба да го проверам вашиот протокол со официјалниот протокол и описот на податоците. [паста]."
шаблон за проверка на CRC/CHECKSUM“Опишете ја пресметката на CRC/проверената сума за [протокол]: полином, почетна вредност, редослед на битови, конечна
ОБРАБОТ ЗА ИЗБОР НА ПРОТОКОЛ "Спроведете споредба на протоколот за транспорт/апликација за следната апликација: [барање: гаранција за испорака, латентност, моќност, пропусен опсег, ограничување на уредот]. Споредете ги TCP/UDP и MQTT/CoAP/HTTP опциите со овие критериуми. НЕ НАМЕТУВАЈТЕ јасен избор; рамнотежата на секоја опција за тестирање треба да биде утврдена.
Слаб промпт / Силен промпт
СЛАБ ПРЕСТАВ: "I2C не работи, зошто?"
СИЛНО ПРЕКЛУЧУВАЊЕ: „Мојот I2C сензор не ACK (адресата не е потврдена). Наведете ги можните причини почнувајќи од најверојатните: повлекување, заедничка основа, погрешна адреса, брзина, капацитет на кабелот, расправија. За секоја причина, напишете што и да видам на SDA/SCL на логичкиот анализатор, се потврдува, што не гледам, дијагнозата може да се елиминира со листа надолу. мерење“.
The weak prompt produces a single guess; Моќното известување обезбедува дијагностичка карта што може да се намали до мерење, нарачана и проверлива.
Табела за споредба на протоколи
протокол
Тип
силна точка
алатка за верификација
УАРТ
Серии, без часовник
Едноставно, две линии
Логички анализатор
СПИ
Сериски, такт
Брз, целосно дуплекс
Логички анализатор (CPOL/CPHA)
I2C
Сериски, адресибилен
Многу уреди, малку иглички
Анализатор (ACK, влечење)
TCP
мрежа, транспорт
Сигурен, со цел
Анализатор на пакети (Wireshark)
UDP
мрежа, транспорт
Брза, мала латентност
анализатор на пакети
MQTT
Апликација
Лесен, паб/под, QoS
Дневник на брокер + фаќање пакети
Внимание: Интерпретацијата на ВИ е брзо, но вештачката интелигенција може погрешно да го преземе редоследот на битови или границата на полето. Потврдете ја секоја анализа според официјалниот опис на протоколот и познатиот тест вектор.
Вообичаени грешки
- Промена врз основа на предвидување со вештачка интелигенција без мерење на причината за дефектот. Погледот на анализаторот ве води до вистинската причина.
- Игнорирање на усогласеноста со CPOL/CPHA во SPI. „Има податоци, но тоа е бесмислица“ често е некомпатибилност на режимот.
- Заборавајќи го повлекувањето и заедничката основа на I2C. Тоа е најчеста причина за „не работи воопшто“.
- Претпоставувајќи ги параметрите на CRC. Полином, почеток, редослед на битови се специфични за стандардот; Се проверува со векторот на тестот.
- Збунувачки MQTT QoS со гаранција за испорака. QoS 0 не гарантира; Изборот е направен и тестиран според апликацијата.
Сумирано
Во оваа единица користевте вештачка интелигенција како моќна помош во објаснувањето на протоколи како што се I2C/SPI/UART и TCP/IP, MQTT, анализа на рамка/пакет и систематско стеснување на причините за дефекти. Но, протоколите се прецизни и стандардно врзани: што всушност прави линијата се одредува со логички/пакет анализатор, точноста на анализата се одредува со формалната дефиниција и тест-вектор, причината за дефектот се одредува со мерење. Насочете ја вештачката интелигенција да ја даде „најверојатната причина и мерењето да ја потврди“; Нека одлучуваат анализаторот и стандардот.
Задача за апликација
Изберете сценарио за неуспех на серискиот протокол (на пр. нема I2C ACK). Побарајте секвенцијална дијагностичка карта која може да се провери со мерење од вештачката интелигенција со шаблонот „стеснување на грешка во протоколот“. Потоа земете примерок од низа бајти (на пр. рамка за читање сензор) и распоредете ја со шаблонот „Рамка/парсирање пакети“ и забележете ја претпоставката за ендијансност. Конечно, проверете го кодот CRC во однос на познат тест вектор со шаблонот „CRC/checksum verification“.
листа за проверка
- [ ] Ја потврдив причината за неуспехот со мерење на анализаторот, а не со предвидување со вештачка интелигенција.
- [ ] Наведов CPOL/CPHA на SPI, адреса/повлекување/заедничка контрола на теренот на I2C.
- [ ] Го споредив парсирањето на рамка/пакет со официјалната дефиниција на протоколот.
- [ ] Ги потврдив параметрите CRC/checksum со тест векторот.
- [ ] Го направив изборот на протоколот за транспорт/апликација според барањето и го тестирав со вистинско тестирање.
- [ ] Правилно го протолкував значењето на гаранцијата за испорака на MQTT QoS.