Discussion :

[Porkipic]

Bonjour,

Je me lance dans la programmation en C sur microcontrôleur et je rencontre un problème d'ordre bizarre, voire inexpliqué.

Voici le code qui pose un soucis :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
void Display_Cursor(signed int lat, signed int lon) {
  unsigned char latitude_y, longitude_x;
 
  //Latitude and Longitude scaling for 128x64 display:
  //Latitude: Input range is -90 to 90 degrees
  //Longitude: Input range is -180 to 180 degrees
  latitude_y = ((61*(90-lat))/180)+1;
  longitude_x = ((125*(lon+180))/360)+1;
 
  //Cursor drawing:
  Glcd_H_Line(0, 127, latitude_y, 2);
  Glcd_V_Line(0, 63, longitude_x, 2);
 
  //Display latitude and longitude "translation" to fit on the screen
  IntToStr(latitude_y,dispLatStr);
  IntToStr(longitude_x,dispLonStr);
  Glcd_Write_Text(dispLatStr,0,6,1);
  Glcd_Write_Text(dispLonStr,0,7,1);
 
  //Blinking
  Delay_ms(500);
  Glcd_Fill(0x00);
}

Le problème c'est que la ligne verticale (longitude) ne s'affiche pas car elle est hors de l'écran (position longitude=196 sur un écran de 128 pixels). Cela peut être solutionné en affectant la valeur au paramètre "lon".
Pour résumer :
- Si le paramètre "lon" de la fonction est utilisé tel quel (sa valeur est de 166 à l'appel de la fonction), le résultat du calcul est faux.
- Si je met "lon = 166;" dans la fonction, le résultat est correct.

Ma question est simple : comment se fait-il qu'avec une même valeur, le résultat d'un calcul puisse être différent ?
Question bonus : pourquoi ce problème n'est pas rencontré pour le calcul de la latitude ?

Si vous avez besoin de plus de renseignements, n'hésitez pas.
Merci d'avance pour vos réponses.

[Bktero]

Quel est ton micro-contrôleur (µC) ? Est-ce un µC 8 bits ?

Tu peux nous dire la valeur rendue par sizeof int ?

[Porkipic]

Effectivement, j'ai omis les infos d'environnement. Les voici donc :
IDE : MikroC
µC : 8bit 18F4250.

Pour ce qui est du siezof int, je vous répond demain, car je n'ai pas la carte de dev sous la main.

[skeud]

C'est un µC en 8 bit du coup lors de ton calcul:
125*(166+180)=43250.
Or 43250 = 1010100011110010 donc pour pouvoir stocker ce nombre, il te faut un espace de 16bit (sur un pc, ça passe nikel comme c'est du 32 ou 64bit).

Par contre sur ton µC c'est du 8bit donc tu dépasse ta valeur INT_MAX. C'est donc normal que ton calcul soit faux.

Pour la solution, je n'ais pas assez de connaissances sur ce genre de programmation pour te répondre, mais tu as une piste .

[phi1981]

Si Bktero et skeud ont raison (et je pense qu'ils ont raison), alors il reste une question sans réponse :

comment se fait-il qu'avec une même valeur, le résultat d'un calcul puisse être différent ?

Ma théorie, c'est que si tu écris la valeur de variable directement dans le source de la fonction, alors d'une certaine manière, pour le compilateur, ce n'est plus une variable, c'est une constante.
Il peut donc remplacer ce code :

Code :

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

1
2
 
longitude_x = ((125*(lon+180))/360)+1;

par ceci :

Code :

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

1
2
 
longitude_x = ((125*(166+180))/360)+1;

et donc, comme optimisation, virer le calcul et coder directement la valeur résultante dans longitude_x.
Mais ton compilateur ne souffre pas des mêmes problèmes de précision, donc la valeur résultante est "juste".

[Obsidian]

Hello à tous !

Ma question est simple : comment se fait-il qu'avec une même valeur, le résultat d'un calcul puisse être différent ?

Il faudrait le code du niveau juste au-dessus pour voir comment ton paramètre est transmis. Et d'une manière générale, il faudrait vérifier au debugger que la valeur arrive bien intacte au début du code de ta fonction.

Question bonus : pourquoi ce problème n'est pas rencontré pour le calcul de la latitude ?

Parce que la formule n'est pas la même non plus et qu'à ce stade, le mystère n'est pas élucidé.

C'est un µC en 8 bit du coup lors de ton calcul:

Pendant très longtemps, on a travaillé avec des machines 8 bits, en temps qu'ordinateur de bureau (notamment les Thomson dans les écoles) et on manipulait des nombres plus larges. Heureusement ! La seule différence est que le calcul se fait en plusieurs étapes plutôt que tenir en une seule instruction assembleur, ce qui a d'ailleurs favorisé l'abandon de sa pratique au profit du C. Mais le C stipule en principe qu'un short int doit mesurer au moins 16 bits et qu'un int ne peut être moins large. Il est possible que sur certaines plateformes, ces valeurs soit revues à la baisse mais c'est très peu probable sans raison valable et ça n'a pas lieu d'être sur un micro-contrôleur récent et grand public comme le PIC 18Fxxxx.

125*(166+180)=43250.
Or 43250 = 1010100011110010 donc pour pouvoir stocker ce nombre, il te faut un espace de 16bit (sur un pc, ça passe nikel comme c'est du 32 ou 64bit).

À mon avis, c'est surtout ça le problème : on ne peut stocker 43250 que sur 16 bits non signés ! Le type int naturel est signé par défaut et c'est également ce format qui est utilisé par les arguments de la fonction. Si le format int est sur 16 bits par défaut sur cette cible, il n'y a pas de raison que le compilateur le promeuve automatiquement à un format plus grand. D'où la question très pertinente de Bktero.

Ma théorie, c'est que si tu écris la valeur de variable directement dans le source de la fonction, alors d'une certaine manière, pour le compilateur, ce n'est plus une variable, c'est une constante.
Il peut donc remplacer ce code […] et donc, comme optimisation, virer le calcul et coder directement la valeur résultante dans longitude_x. Mais ton compilateur ne souffre pas des mêmes problèmes de précision, donc la valeur résultante est "juste".

Très pertinent également, et c'est probablement pour cette raison que le calcul fonctionne dans ce cas si la « panne » ne vient pas d'une erreur de transmission en amont.