Introduction au protocole SNAP

Introduction

S.N.A.P. est un protocole de communication entre plusieurs hôtes connectés. Il permet :

- adressage

- drapeaux

· ack/nak request

- détection des erreurs (différentes méthodes de détection des erreurs disponibles)

Il peut être exécuté sur différents supports, y compris RS485. Il est optimisé pour une petite empreinte (ressources limitées en matière de calcul et de mémoire), mais il peut être adapté en fonction de vos besoins.

En gros, si vous voulez connecter plusieurs systèmes de calcul et les applications qui tournent dessus, par exemple un Raspberry Pi et plusieurs microcontrôleurs Atmel via leurs UART respectifs, en utilisant RS485 comme média, vous voulez quelque chose pour envelopper vos données, les délivrer aux hôtes corrects, recevoir des accusés de réception indiquant que les données ont été reçues correctement, etc. C'est à cela que sert SNAP. Il s'agit en quelque sorte d'une alternative au protocole Modbus, par exemple.

SNAP a été développé par HTH, High Tech Horizon, une société suédoise.

La page d'accueil du protocole est la suivante : http://www.hth.com/snap/.

Pour pouvoir communiquer à l'aide du protocole, vous devez obtenir un identifiant de fournisseur, que vous pouvez demander gratuitement à HTH. Ils vous demandent d'inclure un PDF du protocole SNAP, ou un lien vers leur site web http://www.hth.com/snap/ avec les applications/produits. L'identifiant du fournisseur n'est PAS inclus dans les octets du protocole que vous mentionnez dans votre demande. Vous pouvez donc commencer par évaluer le protocole, puis utiliser l'évaluation comme mise en œuvre réelle, sans aucune modification.

Voici la liste des identifiants des fournisseurs actuellement enregistrés :

http://www.hth.com/snap/vidlist.html

Voici un lien direct vers la fiche technique :

http://www.hth.com/filelibrary/pdffiles/snap.pdf

Quelques propriétés de base du SNAP

- protocole binaire

- un ensemble de fonctionnalités évolutives, en fonction de votre application

- fonctionne avec une communication synchrone et asynchrone (= par exemple UART)

- gratuit pour un usage commercial et privé. Nécessite un identifiant de fournisseur gratuit pour les identifiants commerciaux.

La communication entre les nœuds se fait sous forme de paquets. Voyons un exemple de paquet, qui utilise certaines des caractéristiques de SNAP :

source : Documentation SNAP, exemple d'un paquet SNAP simple

préambule : Le préambule est facultatif, il peut utiliser n'importe quels caractères tant qu'ils ne sont pas l'octet de synchronisation, SYNC.

- SYNC : octet unique avec la structure suivante : 01010100, indique le début du paquet.

- HDB2, HDB1 : Les octets de définition de l'en-tête HDB2 et HDB1 définissent la longueur du paquet et les caractéristiques qui seront utilisées.

- DAB1 : Octet d'adresse de destination

- SAB1 : Octet d'adresse source

- DB1 : Data Byte 1 - la charge utile pour votre application

- CRC2 : octet de poids fort du CRC-16

- CRC1 : octet de poids faible du CRC-16

adresse 0 est réservé comme une adresse de diffusion et ne doit pas être utilisé pour autre chose. (DAB / SAB)

note : les appareils arrivant au milieu des communications peuvent se synchroniser sur un 01010100 "normal" dans la mauvaise position (où il n'était pas destiné à être SYNC). Par conséquent, une somme de contrôle doit être utilisée, afin que le périphérique puisse reconnaître que les données "ne correspondent pas" et qu'il continue à écouter le prochain paquet commençant par le 01010100. (Ceci est nécessaire pour se protéger contre les décalages de trame). Il est évident que le périphérique rejettera tous les octets avant de recevoir le premier 01010100, car il n'a pas reçu le paquet complet.

octets de définition d'en-tête

SNAP est construit de manière modulaire et extensible. Vous pouvez définir (DD) des adresses de destination avec une longueur de 0 à 3 octets dans le DAB, octets d'adresse de destination. Avec une adresse de destination de 3 octets (DD = 11), vous obtiendrez jusqu'à 16 777 215 nœuds adressables. Avec une adresse de destination de 1 octet (DD = 01), utilisée dans l'exemple ci-dessus, vous pourrez adresser 255 adresses.

Il en va de même pour la longueur de l'adresse source (SS) dans les octets de l'adresse source (SAB). Dans l'exemple, SS = 01 pour les adresses de 1 octet.

PFB : longueur d'octet spécifique au protocole. 0 - 3 octets, comme ci-dessus (PP). Dans l'exemple, PP = 00. Cette fonctionnalité n'est pas encore implémentée dans SNAP, et donc elle devrait être définie comme 0, comme dans l'exemple. Une implémentation spécialisée de SNAP pourrait probablement faire quelque chose avec eux (par exemple un compteur de paquets, etc) - voir la documentation SNAP pour quelques idées.

ACK : c'est une zone importante de la définition de l'en-tête. Elle indique si le nœud émetteur demande un paquet ACK / NAK en retour, et agit également comme la réponse ACK / NAK réelle du nœud récepteur :

- 0 0 = Pas de demande d'acquittement (Tx)

- 0 1 = Demande d'acquittement (Tx)

- 1 0 = Réponse Ack (Rx)

- 1 1 = réponse NAK (Rx)

CMD - bit de mode de commande. Mettez-le à zéro, c'est une fonction avancée de SNAP que vous n'utiliserez probablement pas dans votre application.

EDM : méthode de détection des erreurs. Ces trois bits vous permettent de définir la méthode de détection des erreurs que vous souhaitez utiliser. Lisez la documentation SNAP pour plus de détails. Dans l'exemple, il a été défini comme 1 0 0 = CRC 16 bits, ajoutant deux octets de somme de contrôle (CRC2, CRC1) à la fin du paquet.

NDB : quatre bits pour déterminer combien d'octets de données il y a dans le paquet.
1 octet, comme dans notre exemple (un octet de données : DB1) est défini par 0 0 0 1

ACK / NAK

Si vous définissez l'ACK à 00 dans l'octet de définition d'en-tête 2 (HDB2), le nœud émetteur n'attendra pas de paquet ACK ou NAK en retour.

Si vous envoyez un ACK / NAK du nœud récepteur, dans l'exemple de la page 23, l'octet de données est présent avec la même longueur (1 octet de données) que dans la demande originale de l'expéditeur, et rempli de 0es.

L'idée derrière ACK / NAK est que le nœud émetteur peut, après un délai, prendre les mesures appropriées.

L'octet de données POURRAIT être utilisé pour des informations supplémentaires sur le problème si un NAK est envoyé, mais cela ne fait pas partie de la spécification SNAP.

Les choses auxquelles vous devez penser

- comment les noeuds détermineront-ils leur adresse ?

Pour le maître, c'est facile : il recevra une adresse définie. Les esclaves doivent recevoir des adresses d'une manière prévisible, de façon à ce qu'elles soient répétables. L'idéal est de les lier à certaines caractéristiques matérielles.

- structure des paquets

Utiliserez-vous toujours la même quantité d'octets de données ? Cela permettra un timing plus déterministe, une mise en œuvre plus facile, etc.

- détection des erreurs

Quel algorithme de détection des erreurs doit-on choisir ?

Veuillez noter que l'octet SYNC n'est pas inclus dans le calcul du checksoum.

Le CRC est capable de reconnaître les erreurs et, idéalement, de les corriger (pour une quantité moindre d'erreurs).

La page 14 de la spécification du protocole donne un aperçu des valeurs de contrôle GED précalculées pour tester votre propre mise en œuvre de somme de contrôle pour les chaînes "SNAP" et "snap".

- longueur totale des paquets

HTH recommande de conserver des paquets de petite taille (< 40 octets) sur des supports tels que les lignes électriques, la RF ou l'IR pour améliorer les performances.

- drapeaux spécifiques au protocole (PFB)

Ceux-ci pourraient être utilisés dans une mise en œuvre spécialisée de votre protocole, vous permettant de déplacer une certaine logique d'application à l'intérieur de celui-ci, et d'utiliser les données comme des données réelles. (par exemple, les bits PFB pourraient définir la commande que vous voulez que le nœud exécute, et les données pourraient être la charge utile requise pour les commandes individuelles). ou vous pourriez emballer commande + données complètement dans les données, et juste utiliser SNAP pour le transport, l'adressage et la garantie que le paquet arrive sans erreurs.

Mise en œuvre de Python

Une implémentation Python de SNAP est disponible. Notez que c'est pour Python 2.

http://www.hth.com/snap/

Voici une documentation pour ce module :

http://diyhpl.us/reprap/trunk/users/stef/pyRepRap/docs/reprap.snap.html

http://diyhpl.us/reprap/trunk/users/stef/pyRepRap/reprap/snap.py

Voici un exemple de fichier d'utilisation :

http://diyhpl.us/reprap/trunk/users/stef/pyRepRap/examples/demo.py

Il est probablement plus pratique de télécharger le code ici :

https://github.com/CarlosGS/Cyclone-PCB-Factory/tree/master/Software/PythonScripts/Replath/pyRepRap

Cette implémentation Python met en œuvre un sous-ensemble de SNAP pour une certaine application, mais c'est un bon point de départ pour votre propre implémentation.

Outils de débogage et bibliothèque

http://www.hth.com/snap/snaplab.html

http://www.hth.com/snap/snaptest.html

Il s'agit d'une application de test générique qui est écrite en DELPHI et qui utilise le port COM pour communiquer. Snaplab peut espionner le trafic réseau SNAP, et générer des paquets SNAP avec des données aléatoires.

Il existe une bibliothèque C pour le protocole SNAP :

http://www.hth.com/snap/libdl.html

Il ne met pas en œuvre l'ensemble des fonctionnalités de SNAP.

Voici une implémentation en C++ :

https://github.com/alx/reprap-arduino-firmware/blob/master/library/SNAP/SNAP.cpp