Je travaille sur un protocole de communication entre les périphériques embarqués. Le protocole aura certainement besoin de nouvelles commandes et champs dans le futur. Que dois-je faire pour m'assurer que je ne me peins pas dans un coin?Lignes directrices pour la conception de protocoles de communication compatibles avant?
Ceci est une question très ouverte. Voici quelques pensées au hasard à ce sujet:
En résumé, Laisser des pièces de rechange.
La question est un peu trop générale pour une réponse claire. Il y a de nombreux aspects qu'un système embarqué peut avoir besoin de communiquer comme;
De combien de pairs aura-t-il besoin pour communiquer? De combien de données a-t-elle besoin pour communiquer? À quel point les systèmes doivent-ils être synchronisés? Quel est le support physique pour le protocole et quelles sont les limitations de bande passante et les considérations de susceptibilité aux erreurs? Toutes ces exigences et limitations de ressources vont certainement contraindre le système et vous pouvez commencer à comprendre ce dont le protocole aura besoin. Une fois que vous connaissez ces problèmes, vous pouvez ensuite prévoir comment certaines exigences peuvent changer/se développer à l'avenir. De là, vous pouvez concevoir le protocole pour accommoder (ou non) les cas d'utilisation les plus défavorables.
J'utiliserais HDLC. J'ai eu de la chance avec ça dans le passé. Je voudrais pointer vers un point de série juste utiliser le Asynchronous framing et oublier tous les autres trucs de contrôle car ce serait probablement trop.
En plus d'utiliser HDLC pour le cadrage du paquet. Je formate mon paquet comme suit. Voici comment les options sont passées à l'aide 802,11
U8 cmd;
U8 len;
u8 payload[len];
La taille totale de chaque paquet de commande est len 2
Vous définissez ensuite des commandes comme
#define TRIGGER_SENSOR 0x01
#define SENSOR_RESPONSE 0x02
L'autre avantage est que vous pouvez ajouter nouvelles commandes et si vous concevez votre analyseur correctement pour ignorer les commandes non définies, vous aurez une certaine rétrocompatibilité.
Donc, en mettant tous ensemble le paquet ressemblerait à ce qui suit.
// total packet length minus flags len+4
U8 sflag; //0x7e start of packet end of packet flag from HDLC
U8 cmd; //tells the other side what to do.
U8 len; // payload length
U8 payload[len]; // could be zero len
U16 crc;
U8 eflag; //end of frame flag
Le système va alors surveiller le flux de série pour le 0x7e drapeau et quand il est là, vous vérifiez la longueur pour voir si elle est pklen> = 4 et pklen = len + 4 et que le crc est valide. Remarque ne comptez pas sur crc seulement pour les petits paquets, vous obtiendrez beaucoup de faux positifs également vérifier la longueur.Si la longueur ou le crc ne correspond pas, il suffit de réinitialiser la longueur et crc et commencer avec le décodage de la nouvelle image. S'il s'agit d'une correspondance, copiez le paquet dans un nouveau tampon et transmettez-le à votre fonction de traitement des commandes. Toujours réinitialiser la longueur et crc quand un drapeau est reçu.
Pour votre fonction de traitement des commandes, saisissez cmd et len, puis utilisez un commutateur pour gérer chaque type de commande. J'exige également que certains événements envoient une réponse afin que le système se comporte comme un appel de procédure à distance qui est piloté par un événement. Par exemple, le dispositif de détection peut avoir une minuterie ou répondre à une commande pour effectuer une lecture. Il formaterait alors un paquet et l'enverrait au PC et le PC répondrait qu'il a reçu le paquet. Si ce n'est pas le cas, le dispositif de détection peut renvoyer un délai d'expiration.
De même, lorsque vous effectuez un transfert réseau, vous devez le concevoir comme une pile réseau comme OSI modle. Le HDLC est le data link layer et le RPC and command handling is the Application Layer.
Dans la mesure du possible, laissez un humain à une extrémité du câble déterminer ce qui se trouve à l'autre extrémité du câble. Idéalement, un humain pourrait brancher un terminal muet et frapper le clavier trois fois (Entrer le point d'interrogation Enter), puis un message long et détaillé reviendrait pour décrire le type de machine, son numéro de modèle, le nom et le numéro de téléphone et le site web de l'organisation qui l'a construit, le numéro de version du protocole « officiel », et le temps de construction non officielle:
__DATE__ ": " __TIME__
envoyer également le même message détaillé à chaque fois que la machine démarre vers le haut.
Dans la mesure du possible, essayez de concevoir votre protocole afin qu'un être humain doté d'un terminal bête puisse parler à votre appareil. Le HTTP est un tel protocole lisible par l'homme, et je soupçonne que c'est l'une des raisons de sa popularité. Human-lisibles implique, entre autres choses:
Vous pouvez également jeter un oeil à la liste des common protocols for embedded systems. Peut-être que vous répondez déjà à vos besoins? Y at-il une raison d'utiliser quelque chose de plus difficile à décoder que le standard Netstring format?
Je ne demande pas de conseil sur l'ensemble de la conception, je cherche simplement des conseils pour la rendre plus résistante. Peut-être une meilleure question est, "Quelles choses spécifiques devrais-je éviter de faire un protocole de communication compatible avant?" –