forcer une interpretation en binaire

Bonjour

Un convertisseur AD me donne un résultat sur 10 bits binaires( donc compris entre 0 et 1023 en équivalent décimal)
je dois multiplier ce nombre binaire par un nombre 0,37

J'ai l'intuition que je ne puis faire une simple multiplication d'un type int par un float ( ou un binaire par un float )....vrai ou non ?
Si je n'ai pas le droit, le plus simple me semble de convertir mon nombre binaire en décimal ( je me suis ecrit une petite routine bin2dec )

Cela marche nickel si je précise que mon nombre binaire est bien 0bxxxxxxxxxx ;mais si j'oublie le 0b, le nombre est considéré comme un entier et du coup 0b0110010000 qui vaut 400 se retrouve valoir 110010000 !!!

Question bête...
1) Comment forcer le soft a considérer par exemple que 0110010000 soit un binaire ( car je ne vois pas le type binaire dans les types du langage...)
2) Comment éventuellement rajouter 0b en entête du nombre

je précise...quand le soft tourne, je n'ai pas de clavier pour rajouter ce 0b d'entete manuellement

Bon, vous avez vu, je débute en C !!!
merci d'avance pour tout tuyau

Bonjour,

Un nombre c'est un nombre. Quand on parle de binaire, décimal, hexadécimal ou que sais-je, ça n'est qu'une convention de représentation. Ce qu'il y a dans une variable c'est un nombre!!!
Quand tu écris 0b110010000, tu as écrit le nombre que les humains écrivent habituellement 400. Tu pourrais aussi bien l'écrire 0x190 ça n'y changerait rien.

Bonjour

Citation:

---

Envoyé par VF38C4HX

( car je ne vois pas le type binaire dans les types du langage...)

---

Il n'y en n'a pas. Il n'y a que des conventions d'écritures. 97 par exemple c'est du décimal. Mais je peux aussi l'écrire 0x61 (hexa). Ou bien 0141 (octal, comme précisé avec ce "0" obligatoire). Ou bien je peux aussi l'écrire 'a' (valeur ascii du caractère "a" qui vaut 97).
Ensuite je peux calculer 97+1, ou bien 0x61+1, ou bien 0141 + 1, ou bien 'a' + 1.
Puis je peux afficher ce résultat au format "%d" (décimal), ou bien "%o" (octal), ou bien "%x" (hexa), ou bien "%c" (caractère). J'aurai alors 98, ou 0142, ou 62, ou 'b'.
Bref toutes ces notions ne sont qu'une façon de "représenter" la quantité 97 qui reste, en interne, toujours la même.

Et donc le code suivant est valide :

Code:

---

1 2	unsigned int raw = ADC_read_value(); float cleaned = raw * 0.37f;

---

Il n'y a rien de plus à faire.

merci a tous....mais
Il semberait que j'aie un probleme avec le compilateur Mplab Ide ( de Microchip )

mon équation
float T = raw*0,37f est refusée...
Il interprete le f comme un digit ( invalid digit 'f' in decimal constant....

et si je tente sans le f

float T = raw*0,37, je me retrouve avec un autre message" expression result unused" [Wunused-value]
bref, suis concé

je fais un essai sous CodeBlocks:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <stdio.h>     int main() {   unsigned int Adc = 0b0110010000; //400 //unsigned short PotVal = 0000000000;       float T = (-(Adc*0.3711f) + 400);   printf("PotVal %d\n T %f\n",Adc,T);   return 0; }

---

cela donne le resultat attendu...Si je retire le 0b dans unsigned int 'Adc, le résultat est faux ( ou plutôt est juste mais pas ce que j'attends..par ce que le chiffre est considéré comme entier)
Il faut que je trouve le moyen de specifiier

Là c'est compliqué :aie: :aie: : tu es 1 débutant et en + tu as 1 compilateur limité.

"invalid digit 'f' in decimal constant" : cela veut sûrement dire que ton compilateur est "exotique". À la fin d'1 nombre on peut forcer sa "précision" en rajoutant 1 lettre : f (ou F apparemment) pour float, L (ou l apparemment) pour long (et peut-être d'autre comme UL)
"expression result unused" : avertissement pour te dire que tu n'utilises pas la variable. C'est ultra méga classique. Et donc, tu sembles dire que ton compilateur "exotique" la met en erreur.

Et apparemment :koi: l'écriture unsigned int Adc = 0b0110010000; est soit via 1 extension C (gcc : Binary Constants using the ‘0b’ Prefix) soit tu utilises 1 compilateur C++ ( >= C++14)

Et comme tu es débutant, pour représenter 1 nombre tu as 3 façons :

• des entiers : normal avec des 0 et des 1
• des entiers négatifs : complément à 1 ou complément à 2
• des entiers flottants : format IEC 60559

Citation:

---

Envoyé par VF38C4HX

Si je retire le 0b dans unsigned int 'Adc, le résultat est faux ( ou plutôt est juste mais pas ce que j'attends..par ce que le chiffre est considéré comme entier)

---

Ben oui. S'il faut une spécificité pour indiquer une base précise, sans cette spécificité la base est alors prise par défaut dans la base courante (10 dans notre système). C'est comme pour mon exemple avec 0142 (142 en base 8). Si je ne mets pas de "0" devant, alors ce nombre sera considéré comme étant 142 écrit en base 10.

Citation:

---

Envoyé par VF38C4HX

Il faut que je trouve le moyen de specifiier

---

Attention, si comme je le crois tu parles d'un nombre "0110010000" lu depuis une entrée IO quelqonque alors dans ce cas ce n'est pas la bonne façon de procéder.
Si j'entre par exemple au clavier les digits "123", alors cela ne sera jamais compris comme l'entier 123.
En réalité j'entre 3 caractères '1', '2' et '3' (qui valent respectivement 49, 50 et 51 dans la table ascii). Pour que la suite '1', '2' et '3' soit convertie en valeur 123 il faut utiliser un algorithme de conversion. Pas super compliqué (suffit d'ôter la valeur '0' (=48) à chaque digit, additionner ce résultat à un total qui a été initialisé à 0 au début de l'algo et multiplier ce total par 10 à chaque tour). Pas compliqué mais faut le faire (enfin il existe déjà via les fonctions atoi() ou strtol()).
Si de ton côté tu veux convertir la suite de digits "0110010000" en valeur binaire 0110010000 il faut utiliser un algorithme similaire (sauf qu'il faut multiplier le total par 2 au lieu de 10).

Citation:

---

Envoyé par VF38C4HX

Il semberait que j'aie un probleme avec le compilateur Mplab Ide ( de Microchip )

---

Enfer et damnation !

Citation:

---

Envoyé par foetus

tu as 1 compilateur limité.
[...]
cela veut sûrement dire que ton compilateur est "exotique"

---

Non, le mot que tu cherches c'est "pourri" :aie:. Microchip a fait quelques compilateurs nuls. J'ai eu des prises de tête infernales sur un projet perso, et c'est un running gag avec des collègues de troller sur les compilateurs Microchip.

Citation:

---

Envoyé par VF38C4HX

mon équation
float T = raw*0,37f est refusée...
Il interprete le f comme un digit ( invalid digit 'f' in decimal constant....

---

Tente avec double T = raw*0,37;, sait-on jamais. Si, il va falloir ouvrir la doc du compilateur pour voir si c'est supporté sur ton MCU.

Citation:

---

Envoyé par foetus

Et apparemment :koi: l'écriture unsigned int Adc = 0b0110010000; est soit via 1 extension C (gcc : Binary Constants using the ‘0b’ Prefix) soit tu utilises 1 compilateur C++ ( >= C++14)

---

C'est une extension classique de pas mal de compilateur. De plus, le binaire est très utilisé en embarqué. Je ne suis pas surpris qu'un compilateur de Microchip l'implémente.

A noter que si tu n'as pas besoin des chiffres après la virgule, tu peux faire ton calcul sans utiliser de float : tu multiplies par 37 puis divise par 100.
Pour ne pas qu'il y ait de dépassement mémoire lors du calcul, il te faut donc travailler sur des variables 32bits... cette astuce peut être utile si tu travailles sur un petit microcontrôleur qui n'a pas de FPU : pas besoin d'utiliser la bibliothèque qui gère les float.
... et selon ton besoin, tu n'as peut-être même pas besoin de diviser par 100 selon l'unité de la mesure que tu veux (ex : passer en mV au lieu de V).

Er déja ...Merci a tous
J'avance...car j'ai raconté pas mal de c....ies

Deja, je me suis planté dans l'écriture de l'équation...0,3711 au lieu de 0.3711 !!!
Du coup, j'accusais a tort le compilo qui maintenant accepte la multipliucation par un real (0.3711f)

Me reste un truc a trouver,
Le résultat du calcul me donne un float...ce qui est normal puisque je multiplie par un real

Comme je n'ai pas accès a la bibliothèque math.h, qui me permettrait de récupérer la mantisse , je tente le coup en (castant..) le float
Ca marche...en partie ce qui me semble zarbi

Le ADC () donne un résultat sur 10bits donc( 000000000 à 1111111111.) et bien que le type de la valeur retournée soit unsigned short, j'ai l'impression que le calcul plante ( c.a.d me donne n'importe quoi..) quand je dépasse 255
ce qui tendrait a dire que le 1 est pris comme bit de signe au lieu de 2 a la puissance 9

je m'y remets demain !!!

Citation:

---

Envoyé par VF38C4HX

Deja, je me suis planté dans l'écriture de l'équation...0,3711 au lieu de 0.3711 !!!

---

Remarque cela nous a tous échappé !!!

Citation:

---

Envoyé par VF38C4HX

Comme je n'ai pas accès a la bibliothèque math.h, qui me permettrait de récupérer la mantisse , je tente le coup en (castant..) le float
Ca marche...en partie ce qui me semble zarbi

---

Tu peux préciser ce que tu entends par "mantisse" ? La partie entière ? La partie float ?
En tout état de cause, pour obtenir la partie décimale d'un nombre, suffit de lui ôter sa partie entière => T-(int)T

Citation:

---

Envoyé par VF38C4HX

Le ADC () donne un résultat sur 10bits donc( 000000000 à 1111111111.) et bien que le type de la valeur retournée soit unsigned short, j'ai l'impression que le calcul plante ( c.a.d me donne n'importe quoi..) quand je dépasse 255
ce qui tendrait a dire que le 1 est pris comme bit de signe au lieu de 2 a la puissance 9

---

Alors là pareil, il faut bien comprendre ce que signifie "signed/unsigned".
Un nombre n'est qu'un nombre. Si je travaille en char, que je sois signed ou unsigned, 0xff vaut 0xff. Si je lui ajoute 1 il passe à 0 et si je lui retranche 1, il passe à 0xfe. Et si je l'affiche au format "%u" la fonction printf() le prendra comme unsigned (même s'il est signed) et affichera 255. Et au format "%d", la fonction considèrera le premier "1" comme bit de signe et affichera -1, même s'il est unsigned.
La caractéristique signed/unsigned n'intervient pas quand on traite le nombre, ou qu'on lui applique des opérations. Elle intervient quand on copie le nombre dans une variable plus large (char vers short, short vers long, etc).
S'il est unsigned, alors 0xff copié dans un short donnera 0x00ff. Mais s'il est signed, alors il y aura extension du bit de signe et ça donnera 0xffff. Et ce, quelle que soit la caractéristique signed/unsigned du short récepteur. Cette caractéristique ne sera elle-aussi prise en compte que quand le short sera copié dans un long (s'il l'est un jour).
C'est ça le seul et unique rôle de signed/unsigned.

Heu, je crois que la mantisse est la partie entière...et comme c'est celle que je souhaite récupérer, j'ai casté comme suit ( PotVal est la valeur 10bits unsigned short fourni par la fonction Adc()
float T = ((-PotVal*0.3711f) + 400);
Nombre = (int)T; // nombre est un unsigned short ou uint16_t

malgré cela, j'ai une partie de l'affichage qui foire
donc, je cherche !!!

Citation:

---

Envoyé par VF38C4HX

Heu, je crois que la mantisse est la partie entière..

---

Alors dis simplement "partie entière", cela sera plus simple.
Surtout qu'en réalité, ce n'est pas ça la mantisse. La mantisse c'est la transformée d'un nombre quelconque dans un nombre compris entre 1 et 10. Exemple 1234 sa mantisse c'est 1,234. Et pour avoir 1234 à partir de 1.234 il faut multiplier par 10^3 donc 1234 c'est 1.234 * 10^3. D'où le couple "mantisse+exposant" permettant de retrouver le nombre initial. Ainsi 1234 c'est (m=1.234, e=3).

Citation:

---

Envoyé par VF38C4HX

malgré cela, j'ai une partie de l'affichage qui foire

---

Comme Platon dans sa caverne, ce que tu vois à l'écran n'est qu'une représentation de ce qu'il y a en ram. Et cette représentation dépend de beaucoup de facteurs (la fonction utilisée, et les ordres d'affichage que tu as passé à ladite fonction). Cf mon exemple avec 0xff qui sera affiché 255 ou -1 selon le format spécifié...

Attention à la taille des types, elle dépend du compilateur et de l'architecture de la CPU.

Les seules choses qui sont certaines sont :
- un char fait 1 octet
- un short a une taille supérieur ou égale à un char
- un int a une taille supérieur ou égale à un short
- un long a une taille supérieur ou égale à un int
... on retrouve beaucoup sur le Web des articles qui annoncent une taille pour un type donné. Par exemple, on retrouve souvent qu'un int fait 4 octets alors qu'il peut n'en faire qu'1. Ce que j'ai remarqué (mais je ne sais pas si c'est écrit dans la norme), c'est qu'un int a en général la taille qui correspond au nombre de bits de la CPU (ex : processeur 8bit => taille d'un int vaut 1 octet, processeur 32bit => taille d'un int vaut 4 octets).

Donc le mieux pour connaitre la taille d'un type est d'utiliser sizeof : printf("Sizeof(int) = %zu\r\n", sizeof(int))

Citation:

---

Envoyé par boboss123

c'est qu'un int a en général la taille qui correspond au nombre de bits de la CPU (ex : processeur 8bit => taille d'un int vaut 1 octet, processeur 32bit => taille d'un int vaut 4 octets).

---

:whistle: nope :nono: [c'est 1 tableau que je sors souvent :oops: ] (sur des microprocesseurs "embarqué", je pense que c'est encore + compliqué)

Pièce jointe 634033

Citation:

---

Envoyé par boboss123

Par exemple, on retrouve souvent qu'un int fait 4 octets alors qu'il peut n'en faire qu'1

---

La norme C99 https://www.open-std.org/jtc1/sc22/w...docs/n1256.pdf donne la plage minimale que doit permettre de représenter chaque type d'entier. Voir la section 5.2.4.2.1 Sizes of integer types <limits.h>. On voit qu'un int fait au moins 16 bits de large.

Avec un compilateur conforme, il est donc impossible qu'un int fasse 1 octet.

A noter que la norme ne parle pas d'octets mais de bytes. Historiquement, un byte n'était pas forcément un octet. Voir l'intro https://fr.wikipedia.org/wiki/Byte On pourrait donc imaginer qu'il existe une plateforme exotique pour laquelle 1 byte == 16 bits, ce qui permettrait d'avoir CHAR_BIT == 16, et donc d'avoir sizeof(int) == 1. Mais bon de nos jours, la probabilité de tomber sur une telle plateforme est très faible...

Citation:

---

Envoyé par Bktero

A noter que la norme ne parle pas d'octets mais de bytes. Historiquement, un byte n'était pas forcément un octet. Voir l'intro https://fr.wikipedia.org/wiki/Byte On pourrait donc imaginer qu'il existe une plateforme exotique pour laquelle 1 byte == 16 bits, ce qui permettrait d'avoir CHAR_BIT == 16, et donc d'avoir sizeof(int) == 1. Mais bon de nos jours, la probabilité de tomber sur une telle plateforme est très faible...

---

Probabilité faible mais non nulle, quand je travaille parfois sur TMS320 qui a des fonctionnalités intéressantes en traitement du signal, j'ai alors:
- taille min adressable : 16 bits et adresse maximale : 0xFFFF. D'où une capacité mémoire de 128KO.
d'où:
- CHAR_BIT=16, le char accède à un byte de 16 bits (donc 2 octets)
- sizeof(char) = sizeof(short) = sizeof(int) = sizeof(void*) = 1.
- sizeof(long) = sizeof(float) = sizeof(double) = 2. Le type double est réduit à celui du float.
- et uint8_t et int8_t n'existent pas.

Et c'est hard pour écrire du code utilisable à la fois sur ce microcontrôleur et les autres. J'y arrive en C++, pas en C.

Les DSP sont une des exceptions notables, où souvent tous les types ont la même taille (et des fois c'est beaucoup).

Content de voir que mon exemple n'était pas totalement farfelu, quelqu'un est exactement dans ce cas :ptdr: Tu fais quoi de marrant avec ces processeurs ?

Après, j'ai quand même préciser "de nos jours". Je pensais à des processeurs modernes. Wikipédia dit que "Texas Instruments TMS320 is a blanket name for a series of digital signal processors (DSPs) from Texas Instruments. It was introduced on April 8, 1983 through the TMS32010 processor, which was then the fastest DSP on the market". Ca fait donc presque 40 ans ;)

Citation:

---

et uint8_t et int8_t n'existent pas.

---

Tous les types à taille fixe (xxx_8_t, xxx_16_t, etc.) sont optionnels pour une raison :)

Citation:

---

Envoyé par Sve@r

Alors dis simplement "partie entière", cela sera plus simple.
Surtout qu'en réalité, ce n'est pas ça la mantisse. La mantisse c'est la transformée d'un nombre quelconque dans un nombre compris entre 1 et 10. Exemple 1234 sa mantisse c'est 1,234. Et pour avoir 1234 à partir de 1.234 il faut multiplier par 10^3 donc 1234 c'est 1.234 * 10^3. D'où le couple "mantisse+exposant" permettant de retrouver le nombre initial. Ainsi 1234 c'est (m=1.234, e=3).


Comme Platon dans sa caverne, ce que tu vois à l'écran n'est qu'une représentation de ce qu'il y a en ram. Et cette représentation dépend de beaucoup de facteurs (la fonction utilisée, et les ordres d'affichage que tu as passé à ladite fonction). Cf mon exemple avec 0xff qui sera affiché 255 ou -1 selon le format spécifié...

---

Je me suis simplifié la vie en dégageant tous les formats exotiques, pour ne rester qu' avec des int et des char...et tout ce qui foirait ou s'affichait de manière bizarre ets rentre dans l'odre !!!
Re Grand merci a tous...et a bientot pour le prochaine problème !!!

Citation:

---

Envoyé par Bktero

Les DSP sont une des exceptions notables, où souvent tous les types ont la même taille (et des fois c'est beaucoup).

Content de voir que mon exemple n'était pas totalement farfelu, quelqu'un est exactement dans ce cas :ptdr: Tu fais quoi de marrant avec ces processeurs ?

Après, j'ai quand même préciser "de nos jours". Je pensais à des processeurs modernes. Wikipédia dit que "Texas Instruments TMS320 is a blanket name for a series of digital signal processors (DSPs) from Texas Instruments. It was introduced on April 8, 1983 through the TMS32010 processor, which was then the fastest DSP on the market". Ca fait donc presque 40 ans ;)

Tous les types à taille fixe (xxx_8_t, xxx_16_t, etc.) sont optionnels pour une raison :)

---

Pour les prochains produits, on remplacera peut-être le TMS320 par un plus récent. Mais on continuera surement à utiliser des composants plus anciens (MSP430) pour d'autres produits car rien sur le marché permet de rester en très basse consommation (autonomie de plusieurs années sur une pile AAA).

Ce sont des produits utilisés dans le nucléaire. Certains basse consommation comme un dosimètre actif.
Pour d'autres la conso n'est pas le problème, il y a assez de courant dans une centrale, c'est le poids. Un testeur de contamination résiduelle pour du démantèlement c'est 30 tonnes concentrées dans quelques mètres cubes. Et pour livrer nos clients, on utilise des porte-chars et en ce moment c'est pas facile d'en avoir :D