[CRC] Pb dans la chaine a transmettre

"Thierry Abrard" a écrit:

- Mais pour piloter mon automate Jbus... je dois envoyer des trames
du type : 01/06/00/0C/00/C7... et bien sûr en HEXA !!! Le problème
c'est que quand j'envoi dans ma fonction de calcul la chaine
correspondante
: "x01x06x00x0Cx00xC7"... Y a un pb au niveau du caractère Nul
0x00. Ma chaine de caractère s'arrete là et le calcul de CRC n'est
pas fait en totalité...

...

CRC = TrameTx ("x01x06x00x0C...",0xFFFF);
-> PB !!!, CRC arreté à x01x06

Termine tes chaines par un NULL byte comme ceci:

CRC = TrameTx ("Hello world...x00",0xFFFF);
CRC = TrameTx ("Hello again !x00",CRC);
CRC = TrameTx ("x01x06x00x0C...x00",0xFFFF);

Cela permet que les chaines soient terminer par un double Null Byte.

Il te reste plus qu'à analyser/traiter tes chaines avec le double-Null
byte comme fin de chaine.


unsigned int CalculCRC16 ( char * pt_Buf, unsigned int CRC)
{

... le calcul...

do
{
...

pt_buf++;

/* un Double Null byte permet de sortir de cette boucle */
} while( *pt_buf || *(pt_buf+1) );

...
return (CRC);
}

Dans le code, il est considéré que la chaine transmise n'est jamais
vide. Sinon il faut le vérifier avant le do/while.


Les fonctions strlen, strcpy, str* s'arreteront au premier Null Byte,
donc à ne pas utiliser...


Code à vérifier comme il se doit...

A
+
Jean-Marc

On 8 Jul 2003 21:18:02 -0700, thierryabrard@wanadoo.fr (Thierry
Abrard) wrote:

Bonjour,

Je doit utiliser le calcul d'un CRC16 pour transmettre un fichier
ASCII et aussi pour envoyer des infos à un automate par protocole
JBus... L'algorithme du CRC fonctionne très bien... vérifié sur
plusieurs langages et avec plusieurs algos...

- Pour ce qui est du fichier ASCII, y a pas de soucis, la chaine de
caractère dont on calcul le CRC reste des caractères imprimables...

- Mais pour piloter mon automate Jbus... je dois envoyer des trames du
type : 01/06/00/0C/00/C7... et bien sûr en HEXA !!! Le problème c'est
que quand j'envoi dans ma fonction de calcul la chaine correspondante
: "x01x06x00x0Cx00xC7"... Y a un pb au niveau du caractère Nul
0x00. Ma chaine de caractère s'arrete là et le calcul de CRC n'est pas
fait en totalité...

J'aimerais donc savoir qu'elle est la démarche à suivre pour envoyer
et calculer le CRC dans ce cas...

Merci...
TA.

______________________________________________
[RESONNEMENT DE MON PROGRAMME (!!!)]


[Fonction] TrameTx (char * Trame, unsigned int CRC_old)
{
unsigned int CRC_new;

printf ("%s",Trame);
CRC_new = CalculCRC16 ( Trame, CRC_old );
return (CRC_new);
}

[Fonction] CalculCRC16 ( char * Buf, unsigned int CRC)
{
... le calcul...
return (CRC);
}

puis j'utilise les fonctions comme ça :

CRC = TrameTx ("Hello world...",0xFFFF);
CRC = TrameTx ("Hello again !",CRC);
-> Le calcul (CRC final) est OK

CRC = TrameTx ("x01x06x00x0C...",0xFFFF);
-> PB !!!, CRC arreté à x01x06

C'est la faute de la fonction CalculCRC qui pense que la séquence des
caractères passée est terminée avant le premier . Quand on veut
inclure des dans la séquence on doit changer la CalculCRC.

D'abord il faut lui passer un paramètre additionnel qui donne la
longueur de la séquence et après il faut changer le code en boucle
controlé par ce nombre.

--
Horst

Thierry Abrard wrote:

: "x01x06x00x0Cx00xC7"... Y a un pb au niveau du caractère Nul
0x00. Ma chaine de caractère s'arrete là et le calcul de CRC n'est pas

Normal, c'est le signe de la fin de chaine!!!
Pour calculer un CRC, on envoi par la commande la chaine d'octets (et
non de caracteres), et la taille de la chaine.

Il existe de nombreuse fonctions deja toutes faites sur le net comme ca,
pourquoi ne pas avoir pris exemple sur eux?

In 'fr.comp.lang.c', thierryabrard@wanadoo.fr (Thierry Abrard) wrote:

Je doit utiliser le calcul d'un CRC16 pour transmettre un fichier
ASCII et aussi pour envoyer des infos à un automate par protocole
JBus... L'algorithme du CRC fonctionne très bien... vérifié sur
plusieurs langages et avec plusieurs algos...

- Pour ce qui est du fichier ASCII, y a pas de soucis, la chaine de
caractère dont on calcul le CRC reste des caractères imprimables...

- Mais pour piloter mon automate Jbus... je dois envoyer des trames du
type : 01/06/00/0C/00/C7... et bien sûr en HEXA !!! Le problème c'est

Pas en hexa, mais en binaire (l'hexa est une représentation 'humaine' du
binaire)

Si il y a des 0 dans les données, on ne peut pas utiliser les fonctions de
chaines. Il faut êtr 'transparent'. On doit donc utiliser autre chose de plus
basique comme le couple {adresse, longueur}. Quelques fonctions du C
utilisent ce genre d'interface :

fread(),
fwrite(),
memset(),
memcpy() etc.

--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Bonjour,

Je vous remercie pour toutes ces réponses, je vais tacher de récupérer
quelques idées, mais j'avais le problème suivant : Dans ma
configuration du programme actuel il m'est difficile de spécifier la
longueur de la Trame...

Il faudrait modifier la fonction :
TrameTx ("hello...", longueur(ici=8), CRC);
- avec printf("%s",trame);
- puis calculcrc16(trame,longueur,crc_old);
mais j'ai un max de lignes à envoyer, et de longueur assez
importantes... et je ne souhaite pas déterminer (à la main) pour tous
la longueur de ce que j'envoi. Je pourrais mettre avant en buffer la
trame par sprintf(buffer,"Hello..."); puis strlen(buffer) mais ça
m'allonge le code (je double les lignes de codes). Surtout que c'est
pour implanter sur mirco-C.

Ensuite, je peux faire la modif suivante :
TrameTx("hello...",crc);
- avec longueur = strlen(trame);
- puis printf("%s",trame);
- puis calculcrc16(trame,longueur,crc_old);
La longueur de la trame est ici calculée automatiquement, mais si je
doit envoyer TrameTx("x01x00x06",crc); la longueur calculée sera de
1 et je doit donc la spécifier cette longueur avant ma fonction (voir
cas plus haut)...

Je vais voir comment associer de façon moins compliquée mes
fonctions...
A+ et merci

Bon... apres quelques essais, finalement lorsque j'envoi :
TrameTx ("x01x06x00x02x03x04",6);

et que je regarde dans le calcul du crc chaque caractères traites (les
6, par printf("%#X",buf[i]); j'ai '0x01' (ok) puis '0x06' (ok) puis
'0x00' (ok) mais ensuite j'ai n'importe quoi pour les caractères
suivants !!!

- Lorsque j'envoi une chaine de caractère (char *) avec un x00 de fin
de chaine à l'interieur, s'arrete t'il de copier ma chaine à partir du
caractère null ?

Finalement, pour la trame Jbus, j'envoi caractère par caractères :
TrameTx("x01");
TrameTx("x06");
TrameTx("x00"); Dans ce cas là, le calcul du crc recupère une ligne
de longueur 0 (strlen(buf)) que je force à 1 pour la traiter quand
meme.
... et je continu et la valeur retournee est correcte.

CalculCRC(char * buf, crc_old)
{
nsize = strlen(buf);
if (nsize == 0) { nsize = 1; } // c'est pas joli-joli !!!
for (i=0;i<nsize;i++)
{
calcul... crc_new = f( crc_old );
}
return (crc_new);
}


A+

Thierry Abrard wrote:

- Lorsque j'envoi une chaine de caractère (char *) avec un x00 de fin
de chaine à l'interieur, s'arrete t'il de copier ma chaine à partir du
caractère null ?

Sans doute, meme si ca m'etonne
Pourquoi pas :
char A[6]=(0x01, 0x06, 0x00, 0x02, 0x03, 0x04)
TrameTx(A, 6);

D'une ca me parait plus lisible, et de deux plus "en regle"
tu joues avec des chaines de caractere (ayant une caracteristique
importante du 0x00) pour travailler avec des octets, c'est un jeu très
dangereux.

les guillements pour des chaines de caracteres uniquement, ce sera
source de bcp moins de pb...

On 9 Jul 2003 16:02:13 -0700, thierryabrard@wanadoo.fr (Thierry
Abrard) wrote:

Bon... apres quelques essais, finalement lorsque j'envoi :
TrameTx ("x01x06x00x02x03x04",6);

et que je regarde dans le calcul du crc chaque caractères traites (les
6, par printf("%#X",buf[i]); j'ai '0x01' (ok) puis '0x06' (ok) puis
'0x00' (ok) mais ensuite j'ai n'importe quoi pour les caractères
suivants !!!

- Lorsque j'envoi une chaine de caractère (char *) avec un x00 de fin
de chaine à l'interieur, s'arrete t'il de copier ma chaine à partir du
caractère null ?

Qui est "il" ?. Quand tu passes une chaine literale a une function
comme p.ex.

void bar(char*) {/**/}
void foo(char*p) { bar(p); }


foo("x01x00x01");

il n'y pas de copiage. Tu passes à la fonction foo un pointeur qui
pointe vers le début d'une séquence de caractères avec les valeurs

1 0 1 0

et quand 'foo' passe le paramètre p à une fonction 'bar', alors la
fonction 'bar' recoit le même pointeur qui pointe toujours vers

1 0 1 0

Personne ne copie si tu ne copies pas.

Que dit ce programme ?

#include <stdio.h>

void f(char*p, int n)
{
int i;
for (i=0;i<n;i++) printf("%dn",p[i]);
}

int main()
{
f("x01x00x01",3);
return 0;
}

--
Horst

In 'fr.comp.lang.c', thierryabrard@wanadoo.fr (Thierry Abrard) wrote:

Bon... apres quelques essais, finalement lorsque j'envoi :
TrameTx ("x01x06x00x02x03x04",6);

et que je regarde dans le calcul du crc chaque caractères traites (les
6, par printf("%#X",buf[i]); j'ai '0x01' (ok) puis '0x06' (ok) puis
'0x00' (ok) mais ensuite j'ai n'importe quoi pour les caractères
suivants !!!

Tu ne peux pas utiliser printf pour visualiser des données binaires. Le truc
courant est d'écrire un petit 'dumper' qui va mettre les bytes au format
00..FF. L'interface est, comme il se doit avec les données binaires, de type
adresse, longueur.

#include <stdio.h>

void xdmp (void *data, size_t len)
{
/* mise en page */
size_t const N = 16;

unsigned char *p = data;
size_t i = 0;

while (i < len)
{
if (i % N != 0)
{
putchar (' ');
}

printf ("%02X", (unsigned) p[i]);

i++;

if (i % N == 0)
{
putchar ('n');
}
}

if (i % N != 0)
{
putchar ('n');
}
}

- Lorsque j'envoi une chaine de caractère (char *) avec un x00 de fin
de chaine à l'interieur, s'arrete t'il de copier ma chaine à partir du
caractère null ?

Les fonctions traitant des chaines s'arrêtent au premier 0 rencontré. Ca
t'étonne? Ca ne devrait pas.

Finalement, pour la trame Jbus, j'envoi caractère par caractères :
TrameTx("x01");
TrameTx("x06");
TrameTx("x00"); Dans ce cas là, le calcul du crc recupère une ligne
de longueur 0 (strlen(buf)) que je force à 1 pour la traiter quand
meme.

Bidouille infâme qui te retombera desssus un jour ou l'autre.

... et je continu et la valeur retournee est correcte.

On t'a déjà dit qu'il fallait construire un tableau de unsigned char, mettre
dedans les 'n' bytes a emettre, et passer à la fonction d'emission adresse et
longueur. Qu'est qui est si difficile?

unsigned char buf[128];
size_t w = 0;
char *s = "hello world";
unsigned checksum = chk16 (s, strlen (s));

/* MSB */
buf[w] = (checksum >> 8) & 0xFF;
w++;
/* LSB */
buf[w] = checksum & 0xFF;
w++;

for (p = s; *p; p++)
{
buf[w] = *p;
w++;
}

xmit (buf, w);

0 0 0 0 0 0 0 0 0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2
CSH CSL 'h' 'e' 'l' 'l' 'o' ' ' 'w' 'o' 'r' 'l' 'd'

Ceci dit, il est assez curieux de mettre le checksum en tête. En général on
le met en fin. Ce qu'on met en tête, c'est plutôt la longueur de la trame...

<longueur><data><cs>

--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Bonjour,

Merci pour les infos,

OK donc pour ce qui est du pointeur, les fonctions transmettent
l'adresse de la chaine de caractère, mais cette chaine est inscrite en
mémoire... non ? Elle est donc présente quelque part et si j'écrit
x01x00x01x02x03 etc, je dois avoir cette séquence ENTIERE en
mémoire... Maintenant, si je 'force' à pointer plus loin dans la
chaine de caractère, je dois donc pouvoir lire mes caracteres au dela
du x00. (comme un tableau)

Que dit ce programme ?

#include <stdio.h>

void f(char*p, int n)
{
int i;
for (i=0;i<n;i++) printf("%dn",p[i]);
}

int main()
{
f("x01x00x01",3);
return 0;
}

Et en fait, apres le x00 je ne sais pas où il va placer les éléments
suivants, mais j'ai n'importe quoi...

Ca donne : 1 0 0
Avec f("x01x02x03x00x04x05x06",7);, j'ai : 1 2 3 0 0 7 0
(en mémoire @A3F j'ai bien la séquence 01 02 03 00 00 07 00 00 00...)
et il ne m'a (le compilateur) pas écrit la suite apres le x00 !

Tout cela me laisse perplexe... <8-p
Faut dire aussi que j'utilise un compilateur C pour programmer un
micro-controleur (80535), qui ne va pas bien loin... snif ! (ie
WEdit51)

A+