Utilisation valeurs Réelles sous PIC18 : Float ou Int ?

[invite0e0d6f65]

Bonjour à tous !

J'ai besoin d'avis avisés concernant la programmation de PIC18.

Concrètement, je suis en train de programmer le pilotage d'un écran tactile. Cet écran tactile devra afficher des valeurs de mesures qui seront des valeurs décimales (ex : 32,5 %). Aussi depuis cet écran, je souhaite envoyer des valeurs de consignes qui seront aussi de la forme : 19,6%.

J'aimerais savoir s'il est obligatoire d'utiliser des variables de types "float" pour réaliser ce genre de tâche. Je suis assez réticent à utiliser ce format ou type de variables, car d'après tout ce que j'ai pu lire sur le net, le traitement de ces variables est long, prend beaucoup d'espace mémoire etc... Et s'il n'est pas forcément nécessaire d'utiliser de "float" comment puis-je procéder au traitement de ces "faux réels" (si je peux appeler cela ainsi) ?

Par avance merci de votre aide !
-----

[guillaume83]

Bonjour,
si il n'y a pas de calculs à faire , tu peux stocker la partie entiére et la partie decimale dans deux variables différentes.
Puis il suffit dafficher la patie entiére, une virgule et la partie decimale.
exemples:
printf("ma valeur= %u , %u", partie entiére,partie decimal);
@+

[RISC]

Salut,

Avec les 8bits il faut tout faire pour éviter les float...car cela massacre les temps de calcul.
Il est très possible de "simuler" les float en mémorisant les puissances de 10 pour faire les calculs en int

a+

[invite0e0d6f65]

merci pour vos réponses !

@guillaume83 : Il y a du calcul derrière. Par exemple si j'envoie de l'écran vers le PIC une nouvelle consigne de 19,6, cette valeur sera réutilisées pour le pilotage de mon système.

@RISC :

Il est très possible de "simuler" les float en mémorisant les puissances de 10 pour faire les calculs en int

Je ne comprends pas très bien votre idée. Serait-il possible d'obtenir plus d'explications ?

[A voir en vidéo sur Futura]

[PA5CAL]

Bonjour

Le type « float » sert à stocker un nombre sous la forme d'un représentation en virgule flottante, en règle générale conformément à la norme IEEE 754. Techniquement, c'est une concaténation d'entiers contenant le signe, la mantisse et l'exposant servant à cette représentation.

C'est un type utile dans la programmation en langages évolués (où la portabilité du code est privilégiée aux performances), et sur les systèmes présentant une unité de calcul matérielle capable de manipuler cette représentation.

Sur les petites microprocesseurs et µC ne disposant pas d'unité de calcul en virgule flottante, pour atteindre de bonnes performances il peut être préférable de s'en tenir à des calculs entiers, et de solutionner autrement la question de la représentation des grandeurs traitées, ce qui peut être réalisé au travers :

• d'un changement d'unités, ou d'une représentation en virgule fixe, ce qui revient au même (par exemple, l'entier 196 peut représenter 19,6% exprimé en ‰) ;

• d'une représentation sous forme de fractions (par exemple, pour 32,5%, le couple d'entiers {65;2} peut représenter la fraction 65/2=32,5) ;

• d'une forme simplifiée de représentation et de calcul en virgule flottante, allégée des contraintes liées au respect de la norme IEEE 754 (par exemple, le couple d'entiers {325;-1} peut représenter 325x10^-1=32,5, ou encore le couple d'entiers {65;-1} peut représenter 65x2^-1=32,5).

[invite0e0d6f65]

@PA5CAL : Cela me paraît relativement compliqué, surtout pour réaliser des calculs ! Car pour mes calculs j'ai plusieurs unités à prendre en compte.

Par exemple : j'ai des entrées ANA 0-5V (signaux linéaires amplifiés) converties par le CAN 10 bits (1024 points au pas de (4,88*10^-3)V). Ce 0-5V représente en réalité un 0-x%. Pourquoi la borne supérieure est-elle x% ? Car en fait, pour pallier à la dégénérescence de mon capteur dans le temps, on a une fonction permettant l'étalonnage du capteur, ce qui signifie grosso modo que l'on recalcule notre "a" de l'équation y=ax (signaux linéaires). Ceci étant possible avec des étalons.

Donc premier calcul, le calcul de notre coefficient directeur : a = y/x (avec y = la valeur lue sur le CAN et x = la valeur insérée lors de l'étalonnage).
Seulement après je peux exploiter cette entrée pour le pilotage mon système. Le but du pilotage est de respecter une valeur de consigne insérer par l'opérateur, cette consigne est de la forme XX,X %. Il faut donc retranscrire cette valeur de consigne sur l'échelle précédemment calculée, ce qui amène le second calcul : y = ax (avec a = coef directeur, x = valeur insérée par l'opérateur et y = valeur de consigne retranscrite sur l'échelle 0-5V). Par la suite, il faut que je transforme mon 0-5V, qui ressemble plus à un Int en hexa suite à la conversion du CAN, en une valeur lisible et compréhensible afin de l'afficher sur un écran tactile. Donc un troisième calcul tout aussi compliqué ...

Enfin non, ce sont des calculs très simples et basiques mais qui s'avèrent compliqués sans l'utilisation de float. Du moins pour moi qui n'aie pas l'habitude d'utiliser l'une de tes techniques.

Si tu pouvais me donner un exemple, je t'en serais fort reconnaissant !

[invite855cd7fb]

Au lieu d'avoir 19,6 stocké dans un float qui consomme plein de mémoire et de cycles de calculs dans ton µC tu stocke 196 voire 1960 dans un int. tu n'a plus qu'a diviser par 100 avant d'afficher et hop.

[RISC]

Salut,

Si tu utilises un CAN, une astuce pour simplifier les calculs est d'utiliser une référence de 5,12V au lieu de 5V ;=)

a+

[invite0e0d6f65]

@MiGaNuTs : PA5CAL à soumis la même solution que toi post#5. Si tu peux me soumettre un exemple, concernant le post#6. Ça pourrait m'aider.

@RISC : Certes oui c'est une astuce, mais je me retrouve tout de même avec un nombre à 10^-3. Mais en fait, pour mon CAN et pour alléger l'électronique externe, j'utilise la tension d'alimentation. Si tu es capable, de me donner un petit exemple concernant le post#6 je t'en serais fort reconnaissant.

[invite0e0d6f65]

Je viens de m'apercevoir de quelque chose de plutôt étonnant.

Afin de ne pas utiliser de float, j'ai utilisé la première technique suggérée par PA5CAL, c'est à dire d'utilisé des int avec un facteur supplémentaire pour éviter la virgule.

Et là je viens de me rendre compte que mon PIC ne veut pas faire ce genre de calculs : x = 558*1000 ; (x étant un unsigned long ayant pour résultat à l'opération suivante 33712). Je trouve ça incompréhensible...

Quelqu'un saurait-il d'où cela peut venir ?

[PA5CAL]

L'opération réalisée est une multiplication d'entiers sur 16 bits, et le résultat sur 32 bits a été tronqué sur 16 bits.

Pour le prouver, il suffit de considérer la représentation binaire (ou hexadécimale) des nombres impliqués :
• 33712 donne 0x83B0
• 588x1000=588000 donne 0x883B0

Puisque x est un unsigned long, j'imagine qu'il suffit qu'au moins l'un des deux nombres du produit soit expressément de type long ou unsigned long pour que ton compilateur donne un résultat correct... par exemple en écrivant « 1000UL » dans ta formule.