Comment créer un protocole de communication UART sûr?

8

Je me demandais comment créer un protocole de communication UART / USB sûr. J'en ai besoin pour la communication entre un microcontrôleur et un PC. J'ai ~ 10 commandes et j'ai pensé utiliser 10 commandes d'accusé de réception distinctes pour chacune d'entre elles.

L'échange devrait se dérouler comme suit:

  • Le PC envoie une commande de réveil via UART
  • µC reconnaît que le PC est connecté et envoie sa commande au PC, par exemple. 0x01
  • Le PC fait ce qui lui a été demandé (certains éléments matériels) et répond ~0x01quand c'est fait (je nie le nombre pour créer une "distance" plus grande entre les deux nombres)
  • µC sait qu'il a envoyé 0x01et attend ~0x01du PC. Si autre chose que ~0x01revient, le µC saura que quelque chose s'est mal passé et enverra une nouvelle demande ou un message d'erreur

Le cas que le µC envoie 0x01, le PC comprend 0x02et renvoie ~0x02mais le µC lit à ~0x01cause d'un certain bruit serait assez mauvais.

Dans quelle mesure est-ce sûr en termes de transmission, ou comment puis-je le rendre plus sûr?

JavaForStarters
la source
1
Vous voudrez peut-être revoir ma question connexe et ses très bonnes réponses.
Eugene Sh.
1
Par "plus sûr", je suppose que vous entendez moins enclin aux erreurs de transmission, pas l'ajout de crypto, etc. pour résister à l'écoute et quoi d'autre. Même juste, c'est un domaine assez vaste: en.wikipedia.org/wiki/Error_detection_and_correction
Fizz
2
Vous voudrez peut-être rechercher le codage Hamming . Il prendra jusqu'à 16 commandes (4 bits) et les étendra de manière systématique à 7 bits (qui peuvent être transmises sur un UART standard). Vous pouvez choisir de corriger toute erreur sur un seul bit ou de détecter si deux bits ont été mal reçus.
Neil_UK
2
1) 7 bits + un bit de parité est à sens unique et c'est simple. Il n'attrapera pas toutes les erreurs possibles mais en attrapera plusieurs. 2) Une méthode plus robuste consiste à envoyer deux octets, d'abord avec la commande réelle et ensuite avec le «non» de la première commande. 3) Encore mieux est d'envoyer un octet de «commande à venir», suivi de la commande, suivi du compliment de la commande, suivi d'un octet de «fin de commande». Les octets «commande à venir» et «fin de commande» doivent être sélectionnés pour ne pas se superposer à aucun des octets de commande et de commande complémentaire
user3629249
1
Si vous n'avez besoin que de 10 commandes, vous pouvez tenir deux copies dans chaque octet (pour la redondance), plus les bits de parité. Ou comme vous avez un espace de symboles de 256 symboles et que vous n'en avez besoin que de 10, vous pouvez simplement choisir des symboles différents au maximum (tous les symboles diffèrent par plusieurs bits), ou choisir uniquement des symboles avec des nombres pairs de uns et de zéros. Vous n'avez certainement pas à vous soucier des erreurs sur un seul bit.
mkeith

Réponses:

1

Je pense que vous devez définir des commandes plus longues, y compris probablement la somme de contrôle ou CRC et attendre un ACK / NACK ou une condition d'erreur.

Vous pouvez prendre des exemples de protocoles simples comme TFTP ( RFC 1350 )

Tapoter
la source
1

Pour une communication sûre, vous devez considérer tous les threads possibles sur votre ligne de communication. Par conséquent, vous devez définir si le système est accessible de l'extérieur (systèmes tiers, par exemple sans fil)

En général, vous devez penser aux fils suivants:

  • répétition
  • omission
  • rééquilibrage
  • manipulation
  • retard
  • insertion
  • la corruption

Les mesures standard contre les fils sont:

  • Séquençage ou horodatages
  • supervision du temps
  • codes source et destination uniques
  • réponse
  • priorité d'identification
  • une sorte de somme de contrôle, de code de hachage ...
  • des techniques de cryographie que vous avez déjà implémentées avec votre protocole simple.
user2572309
la source