Discussion :

[Caxton]

Bonjour,

Je suis tout nouveau dans le monde des Arduino et j'ai un projet lourd dans lequel je patauge amèrement.

Je dois établir une connexion série type TTL entre deux cartes Arduino. Quelques tests sur base d'ascii m'a permis de validé le fait que ça fonctionnais.

Depuis, le projet à pris un peu plus d'ampleur et je suis obliger de passer par des Octets du type 0x00 à 0xFF. Rien de bien méchant.

C'est à ce niveau là que je bloque. J'ai entendu parlé mais j'ai pas trouver de documentations probante. J'ai peut-être pas les bons mots clefs aussi. Je recherche le fonctionnement du CR16 qui sert en checksum et qui sert en fin de transmission.

Retenez que chaque trame est composé, dans le protocole que j'utilise de 3 à 5 octets suivi d'un octet de type CR16.

Mes questions sont donc:
- Quelle doc en français même condensé pour comprendre le CR16 ?
- Comme s'implémente le CR16 dans une liaison série ?
- Doit-on envoyer chaque octet avec un séparateur ?
- Est-ce qu'il existe une liaison série fiable pour Arduino déjà codé sous format de lib à importe ?

Je ne peux hélas que vous demander un peu de patience et de compréhension, moi qui débute dans ce petit monde de l'embarqué.

Merci pour vos réponses, en espérant que ce ne soit pas histoire de devoir réinventer la roue. Restons simple concis et efficace.

Cordialement

[sevyc64]

Retenez que chaque trame est composé, dans le protocole que j'utilise de 3 à 5 octets suivi d'un octet de type CR16.

Faux.
CRC pour Cyclic Redundancy Check (Contrôle de redondance cyclique) est le reste de la division modulo 2 des données binaires à contrôler par le polynôme de calcul. Pour le CRC16, le reste sera obligatoirement de 16 bits donc 2 octets de CRC

- Quelle doc en français même condensé pour comprendre le CR16 ?

La page wikipédia en français, mais la page anglosaxone est quand même bien plus complète

- Comme s'implémente le CR16 dans une liaison série ?

Il ne s'implémente pas sur la liaison elle-même, mais se calcule en amont sur les données à transmettre (la totalité des données binaires en un seul mot et non pas octet par octet). Le résultat s'intègre à la fin de trame et devient banalement 2 octets supplémentaires à transmettre.

- Doit-on envoyer chaque octet avec un séparateur ?

Faut voir avec ton protocole de dialogue. Généralement, dans les protocoles de dialogues, les trames contiennent au départ au moins, un identifiant de début de trame, une information de longueur, les données, le crc, éventuellement un identifiant de fin. Dans ce cas il n'y a pas besoin de séparateur, la longueur des données est connue, donc les 2 octets qui suivent (dans le cas simpliste que j'indique) sont donc forcément le crc.

- Est-ce qu'il existe une liaison série fiable pour Arduino déjà codé sous format de lib à importe ?

Joker, je connais pas Arduino.

Concernant les CRC, notamment le CRC16, tu peux prendre le polynôme que tu veux mais certains sont normalisés (voir tableau à la fin de la page wikipédia anglo-saxonne). Dans le cas présent, le polynôme doit t'être indiqué dans la doc de ton protocole de dialogue.

Dans le cas de l'exemple de la page wikipédia anglo-saxonne (Computation of CRC), le CRC pris est un CRC3 (ordre 3 donc 4 bits).
Le polynome est x³+x+1, donc 1*x³+0*x²+1*x+1 ou sous forme binaire 1011

Pour calculer, il faut prendre la totalité des données binaires en un seul mot, rajouter autant de 0 de poids faible que la puissance la plus élevée du CRC (ici 3).
Ensuite on applique la division modulo 2 de la donnée avec le polynôme, on ignore le quotient, on ne garde que le reste (revient aussi à répéter une addition bit à bit sans retenue, en partant du poids fort jusqu'à obtenir un résultat inférieur en nombre de bit au polynôme).

Et j'avais pas vu, la page wikipédia en français contient un lien vers ce tuto de :dvp:

[sevyc64]

- Est-ce qu'il existe une liaison série fiable pour Arduino déjà codé sous format de lib à importe ?

Pour le calcul du crc16 sur Arduino, j'ai trouvé ça :
http://www.arduino.cc/cgi-bin/yabb2/...1246539386/all

http://code.google.com/p/arduino-rov...24e833e076c8b6
http://code.google.com/p/arduino/sou...rduino/crc16.c

Le premier lien est à étudier, j'ai pas pris le temps de tout lire.
Les 2 autres liens, je te les mets aussi même si je trouve le code un peu bizarre. Je ne suis pas certain que ce ne soit pas des cas particuliers.

[Caxton]

Ah wai !

Ok, je n'étais pas du tout parti là dessus. Effectivement, ce que je voulais faire n'est pas du CRC16 maus du CRC

Effectivement, je ne suis pas tomber sur ces sources et du coup j'ai longuement patauger.

Je pense faire ceci : Data 1 + Data2 / Lenght sur 1 octets max. L'opération inverse est possible car ces éléments là sont transmis.

Par contre est-ce que ça fonctionnera pour 4, 5 data ? Il faudra que j'essaie sur un tableau

Merci Sevy, problème résolu

[sevyc64]

Non, un CRC est un CRC, c'est quelque chose de bien défini.

Tu veux certainement parler plutôt de checksum, dont il existe différent types (le CRC en est un). Il en existe des quantités.

Si on est large d'esprit, le bit de parité en est un, mais pas très efficace car il ne détecte que des erreurs de bits en nombre impair.
Tu as aussi les sommes modulaire, qui consiste à faire la somme des mots de tes données et à en prendre le complément à 2. L'avantage c'est qu'il se calcule très vite à la réception, puisqu'il suffit de faire la somme des mots y compris le checksum reçu, le résultat devant être égal à 0. Là aussi, si les erreurs sur un bit sont bien détectées, les erreurs sur 2 bits et plus ne le sont pas forcément toutes.
Tu as aussi, le Ou exclusif avec chaque mot, la aussi toutes les erreurs ne sont pas forcément détectées.

Le plus complet étant sans doute le CRC avant de mettre en place des solutions plus complexes comme les hashs style MD5, SHA, etc

Ce que tu veux faire toi est en fait une moyenne (somme des mots/nombre des mots). Attention à la résolution, la partie décimale est tronquée. Si le cumul des erreurs est inférieur en valeur au nombre de mots, les erreurs ne seront pas vues car tronquées dans la partie décimale.

La page wikidédia anglosaxone sur les checksum, elle est très succincte
La page française donne une autre approche

[Caxton]

Oui, c'est ce que je me suis rendu compte

Bon, je propose donc de me servir de ce post pour comprendre la démarche et en faire un algorythme

Donc, si je comprends bien, je prends mes data, je les additionnent, puis je procède à un décalage vers la gauche.

Trame à envoyer : 0x00 0x13 0x02 0x05 0x03 0x20

0x00 = start
0x13 = Sortie en PWM pour faire fonctionné un servo
0x02 = 2 datas
0x05 = data1 = servo N° 5
0x03 = data2 = position ° de 0 à 180. Cela rentre dans les 0 à 255 d'un octet.
0x20 = CRC

CRC en emission:
0x05 + 0x03 = 0x08
0x08 = 00001000 en binaire, décaler vers la gauche 000100000 donc 0x20

CRC en réception:
Data1 + Data2 = Somme
Somme décalé vers la gauche = CRC
CRC = CRC trame


Chez pas si c'est clair

[Caxton]

Suite aux remarques de Sevy sur le t'chat, je met à jour ma doc.
Suite à des indications sur un autre forum, je change mon start bit.

Le checksum sera composé de Type, Lenght, Data 1, Data 2...Data X / 256.

Exemple pour une trame modifier de celle d'au dessus.

Trame à envoyer : 0x0F 0x13 0x02 0x05 0x5A 0xE8

0x0F = start
0x13 = Sortie en PWM pour faire fonctionné un servo
0x02 = 2 datas
0x05 = data1 = servo N° 5
0x5A = data2 = position ° de 0 à 180. Cela rentre dans les 0 à 255 d'un octet. Ici, c'est 90°.
0xE8 = CRC

CRC en emission:
0x13 + 0x02 + 0x05 + 0x5A = 0x74
0x74 / 255 = 0
0x00 = 00000000 en binaire, décaler vers la gauche 00000000 donc 0x00

CRC en réception:
Type + Lenght + Data1 + Data2 = Somme
Somme décalé vers la gauche = CRC
CRC = CRC trame

En théorie, si une erreur survient, la comparaison devient mauvaise et une erreur est levée.

Edit:
Il me semble que je fais une erreur sur ma division. Il devrait y avoir un code permettant de récupérer le reste de la division. Mais lequel, je ne sait pas encore.

Quelqu'un à une idée ?

[sevyc64]

Comme indiqué sur le chat, la somme est à faire en 16bits, pour éviter le dépassement de capacité.

La division à faire est le modulo (récupération du reste de la division euclidienne) et c'est par 256 qu'il faut diviser pour ne garder que la partie "8bits" du résultat de la somme. Le décalage pourra être fait avant la division.

Trame à envoyer : 0x0F 0x13 0x02 0x05 0x5A 0xXX
CRC en émission:
0x0013 + 0x0002 + 0x0005 + 0x005A = 0x0074
0x0074 LSH 1 = 0x00E8
0x00E8 MOD 0x0100 = 0xE8

Trame envoyée : 0x0F 0x13 0x02 0x05 0x5A 0xE8

[Caxton]

Ah wai d'accord !

Bon, et bien j'ai plus qu'à trouvé comment ca se réalise niveau code

J'ai peur de ne pas y arrivé facilement et ici on connais peu le petit monde Arduino

Bon, ce n'est pas grave, je vais donc y allé pas à pas.