besoin d'un avis sur le calcul msb et lsb d'une trame

Version imprimable

Coucou à tous j'aurai besoin de votre avis sur une méthode de calcul

voici la situation:
dans un thread je lis mon port com.
Je récupère une trame.
Si la trame est correcte, les 2 derniers octets correspondent au msb et lsb de la trame.
En suite je mets à jour mes contrôles si la trame est correcte.

le problème est le suivant:
En mode debug(GO F5) sans mettre de point d'arrêt mon application fonction correctement.
Mais dans que je lance l'exécutable ça ne va plus... mes voyants restent au rouge( control). De plus l'application prend beaucoup de ressources de l'UC.
En cherchant, j'ai trouvé que c'était la fonction "calculerPoidBits" qui prenait au temps de ressources.

quelqu'un aurait -il une méthode moin lourde.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
 
static unsigned char aCRCmsb[] = {
      0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
      0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
      0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
      0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
      0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1,
      0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41,
      0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1,
      0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
      0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
      0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40,
      0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1,
      0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
      0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
      0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40,
      0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
      0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
      0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
      0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
      0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
      0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
      0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
      0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40,
      0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1,
      0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
      0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
      0x80, 0x41, 0x00, 0xC1, 0x81, 0x40 };
 
static unsigned char aCRClsb[] = {
      0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06,
      0x07, 0xC7, 0x05, 0xC5, 0xC4, 0x04, 0xCC, 0x0C, 0x0D, 0xCD,
      0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09,
      0x08, 0xC8, 0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A,
      0x1E, 0xDE, 0xDF, 0x1F, 0xDD, 0x1D, 0x1C, 0xDC, 0x14, 0xD4,
      0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3,
      0x11, 0xD1, 0xD0, 0x10, 0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3,
      0xF2, 0x32, 0x36, 0xF6, 0xF7, 0x37, 0xF5, 0x35, 0x34, 0xF4,
      0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A,
      0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38, 0x28, 0xE8, 0xE9, 0x29,
      0xEB, 0x2B, 0x2A, 0xEA, 0xEE, 0x2E, 0x2F, 0xEF, 0x2D, 0xED,
      0xEC, 0x2C, 0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26,
      0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0, 0xA0, 0x60,
      0x61, 0xA1, 0x63, 0xA3, 0xA2, 0x62, 0x66, 0xA6, 0xA7, 0x67,
      0xA5, 0x65, 0x64, 0xA4, 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F,
      0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68,
      0x78, 0xB8, 0xB9, 0x79, 0xBB, 0x7B, 0x7A, 0xBA, 0xBE, 0x7E,
      0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C, 0xB4, 0x74, 0x75, 0xB5,
      0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71,
      0x70, 0xB0, 0x50, 0x90, 0x91, 0x51, 0x93, 0x53, 0x52, 0x92,
      0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54, 0x9C, 0x5C,
      0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B,
      0x99, 0x59, 0x58, 0x98, 0x88, 0x48, 0x49, 0x89, 0x4B, 0x8B,
      0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C,
      0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42,
      0x43, 0x83, 0x41, 0x81, 0x80, 0x40 };
 
 
//calculer les bits de poids fort et de poids faible
//"trame" est l'attribut sur le quel on travail, "nombreOctet" correspond est lier à la taille de la trame
//retourne "true" si l'opération c'est correctement passé
bool CCom::calculerPoidBits(int nombreOctet, unsigned char *trame)
{
	unsigned char msb=0xFF;
	unsigned char lsb=0xFF;
	unsigned char temp;
	int ind=0;
	int taill=nombreOctet;
 
	nombreOctet=nombreOctet-2;
 
	do                         
	{
		if(nombreOctet>0)
		{
			temp = msb ^ trame[ind];
            ind++;
			msb = lsb ^ aCRCmsb[temp];
			lsb = aCRClsb[temp];
		}
	}while(nombreOctet--);
 
	trame[taill-2]=lsb;
	trame[taill-1]=msb;
	return true;
}

je rappel que si j'ai déclaré ces attributs et cette méthode en static c'est parce que je l'ai utilise dans un thread

merci d'avance

03/08/2006, 09h36
Médinoc

Citation:

Si la trame est correcte, les 2 derniers octets correspondent au msb et lsb de la trame.

Je ne vois pas du tout ce que tu veux dire par là...

PS: n'hésite pas à mettre des const pour tes deux tableaux statiques.
03/08/2006, 09h40
thony76

calcul des Bits de poid fort et bits de poid faible
03/08/2006, 09h46
Médinoc
Tu ne m'apprends rien, là...
Même avec ton calcul et tes tables, je n'arrives pas à voir quels bits de poids fort et faible tu veux, et pourquoi il te faut deux octets pour cela.
- Ce n'est sûrement pas le bit de poids fort du premier octet de la trame et le bit de poids faible du dernier ?
- Serait-ce la somme du bit de poids fort de chaque octet, et même chose pour le bit de poids faible ?
- Ou bien, un XOR entre les OCTETS de poids fort de chaque paire d'octet ?
- Edit: D'après ton code, ça a l'air d'être un XOR entre l'octet de poids fort de chaque paire, une valeur de tableau dépendant de l'octet de poids faible de la paire précédente et une valeur de tableau dépendant du résultat d'un autre XOR...
  Et les octets ne sont pas lus deux par deux...
Tant qu'on ne sait pas précisément ce que tu veux calculer, on ne peut pas t'aider...

Edit: C'est un algorithme de calcul de CRC ?

Tu devrais essayer ceci : J'ai simplifié les tests dans la boucle.
Les déclarations const, aussi, ça peut parfois aider à optimiser (j'ai aussi déclaré const les tableaux)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
//[static]
bool CCom::calculerPoidBitsEx(int nombreOctet, unsigned char *pTrame)
{
unsigned char msb=0xFF;
unsigned char lsb=0xFF;
unsigned char temp;
int index=0;
int const taill=nombreOctet;
 
unsigned char *pCrc = &pTrame[taill-2];
unsigned char const *pcTrame = pTrame;
 
 
nombreOctet=nombreOctet-2;
 
while(nombreOctet>0)
{
	temp = msb ^ pcTrame[index];
	index++;
	msb = lsb ^ aCRCmsb[temp];
	lsb = aCRClsb[temp];
	nombreOctet--;
}
 
pCrc[0]=lsb;
pCrc[1]=msb;
return true;
}

03/08/2006, 10h35
thony76

Désolé, je me suis un peu absenté

Pour répondre à tes questions :
Non, ce n'est pas le bit de poids fort du premier octet de la trame et le bit de poids faible du dernier.
Non, je ne fais pas de somme entre les bits
En fait, tu as bien analysé la méthode.

Je vais essayer ta proposition, merci
03/08/2006, 10h52
thony76

bonne nouvel en mode débug ça fonction correctement
mauvaise nouvel, avec l'executable la sitaution est pire car Window demande à arréter l'application.

étrange 8O

le problème vient peut de la configuration de Visaul C++ quand il contruit
l'exe???
03/08/2006, 11h04
Médinoc

Bizarre, j'ai testé la fonction (avant et après modification, en comparant les résultats) en debug et en release, et tout fonctionnait...

Tu es sûr que tu as toujours la place de mettre ton CRC dans le buffer de trame ?

Bref, tu es sûr que l'erreur ne vient pas d'ailleurs?

pour ce qui est de la place dans la trame, normalement j'en ai comme tu peus le voire dans ce morceau de code.
ce code est dans la fonction appellée par mon thread

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
...
if(nLength = ReadComm(buffer, 100, INFO))
				{
					if(buffer[0]==129)
					{
						msb.Format("%d",buffer[nLength-2]);
						lsb.Format("%d",buffer[nLength-1]);
 
						calculerPoidBits(nLength,buffer);
 
						calculemsb.Format("%d",buffer[nLength-2]);
						calculelsb.Format("%d",buffer[nLength-1]);
						if(msb==calculemsb && lsb==calculelsb)
						{... modif control
}...

03/08/2006, 12h24
Médinoc

Ben dans ce cas, je ne vois pas... 100, c'est la taille de ton buffer ?

PS: Ah au fait, j'ai testé avec des octets nuls au CRC, moi. Mais normalement, ça ne devrait pas avoir d'influence... À vérifier.
03/08/2006, 13h20
thony76

ok j'ai trouvé le problème
:P
j'ignore pourquoi ça influancer au tant ma fonction calcul...
8O
mais en modifiant plus haut dans mon code la condition d'une boucle lier à un appel d'une autre fonction mon problème de resource à disparu
en faite je me retourver à éffectuer plusieur fois de suite une lecutre du port et le calcul
:aie:
désolé de t'avoire guider sur une fausse piste

il y a toujour le problème de l'exe qui fonctionne pas et le debug oui, mais ceci est une autre histoire.
alors une derniere fois merci