Calcul Crc 18 Bit En C

Calculez un CRC 18 bits configurable pour une chaîne ASCII ou une trame hexadécimale, visualisez le résultat immédiatement et récupérez les paramètres essentiels pour l’implémenter proprement en C embarqué, firmware, télécom ou protocole industriel.

Conseil: pour une trame hexadécimale, séparez les octets par des espaces, des virgules ou écrivez une suite continue comme 48656C6C6F.

Guide expert: comment réaliser un calcul CRC 18 bit en C de manière fiable

Le calcul CRC 18 bit en C intéresse surtout les développeurs embarqués, les ingénieurs protocoles et les équipes firmware qui doivent détecter les erreurs de transmission avec un coût de calcul raisonnable. Un CRC, ou Cyclic Redundancy Check, n’est pas un mécanisme de chiffrement: c’est une méthode mathématique de détection d’erreurs. Son rôle consiste à résumer une trame de données dans un registre binaire de taille fixe, ici 18 bits, afin qu’un récepteur puisse vérifier si les bits ont été altérés pendant le transport ou le stockage.

En pratique, beaucoup d’échecs d’implémentation viennent d’un détail: deux développeurs parlent de “CRC-18”, mais n’emploient pas le même polynôme, la même valeur initiale, ni les mêmes réglages RefIn, RefOut et XorOut. C’est précisément pour cela qu’un calculateur paramétrable est utile. Il permet de reproduire les paramètres d’une spécification technique, de comparer le résultat avec un équipement existant et de générer une base fiable avant d’écrire le code C final.

Pourquoi choisir un CRC de 18 bits ?

Un CRC de 18 bits offre un compromis intéressant entre la taille du champ de contrôle et la capacité de détection. Il est plus compact qu’un CRC-32 tout en offrant une probabilité d’erreur non détectée bien plus faible qu’un contrôle de parité ou qu’une somme simple. Dans des contextes où chaque bit compte, par exemple sur une trame radio, un bus série spécialisé ou un protocole à bande passante contrainte, 18 bits peuvent représenter un excellent équilibre.

D’un point de vue probabiliste, pour des erreurs aléatoires indépendantes, un CRC de largeur n laisse passer une erreur avec une probabilité théorique proche de 1 sur 2ⁿ. Pour 18 bits, cela correspond à 1 sur 262 144, soit environ 0,000381%. Ce chiffre ne raconte pas toute l’histoire, car la qualité réelle dépend aussi du polynôme choisi, mais il donne une base utile pour comparer différentes largeurs.

Type de contrôle	Largeur	Probabilité théorique d’erreur aléatoire non détectée	Équivalent en pourcentage
Bit de parité	1 bit	1 / 2	50%
Checksum simple	8 bits	1 / 256	0,390625%
CRC-16	16 bits	1 / 65 536	0,001526%
CRC-18	18 bits	1 / 262 144	0,000381%
CRC-32	32 bits	1 / 4 294 967 296	0,0000000233%

Les paramètres qui changent tout

Quand on parle de calcul CRC 18 bit en C, le mot “CRC-18” ne suffit pas. Une définition complète comprend au minimum:

• Width: ici 18 bits.
• Polynomial: le polynôme générateur, par exemple 0x10289 selon la variante visée.
• Init: le contenu initial du registre CRC.
• RefIn: indique si chaque octet entrant doit être réfléchi bit à bit.
• RefOut: indique si le CRC final doit être réfléchi.
• XorOut: valeur appliquée au CRC final avant restitution.

Si un seul de ces paramètres diffère, le résultat change. C’est la cause numéro un des incohérences entre une implémentation C et la documentation d’un protocole. La bonne méthode consiste à valider d’abord le calcul avec une entrée simple, puis à reproduire fidèlement les mêmes paramètres dans le code C, les tests unitaires et éventuellement dans l’outil de production ou de diagnostic.

Comment fonctionne le calcul, sans simplifier à l’excès

Le CRC se comporte comme une division polynomiale sur le corps binaire. Les données sont interprétées comme un polynôme à coefficients binaires, puis divisées par un polynôme générateur. Le reste de cette division est le CRC. En implémentation logicielle, on ne fait pas une division au sens arithmétique habituel: on manipule un registre, des décalages et des opérations XOR.

1. On initialise un registre de 18 bits.
2. On injecte les octets un à un, éventuellement avec réflexion des bits.
3. À chaque bit traité, on décale le registre.
4. Si le bit sortant indique une condition active, on applique un XOR avec le polynôme.
5. À la fin, on applique éventuellement RefOut puis XorOut.
6. On masque toujours le résultat final sur 18 bits.

Ce procédé paraît simple, mais les erreurs de décalage sont fréquentes. Avec un CRC 18 bits, le registre ne rentre pas proprement dans 16 bits. La pratique la plus sûre consiste à employer un type non signé d’au moins 32 bits, à masquer systématiquement avec 0x3FFFF et à surveiller la position du bit de poids fort, ici 1 << 17.

Exemple concret d’implémentation en C

Voici une base pédagogique pour un CRC 18 bits non réfléchi. Elle n’est pas liée à une norme unique: elle illustre surtout la structure correcte d’un calcul bit à bit. Ensuite, vous adaptez le polynôme, l’initialisation et les options de réflexion à votre besoin.

#include <stdint.h>
#include <stddef.h>

uint32_t crc18_compute(const uint8_t *data, size_t len,
                       uint32_t poly, uint32_t init, uint32_t xorout) {
    uint32_t crc = init & 0x3FFFF;
    const uint32_t topbit = 1U << 17;

    for (size_t i = 0; i < len; i++) {
        crc ^= ((uint32_t)data[i] << 10);

        for (int bit = 0; bit < 8; bit++) {
            if (crc & topbit) {
                crc = (crc << 1) ^ poly;
            } else {
                crc = (crc << 1);
            }
            crc &= 0x3FFFF;
        }
    }

    crc ^= (xorout & 0x3FFFF);
    return crc & 0x3FFFF;
}

Dans cet exemple, le décalage << 10 permet d’aligner l’octet entrant avec un registre de 18 bits afin que le traitement bit à bit se fasse au bon endroit. Si vous utilisez une variante réfléchie, la logique de parcours des bits change. C’est exactement ce que le calculateur ci-dessus vous aide à vérifier avant de figer votre version C.

Bit à bit ou table lookup: quel choix en C ?

Il existe deux grandes familles d’implémentation:

• Bit à bit: facile à comprendre, faible empreinte mémoire, plus lente.
• Table lookup: beaucoup plus rapide, mais nécessite une table pré-calculée et un soin particulier pour la cohérence avec RefIn/RefOut.

Sur microcontrôleur modeste, la version bit à bit est très souvent suffisante pour des trames courtes. Sur un flux plus dense ou une charge CPU serrée, une table de 256 entrées devient préférable. Le point important n’est pas seulement la vitesse, mais la traçabilité du paramétrage. Une table mal générée donne rapidement l’illusion de fonctionner sur quelques vecteurs de test, puis échoue en production.

Méthode	Opérations par octet	Mémoire supplémentaire	Cas d’usage typique
CRC bit à bit	8 itérations de boucle par octet	Quasi nulle	Firmware simple, validation, tests de référence
CRC table 16 entrées	2 accès table par octet	Faible	Compromis mémoire / performance
CRC table 256 entrées	1 accès table par octet	Plus élevée	Débit élevé, protocole temps réel, passerelle logicielle

Garanties de détection: ce qu’un CRC-18 fait bien

Le CRC est particulièrement fort pour les erreurs en rafale. Une propriété classique est qu’un CRC de largeur r détecte toutes les erreurs en rafale de longueur inférieure ou égale à r, à condition de respecter le modèle CRC standard. Pour un CRC-18, cela signifie une détection garantie des rafales jusqu’à 18 bits. C’est une propriété très utile sur les liaisons réelles, où les erreurs ne sont pas toujours indépendantes bit par bit.

Au-delà de cette limite, la probabilité de non-détection dépend fortement du polynôme. C’est pourquoi le choix du polynôme ne doit jamais être arbitraire. Les travaux du professeur Philip Koopman de Carnegie Mellon University sont une référence incontournable pour comparer la qualité des polynômes CRC sur des longueurs de messages réalistes.

Sources d’autorité à consulter

Pour documenter vos choix et éviter les implémentations improvisées, vous pouvez consulter les ressources suivantes:

• Carnegie Mellon University (.edu): études de Philip Koopman sur les polynômes CRC
• NIST (.gov): ressources générales sur l’intégrité des données et l’ingénierie numérique
• NASA (.gov): documentation technique utile sur les communications, télémesures et fiabilité des données

Même si ces sources ne donnent pas toujours une “recette” prête à copier pour votre variante exacte de CRC-18, elles fournissent le contexte scientifique et technique nécessaire pour sélectionner un polynôme robuste et justifier votre implémentation auprès d’une équipe qualité ou d’un client industriel.

Pièges courants dans un calcul CRC 18 bit en C

• Utiliser un type signé: cela perturbe les décalages et la propagation des bits.
• Oublier le masque 18 bits: le registre déborde et le résultat devient faux.
• Confondre poly normal et poly réfléchi: le calcul semble plausible mais reste incompatible avec l’équipement cible.
• Injecter les octets au mauvais alignement: erreur fréquente quand la largeur n’est pas 8, 16 ou 32.
• Tester sur un seul message: un seul vecteur de test ne suffit jamais.
• Ne pas documenter Init et XorOut: l’équipe suivante ne pourra pas reproduire le résultat.

Méthode de validation recommandée

1. Choisissez une chaîne de test simple, par exemple “123456789” si la spécification fournit une valeur de contrôle de référence.
2. Vérifiez les paramètres exacts: width, poly, init, refin, refout, xorout.
3. Calculez le CRC avec l’outil ci-dessus.
4. Recopiez la même configuration dans votre code C.
5. Ajoutez des tests unitaires avec plusieurs trames, y compris des messages vides, des octets nuls et des motifs répétitifs.
6. Comparez ensuite avec les trames émises par le matériel réel.

Quand un CRC-18 est-il préférable à un CRC-16 ou à un CRC-32 ?

Si vous avez déjà une contrainte protocolaire forte, la réponse est simple: vous suivez la norme. En revanche, dans un nouveau design, le CRC-18 devient intéressant quand vous voulez une protection supérieure à 16 bits sans accepter le surcoût de 32 bits. Sur des paquets courts à moyens, il peut offrir un niveau de sécurité de détection très honorable tout en économisant de l’en-tête. En revanche, pour des systèmes critiques, des charges utiles volumineuses ou des environnements fortement bruités, le CRC-32 reste souvent le meilleur choix.

Ce que fait exactement le calculateur de cette page

Le calculateur lit vos données en mode ASCII ou hexadécimal, applique un algorithme CRC générique 18 bits, puis affiche:

• la valeur finale au format hexadécimal ou binaire,
• le nombre d’octets réellement traités,
• les paramètres utilisés,
• un graphique visuel des octets et du CRC final.

Ce dernier point est particulièrement utile en phase de débogage. Si le résultat attendu ne correspond pas, vous pouvez rapidement confirmer si le problème vient de l’interprétation des données, du mode ASCII/HEX, ou du réglage des options RefIn et RefOut.

Conclusion

Réaliser un calcul CRC 18 bit en C n’est pas difficile d’un point de vue algorithmique, mais demande une rigueur absolue sur les paramètres et les détails d’implémentation. Le meilleur réflexe consiste à commencer par un calculateur paramétrable, à fixer des vecteurs de test, puis à écrire une fonction C propre avec masquage constant sur 18 bits. Si vous suivez cette approche, vous éviterez la majorité des écarts rencontrés entre documentation, firmware et terrain.

Cet outil a une vocation technique et pédagogique. Pour un usage de production, validez toujours votre variante CRC-18 contre la spécification exacte du protocole, des vecteurs de tests de référence et, si possible, un équipement réel.