Discussion :

[VincM]

Bonjour,

j'ai un code qui permet d'envoyer et recevoir des données entre l'ordinateur et une carte électronique. Il faut que j'y ajoute un CRC. J'ai donc parcouru ce tutoriel et fouillé un peu sur le net pour éclaircir au mieux les choses.... Mais c'est pas très clair dans ma petite tête....

Le principe, je pense l'avoir saisi. On divise la trame par un polynôme fixé et le reste de la division nous donne le CRC (le quotient, je le jette?).

Pour ne pas me prendre la tête, je me suis dit que j'allais utiliser le CRC16 CCITT vu qu'il a l'air d'être pas mal utilisé et que 16 bits sont largement suffisant dans mon cas.
Le polynôme est donc: x^16 + x^12 + x^5 + 1
Et en hexa, ça donnerait (toujours d'après le tuto): 0x1021
-> Je n'arrive pas à passer d'une valeur à l'autre...
J'ai passé 1021 en binaire et je pensais qu'il suffisait de tenir compte du poids des bits... Au mieux, je trouve x^12 + x^5 + 1

J'ai l'impression de rater un truc évident, surtout que je suis sûr d'avoir déjà fait ce genre de chose!

Avant de me lancer dans le code, je tiens à bien comprendre le fonctionnement. Je n'ai pas envie de copier/coller et bidouiller des lignes pour l'adapter à mon programme.

Si quelqu'un peut m'expliquer à sa manière le fonctionnement du CRC, je suis tout ouïe!!

(et toutes mes excuses si je ne poste pas dans le bon forum, je ne savais pas où poster mais vu que je code en C++....)

[ram-0000]

Le CRC est le reste de la division d'un nombre (numérateur) par un autre nombre (dénominateur).

Ce dénominateur doit avoir quelques propriété mathématiques pour en faire un CRC et le CRC16 CCITT (on parle aussi de polynôme générateur) possède ces caractéristiques (sur un domaine d'application particulier).

Si tu as une trame (mettons 100 octets) et que tu concatène le CRC à cette trames (2 octets CRC16 CCITT), tu obtiens une trame de 102 octets.

Maintenant, si tu recalcules le CRC de cette trame de 102 octets, tu obtiens 0 (ou une autre valeur connue et fixe). C'est ainsi que l'on détecte les erreurs avec le CRC. Si le CRC de la trame n'est pas 0 (ou autre valeur connue et fixe), alors il y a une erreur de transmission.

De plus, si tu es dans le domaine d'application du CRC, tu peux retrouver le bit en erreur et le corriger ou alors, tu sais qu'il y a trop de bits en erreur et tu sais que tu ne peux les corriger.

Si tu sors du domaine d'application du CRC, tu ne peux pas corriger (mais tu peux détecter). De même, si tu sors vraiment trop du domaine d'application, tu peux avoir une erreur non détectée par le CRC (effet similaire à la preuve par 9 de la multiplication).

Pour info, le bit de parité est aussi un CRC dont le polynôme générateur est x+1

[VincM]

Merci pour les infos et une réponse aussi rapide!
Jusque là, ça va. Avant d'émettre le signal, je calcule le CRC que j'ajoute en fin de trame. Pour la réception, si je t'ai bien suivi, je calcule le CRC de la trame+CRC et ça doit me donner 0.
J'étais parti dans l'idée de calculer le CRC de la trame et de le comparer à celui reçu pour vérifier l'erreur. Je préfère ta solution, ça évite de couper la chaîne transmise, isoler le CRC calculé avant l'envoi et le comparer. Ca va déjà simplifier mon code

L'autre soucis, c'est le passage polynôme <-> hexa:
Pour le CCITT, on donne 0x1021 mais lorsque je cherche à le calculer, je trouve 0x11021 à chaque fois

[ram-0000]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
x^16 + x^12 + x^5 + x^0
==> 1 0001 0000 0010 0001
==> 0x11021

Effectivement, tu as raison mais je pense qu'il faut enlever le 1er digit car c'est plus grand que 16 bits et donc on obtiens 0x1021 (ou alors une autre raison dans le genre CRC16(x^16 + x^12 + x^5 + x^0) = 0x1021)

Autre chose, pour calculer le CRC d'une trame, il faut d'abord lui ajouter les bits du CRC initialisés à 0.

Donc dans mon exemple avec une trame de 100 octets

1. 100 octets
2. 100 octets + 2 octets à 0
3. calcul CRC sur 102 octets
4. remplacer les 2 octets à 0 par la valeur calculée du CRC

[VincM]

Je suis rassuré, j'avais peur de ne plus savoir compter

Merci pour tes explications, j'y vois déjà plus clair

Plus qu'à aller ajouter le CRC au programme maintenant!

[VincM]

Petite question supplémentaire:

mon projet comporte une application Windows, un driver USB et un périphérique USB (une carte électronique, avec un programme dessus).

J'avais pensé mettre le CRC dans le driver mais est-ce le plus judicieux? Le driver servant en quelque sorte seulement d'interprète, est-ce qu'une norme par exemple voudrait que je mette le contrôle du CRC dans l'appli et dans le programme du microcontroleur de la carte à la place?

[ram-0000]

Que fera l'appli si elle reçoit une trame avec un mauvais CRC ? Probablement qu'elle l'ignorera.

Autant faire alors le calcul au niveau du driver et ne pas embêter l'appli si le CRC est mauvais, c'est le driver qui jette la trame.

De plus, si tu refais une autre appli qui utilise le même driver, tu n'auras pas à t'embêter avec le CRC, tu sais déjà que ce qui est remonté par le driver est correct (enfin, le plus correct possible).

Si je fais une analogie avec les couches réseau, une trame avec un mauvais CRC n'est pas remonté par la pile, il est ignoré par la carte réseau. Une trame IP avec un mauvais checksum IP n'est pas remonté par la pile IP à la couche TCP, elle est jetée.

[EDIT] et puis si tu change d'algorithme, cela ne concernera que le driver, rien à refaire au niveau de l'appli.

[VincM]

Merci de m'avoir enlever ce doute

C'est vrai que c'est beaucoup plus logique de le traiter dans le driver...