Добици:
- Способност анализе структуре оквира/пакета протокола као што су И2Ц/СПИ/УАРТ и ТЦП/ИП, МКТТ са подршком АИ
- Способност сужавања грешака у протоколу (тајминг, адресирање, контролни збир) као хипотезе са АИ
- Способност да се верификује тумачење АИ протокола са стандардним документом, мерењем анализатора (логичког/пакета)
Протокол је скуп правила о којима се два уређаја слажу да би се разумели: којом брзином, којим редоследом, у ком формату ће разговарати. Било да сензор температуре разговара са микроконтролером преко И2Ц или уређај разговара са сервером у облаку преко ТЦП/ИП и МКТТ заснован је на протоколу. У овој јединици ћете видети како да користите АИ за анализу оквира/пакета протокола, сузите грешке у протоколу и разумете комуникацијски стек (слојеви један на другом, од физичког слоја до апликације). АИ је моћан у објашњавању протокола и генерисању хипотеза; али шта линија заправо ради зна се само по мерењу њеног анализатора (логички анализатор, анализатор протокола/пакета) и стандардном документу.
Уграђени серијски протоколи: И2Ц, СПИ, УАРТ
Чипови на плочи углавном разговарају са три серијска протокола:
- УАРТ: две линије (ТКС/РКС), без такта; Обе стране морају бити подешене на исту брзину (брзина преноса). Једноставна, али синхронизација зависи од брзине.
- СПИ: Сат (СЦЛК), улаз/излаз података (МОСИ/МИСО) и избор (ЦС) линија; Брз, пуни дуплекс, али захтева више пинова. Поларитет/фаза сата (ЦПОЛ/ЦПХА) мора да се подудара са обе стране.
- И2Ц: Две линије (СДА/СЦЛ), базирано на адреси, више уређаја на истој линији; пулл-уп отпорници и заједничко стање уземљења. Споро, али економично.
АИ веома добро објашњава како ови протоколи функционишу, њихову структуру оквира и типичне узроке неуспеха. Систематски наводи могуће узроке (нетачна адреса, недостатак повлачења, неусклађеност брзине, одсуство заједничког уземљења, сукоб у линији, дужина кабла/капацитивност) када И2Ц уређај престане да реагује. Али шта је од овога стварно може се разумети мерењем линије помоћу логичког анализатора и посматрањем СДА/СЦЛ таласа; АИ даје хипотезу, мерење одлучује.
Савет: У случају квара серијског протокола, питајте АИ „рангирај могуће узроке од највероватнијих до најмање вероватних, и све што видим на анализатору за сваки је потврђено“. На овај начин циљате мерење; Уместо да испробавате сваки разлог један по један, приказ анализатора вас води на десну грану.
Мрежни протоколи: ТЦП/ИП, УДП, МКТТ, ЦоАП
Слојевити протоколи долазе у игру док се уређаји повезују на мрежу и облак. ТЦП/ИП стек је у суштини слојевит: физичка/дата веза (Етхернет, Ви-Фи), мрежа (ИП: адресирање и рутирање), транспорт (ТЦП: поуздан, секвенцијалан, контролисан протоком / УДП: брз, без поверења) и апликација (ХТТП, МКТТ, ЦоАП). Кључни концепти:
- ТЦП наспрам УДП: ТЦП компензује губитак и гарантује ред, али уводи кашњење и надметање; УДП је брз, али нема гаранцију испоруке (аудио/видео у реалном времену преферирано за телеметрију).
- МКТТ: Лагани ИоТ протокол за размену порука који ради са моделом објављивања-претплате; слање порука преко тема преко брокера. КоС нивои постављају осигурање испоруке.
- ЦоАП: лагани протокол налик на ХТТП, заснован на УДП-у за ограничене уређаје.
АИ анализира структуру оквира/пакета ових протокола, помаже вам да тумачите Виресхарк (анализатор пакета) хватање и прегледа МКТТ дизајн теме. Али шта је прави саобраћај се проверава хватањем пакета, а понашање сервера се проверава правим тестирањем.
Контролни збир, ЦРЦ и кадрирање
Већина протокола користи контролни збир или ЦРЦ (Цицлиц Редунданци Цхецк) за проверу да подаци нису оштећени: пошиљалац израчунава верификациону вредност из података, прималац ради исти прорачун и упоређује. АИ описује и пише код за израчунавање ЦРЦ/контролне суме, али детаљи као што су избор полинома, ендианнесс, почетна вредност итд. су специфични за стандард; ЦРЦ код који генерише АИ мора се дословно упоредити са званичном дефиницијом протокола и верификован у односу на познати тест вектор.
три мини кофера
Случај 1 — Непотпуно повлачење. Тим не може да покрене И2Ц сензор на матичној плочи; не признаје адресу уређаја (нема АЦК). АИ наводи недостатак отпорника за повлачење и заједничког уземљења као највероватнији узрок. Када се логичким анализатором погледа СДА линија, види се да сигнал не може у потпуности достићи високи ниво; Комуникација почиње када се додају пулл-уп отпорници. Лекција: АИ је истакао највероватнији узрок, анализатор је то потврдио.
Случај 2 — Погрешан СПИ режим. Инжењер чита бесмислице са СПИ уређаја. АИ предлаже неслагање поларитета/фазе сата (ЦПОЛ/ЦПХА) као могући узрок. У анализатору се чини да сат узоркује другачије од ивице коју уређај очекује; Када се режим коригује, подаци постају значајни. Поука: Симптом „подаци, али бесмислица“ у СПИ је најчешће неусклађеност режима; мерење ово чини јасним.
Случај 3 — МКТТ КоС неспоразум. Стажиста шаље телеметрију преко МКТТ-а, али види да су неке поруке изгубљене и пита АИ. АИ наводи да је КоС 0 „највише једном, испорука није загарантована“; Објашњава да је КоС 1/2 потребан да би се гарантовала испорука, али то доводи до додатних трошкова и кашњења. Приправник прелази на КоС 1 на основу критичности телеметрије и проверава понашање брокера стварним тестирањем. Лекција: Објасните опцију АИ протокола; Тачан избор се врши према апликацији и проверава тестирањем.
Шаблони упита који се могу копирати
ШАБЛОНА ЗА НАВИГАЦИЈУ КВАРА ПРОТОКОЛА"[И2Ц/СПИ/УАРТ/ТЦП/МКТТ] комуникација има следећи симптом: [симптом]. Рангирајте могуће узроке од НАЈВЕРОВАТНИЈЕ до најмање вероватније. За сваки узрок: (1) зашто даје овај симптом, (2) шта год видим на анализатору је (видим) ПОТВРЂУЈЕМ. ЕЛИМИНИСАН НЕМОЈТЕ ПОСТАВИТИ коначну дијагнозу;
ШАБЛОНА ЗА АНАЛИЗУ ОКВИРА/ПАКЕТА „Разбијте следећи садржај [И2Ц/СПИ/УАРТ низ бајтова/хватање пакета] у поља и опишите свако поље (адреса, команда, подаци, контролни збир/ЦРЦ, заставица). Јасно изнесите своју претпоставку о ендианнессу и редоследу битова. Имајте на уму да морам да проверим ваш коментар са званичним описом вектора и провером. [налепи]."
ЦРЦ/ШАБЛОНА ЗА ВЕРИФИКАЦИЈУ КОНТРОЛНЕ СУМЕ"Опишите израчунавање ЦРЦ/контролне суме за [протокол]: полином, почетна вредност, ред битова, коначни
ШАБЛОНА ЗА ИЗБОР ПРОТОКОЛА „Спроведите поређење протокола транспорта/апликације за следећу апликацију: [захтев: гаранција испоруке, кашњење, снага, пропусни опсег, ограничење уређаја]. Упоредите ТЦП/УДП и МКТТ/ЦоАП/ХТТП опције са овим критеријумима. НЕМОЈТЕ НАМЕТНУТИ јасан избор; балансирајте сваку опцију и наведите да стварни избор треба да буде верификован."
Слаби промпт / Јаки промпт
ВЕАК ПРОМПТ: "И2Ц не ради, зашто?"
СНАЖНА УПИТКА: „Мој И2Ц сензор не АЦК (адреса није потврђена). Наведите могуће узроке почевши од највероватнијег: повлачење, заједничка маса, погрешна адреса, брзина, капацитет кабла, свађа. За сваки узрок, напишите шта год видим на СДА/СЦЛ на логичком анализатору је потврђено, шта год да видим је елиминисана дијагноза надоле.
Слаб промпт производи једно нагађање; Моћни упит пружа дијагностичку мапу која се може сузити на мерење, наручити и проверити.
Табела поређења протокола
протокола
Тип
јака тачка
алат за верификацију
УАРТ
Серија, без сата
Једноставно, два реда
Логички анализатор
СПИ
Серијски, такт
Брз, пун дуплекс
Логички анализатор (ЦПОЛ/ЦПХА)
И2Ц
Серијски, адресабилни
Много уређаја, неколико пинова
Анализатор (АЦК, пулл-уп)
ТЦП
мрежа, транспорт
Поуздан, у реду
Анализатор пакета (Виресхарк)
УДП
мрежа, транспорт
Брзо, мало кашњење
анализатор пакета
МКТТ
Апликација
Лаган, пуб/суб, КоС
Дневник брокера + хватање пакета
Опрез: АИ тумачење снимања протокола је брзо, али АИ може погрешно да претпостави редослед битова или границу поља. Верификујте сваку анализу у односу на званични опис протокола и познати вектор тестирања.
Уобичајене грешке
- Промена на основу АИ предвиђања без мерења узрока грешке. Поглед анализатора води вас до правог узрока.
- Игнорисање усклађености са ЦПОЛ/ЦПХА у СПИ. „Постоје подаци, али то је бесмислица“ често је некомпатибилност режима.
- Заборављајући на повлачење и заједнички терен на И2Ц. То је најчешћи узрок „уопште не ради“.
- Уз претпоставку ЦРЦ параметара. Полином, почетак, ред битова су специфични за стандард; Верификује се тест вектором.
- Збуњујући МКТТ КоС са гаранцијом испоруке. КоС 0 не гарантује; Избор се врши и тестира према апликацији.
Укратко
У овој јединици сте користили АИ као моћну помоћ у објашњавању протокола као што су И2Ц/СПИ/УАРТ и ТЦП/ИП, МКТТ, анализа оквира/пакета и систематско сужавање узрока грешака. Али протоколи су прецизни и стандардно ограничени: оно што линија заправо ради одређује логички/пакетни анализатор, тачност анализе одређена је формалном дефиницијом и тест вектором, узрок грешке се утврђује мерењем. Усмерите АИ да да „највероватнији узрок и мерење да га потврди“; Нека одлучи анализатор и стандард.
Задатак апликације
Изаберите сценарио неуспеха серијског протокола (нпр. нема И2Ц АЦК). Затражите секвенцијалну дијагностичку мапу која се може проверити мерењем од АИ са шаблоном „сужавање грешке у протоколу“. Затим узмите узорак низа бајтова (нпр. оквир за читање сензора) и размакните га шаблоном „Распоређивање оквира/пакета“ и забележите претпоставку о ендианнессу. Коначно, проверите ЦРЦ код према познатом тест вектору помоћу шаблона „ЦРЦ/верификација контролне суме“.
контролна листа
- [ ] Потврдио сам узрок квара мерењем анализатора, а не предвиђањем вештачке интелигенције.
- [ ] Навео сам ЦПОЛ/ЦПХА на СПИ, адресу/пулл-уп/заједничку земаљску контролу на И2Ц.
- [ ] Упоредио сам рашчлањивање оквира/пакета са званичном дефиницијом протокола.
- [ ] Проверио сам параметре ЦРЦ/контролне суме са тест вектором.
- [ ] Направио сам избор протокола за транспорт/апликацију према захтеву и тестирао га правим тестирањем.
- [ ] Исправно сам протумачио значење гаранције испоруке за МКТТ КоС.