Gains :
- Capacité à analyser la structure trame/paquet de protocoles tels que I2C/SPI/UART et TCP/IP, MQTT avec prise en charge de l'IA
- Capacité à affiner les erreurs de protocole (synchronisation, adressage, somme de contrôle) en tant qu'hypothèses avec l'IA
- Capacité à vérifier l'interprétation du protocole de l'IA avec un document standard, une mesure par analyseur (logique/paquet)
Un protocole est un ensemble de règles sur lesquelles deux appareils s'accordent pour se comprendre : à quelle vitesse, dans quel ordre, dans quel format ils vont parler. Qu'un capteur de température communique avec un microcontrôleur via I2C ou qu'un appareil communique avec un serveur cloud via TCP/IP et MQTT est basé sur un protocole. Dans cette unité, vous verrez comment utiliser l'IA pour analyser les trames/paquets de protocole, affiner les erreurs de protocole et comprendre la pile de communications (couches les unes sur les autres, de la couche physique à l'application). L’IA est puissante pour expliquer les protocoles et générer des hypothèses ; mais ce que fait réellement une ligne n'est connu que par les mesures de son analyseur (analyseur logique, analyseur de protocole/paquet) et par son document standard.
Protocoles série intégrés : I2C, SPI, UART
Les puces d'une carte communiquent généralement avec trois protocoles série :
- UART : deux lignes (TX/RX), pas de ligne d'horloge ; Les deux côtés doivent être réglés sur la même vitesse (débit en bauds). Simple mais la synchronisation dépend de la vitesse.
- SPI : horloge (SCLK), lignes d'entrée/sortie de données (MOSI/MISO) et de sélection (CS); Rapide, full duplex, mais nécessite plus de broches. La polarité/phase de l'horloge (CPOL/CPHA) doit correspondre des deux côtés.
- I2C : deux lignes (SDA/SCL), basées sur l'adresse, plusieurs appareils sur la même ligne ; résistances de rappel et condition de masse commune. Lent mais économique.
L'IA explique très bien le fonctionnement de ces protocoles, leur structure et les causes typiques des échecs. Répertorie systématiquement les causes possibles (adresse incorrecte, pull-up manquant, inadéquation de vitesse, absence de masse commune, conflit de ligne, longueur/capacité du câble) lorsqu'un périphérique I2C ne répond plus. Mais lequel de ces éléments est réel peut être compris en mesurant la ligne avec un analyseur logique et en regardant les ondes SDA/SCL ; L’IA donne l’hypothèse, la mesure décide.
Astuce : en cas de défaillance du protocole série, demandez à l'IA de "classer les causes possibles de la plus probable à la moins probable, et tout ce que je vois sur l'analyseur pour chacune est confirmé". De cette façon, vous effectuez la mesure de manière ciblée ; Au lieu d’essayer chaque raison une par une, la vue de l’analyseur vous amène à la bonne branche.
Protocoles réseau : TCP/IP, UDP, MQTT, CoAP
Les protocoles en couches entrent en jeu lorsque les appareils se connectent au réseau et au cloud. La pile TCP/IP est essentiellement en couches : liaison physique/données (Ethernet, Wi-Fi), réseau (IP : adressage et routage), transport (TCP : fiable, séquentiel, contrôlé de flux / UDP : rapide, sans confiance) et application (HTTP, MQTT, CoAP). Notions clés :
- TCP vs UDP : TCP compense la perte et garantit l'ordre mais introduit de la latence et des frais généraux ; UDP est rapide mais n'a aucune garantie de livraison (audio/vidéo en temps réel préféré pour la télémétrie).
- MQTT : protocole de messagerie IoT léger qui fonctionne avec le modèle de publication-abonnement ; messagerie via des sujets via un courtier. Les niveaux de QoS définissent l’assurance de livraison.
- CoAP : protocole léger de type HTTP, basé sur UDP, pour les appareils restreints.
L'IA analyse la structure trame/paquet de ces protocoles, vous aide à interpréter une capture Wireshark (analyseur de paquets) et examine la conception d'un sujet MQTT. Mais le trafic réel est vérifié par la capture de paquets, et le comportement du serveur est vérifié par des tests réels.
Somme de contrôle, CRC et cadrage
La plupart des protocoles utilisent une somme de contrôle ou CRC (Cyclic Redundancy Check) pour vérifier que les données ne sont pas corrompues : l'expéditeur calcule une valeur de vérification à partir des données, le destinataire fait le même calcul et compare. L'IA décrit et écrit le code pour le calcul du CRC/somme de contrôle, mais les détails tels que la sélection polynomiale, l'endianité, la valeur initiale, etc. sont spécifiques à la norme ; Le code CRC généré par l'IA doit être comparé textuellement à la définition officielle du protocole et vérifié par rapport à un vecteur de test connu.
trois mini-cases
Cas 1 — Pull-up incomplet. Une équipe ne peut pas exécuter un capteur I2C sur une maquette ; ne reconnaît pas l'adresse de l'appareil (pas d'ACK). L'IA répertorie l'absence de résistance de rappel et de masse commune comme cause la plus probable. En regardant la ligne SDA avec un analyseur logique, on constate que le signal ne peut pas atteindre complètement le niveau haut ; La communication démarre lorsque des résistances de rappel sont ajoutées. Leçon : l'IA a mis en évidence la cause la plus probable, l'analyseur l'a confirmée.
Cas 2 — Mauvais mode SPI. Un ingénieur lit des données charabia provenant d'un appareil SPI. L'IA suggère une inadéquation polarité/phase d'horloge (CPOL/CPHA) comme cause possible. Dans l’analyseur, l’horloge semble échantillonner différemment du front attendu par l’appareil ; Lorsque le mode est corrigé, les données deviennent significatives. Leçon : Le symptôme « données mais absurdes » dans SPI est le plus souvent une inadéquation de mode ; la mesure le montre clairement.
Cas 3 — Incompréhension de la qualité de service MQTT. Un stagiaire envoie des télémétries via MQTT mais voit que certains messages sont perdus et demande à l'IA. AI déclare que la QoS 0 est « au plus une fois, la livraison n'est pas garantie » ; Explique que QoS 1/2 est requis pour garantir la livraison, mais cela introduit une surcharge et des retards. Le stagiaire passe à QoS 1 en fonction de la criticité de la télémétrie et vérifie le comportement du courtier avec des tests réels. Leçon : Expliquez l'option du protocole AI ; Le bon choix est fait en fonction de l'application et vérifié par des tests.
Modèles d'invite copiables
MODÈLE DE NAVIGATION DE DÉFAILLANCE DE PROTOCOLE "[I2C/SPI/UART/TCP/MQTT] présente le symptôme suivant : [symptôme]. Classez les causes possibles de la PLUS PROBABLE à la moins probable. Pour chaque cause : (1) pourquoi donne-t-il ce symptôme, (2) tout ce que je vois sur l'analyseur/la mesure est CONFIRMÉ, (3) tout ce que je vois est ÉLIMINÉ. NE FAITES PAS de diagnostic définitif ; je précise par la mesure, un arbre de décision émerge.
MODÈLE D'ANALYSE DE CADRE/PAQUET "Divisez le contenu suivant [tableau d'octets / capture de paquets I2C/SPI/UART] en champs et décrivez chaque champ (adresse, commande, données, somme de contrôle/CRC, indicateur). Énoncez clairement votre hypothèse sur le boutisme et l'ordre des bits. Notez que je dois vérifier votre commentaire avec la description officielle du protocole et un vecteur de test. Données : [coller]."
MODÈLE DE VÉRIFICATION CRC/CHECKSUM"Décrire le calcul CRC/checksum pour [protocole] : polynôme, valeur initiale, ordre des bits, final
MODÈLE DE SÉLECTION DE PROTOCOLE « Effectuer une comparaison des protocoles de transport/d'application pour l'application suivante : [exigence : garantie de livraison, latence, puissance, bande passante, contrainte de périphérique]. Comparez les options TCP/UDP et MQTT/CoAP/HTTP avec ces critères. N'IMPOSEZ PAS un choix clair ; équilibrez chaque option et indiquez que le choix doit être vérifié par des tests réels. "
Invite faible/Invite forte
INVITE FAIBLE : « I2C ne fonctionne pas, pourquoi ? »
INVITE FORTE : "Mon capteur I2C n'acquiert pas (adresse non reconnue). Répertoriez les causes possibles en commençant par les plus probables : pull-up, masse commune, mauvaise adresse, vitesse, capacité du câble, contention. Pour chaque cause, écrivez tout ce que je vois sur le SDA/SCL sur l'analyseur logique est confirmé, tout ce que je vois est éliminé. Ne faites pas de diagnostic ; je veux une liste que je peux affiner par mesure. "
L'invite faible produit une seule supposition ; L'invite puissante fournit une carte de diagnostic qui peut être réduite à des mesures, ordonnées et vérifiables.
Tableau de comparaison des protocoles
protocole
Tapez
point fort
outil de vérification
UART
Série, sans horloge
Simple, deux lignes
Analyseur logique
ISP
Série, cadencé
Rapide et full duplex
Analyseur logique (CPOL/CPHA)
I2C
Série, adressable
De nombreux appareils, peu de broches
Analyseur (ACK, pull-up)
TCP
réseau, transports
Fiable, afin
Analyseur de paquets (Wireshark)
UDP
réseau, transports
Rapide et faible latence
analyseur de paquets
MQTT
Demande
Léger, pub/sub, QoS
Journal du courtier + capture de paquets
Attention : Demander à l'IA d'interpréter une capture de protocole est rapide, mais l'IA peut supposer de manière incorrecte l'ordre des bits ou la limite du champ. Vérifiez chaque analyse par rapport à la description officielle du protocole et à un vecteur de test connu.
Erreurs courantes
- Changez-le en fonction de la prédiction de l'IA sans mesurer la cause du défaut. La vue de l'analyseur vous mène à la bonne cause.
- Ignorer la conformité CPOL/CPHA dans SPI. "Il y a des données mais c'est absurde" est souvent une incompatibilité de mode.
- Oublier le pull-up et le terrain d'entente sur I2C. C'est la cause la plus courante de « ne fonctionne pas du tout ».
- En supposant les paramètres CRC. Le polynôme, le début, l'ordre des bits sont spécifiques au standard ; Elle est vérifiée avec le vecteur test.
- Confondre MQTT QoS avec garantie de livraison. QoS 0 ne garantit pas ; La sélection est effectuée et testée en fonction de l'application.
En résumé
Dans cette unité, vous avez utilisé l'IA comme une aide puissante pour expliquer des protocoles tels que I2C/SPI/UART et TCP/IP, MQTT, l'analyse de trames/paquets et pour réduire systématiquement les causes de pannes. Mais les protocoles sont précis et limités par des normes : ce que fait réellement une ligne est déterminé par un analyseur logique/de paquets, la précision d'une analyse est déterminée par la définition formelle et le vecteur de test, la cause d'un défaut est déterminée par la mesure. Ordonner à l’IA de donner « la cause la plus probable et la mesure pour la confirmer » ; Laissez l’analyseur et l’étalon décider.
Tâche de candidature
Sélectionnez un scénario d'échec du protocole série (par exemple, pas d'ACK I2C). Demandez à AI une carte de diagnostic séquentielle et vérifiable par mesure avec le modèle de « rétrécissement des défauts de protocole ». Ensuite, prenez un exemple de tableau d'octets (par exemple un cadre de lecture de capteur) et espacez-le avec le modèle "Analyse de trame/paquet" et notez l'hypothèse d'endianité. Enfin, vérifiez un code CRC par rapport à un vecteur de test connu avec le modèle « Vérification CRC/somme de contrôle ».
liste de contrôle
- [ ] J'ai confirmé la cause de l'échec par la mesure de l'analyseur, et non par la prédiction de l'IA.
- [ ] J'ai répertorié CPOL/CPHA sur SPI, adresse/pull-up/contrôle de terrain commun sur I2C.
- [ ] J'ai comparé l'analyse des trames/paquets avec la définition officielle du protocole.
- [ ] J'ai vérifié les paramètres CRC/checksum avec le vecteur de test.
- [ ] J'ai fait la sélection du protocole de transport/application en fonction des exigences et je l'ai testé avec des tests réels.
- [ ] J'ai correctement interprété la signification de la garantie de livraison de MQTT QoS.