Discussion :

[Pete_Rebeat]

Bonjour à tous et merci d'avance pour votre aide.

Voilà, pour commencer, je travaille en C sur microcontroleur (STM32F4), j'essaie donc dans la mesure du possible de limiter mon utilisation des bibliothèques du C.

Je voudrais trouver un moyen de calculer le nombre d'éléments d'un chiffre Hexa (exemple 0x02CFF300). J'ai essayé un truc comme ça qui me paraissait pas mal:

Code :

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

1
2
3
4
 
uint32_t hexatest = 0x02CFF300;
char chaine[20]={'0'};
int longueur = sprintf(chaine,"%x",hexatest);

chaine[0] 2
chaine[0] C
chaine[0] F
chaine[0] F
chaine[0] 3
chaine[0] 0
chaine[0] 0

longueur 7


Le problème est que le premier zéro saute systématiquement dans le tableau et que j'ai donc dans longueur '7', ce qui est faux. Ce premier zéro est tres important dans mon application puisque c'est un quartet passé ensuite à un écran, qui doit savoir que 4 pixels sont vides. Je ne trouve pas d'autre solution pour mesurer le nombre de quartet de mon chiffre Hexa, je bloque, si l'un de vous a une idée ce serait génial.

Merci encore,

[Obsidian]

Bonjour,

Un chiffre hexadécimal représente exactement 4 bits. C'est d'ailleurs pour cela qu'on s'en sert : ça permet de passer immédiatement du binaire à l'hexa et vice-versa sans avoir à faire de calcul et le nombre de bits que l'on obtient reste compatible avec le format des mots binaires utilisées par toutes les machines encore en état de fonctionner.

Pour compter le nombre de chiffres hexa, il te suffit de supprimer des blocs de quatre bits par la droite jusqu'à ce que ton nombre devienne nul :

Code :

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

1
2
3
4
    uint32_t hexatest = 0x02CFF300;
    int      count    = 0;
 
    while (hexatest) { count++; hexatest >>=4; }

Maintenant, si tu veux tenir compte des zéros non significatifs, alors c'est le format de « uint32_t » qu'il faut connaître, parce qu'il est fixe. En l'occurrence, uint32_t signifie « entier non signé de 32 bits ». Il est donc toujours formé de 8 chiffres hexadécimaux exactement.

[Bktero]

@Obsidian : tu comptes le nombre de digits utiles, non ? 0x00000000 te donnera 0. 0x0000001 te donnera 1. Ton exemple donnera 7. Or, je pense que Pete_Rebeat voudrait obtenir 8. (EDIT: en fait, c'est ce qu'il y après ton bloc CODE )

Est-ce que sizeof(hexatest) * 8 / 4 ne fait pas l'affaire ?

[ram-0000]

Est-ce que sizeof(hexatest) * 8 / 4 ne fait pas l'affaire ?

voire même sizeof(uint32_t) * 8 / 4 (comme cela, pas de variable locale à déclarer)

[Pete_Rebeat]

Merci pour ces réponses. Ces solutions sont bonnes, sauf qu'elles ne fonctionneront pas pour un nombre avec moins de 8 quartets.

En l'occurence si j'ai une variable du style hexatest=0x02FF3, je voudrais retourner longueur=5, en tenant compte du premier zéro non significatif donc. D'autres idées?

[ram-0000]

une solution bourrin :

Code :

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

1
2
3
4
if(nombre <= 0x0000000f) len = 2;
else if(nombre <= 0x000000ff) len = 3;
else if(nombre <= 0x00000fff) len = 4;
...

Si tu n'exécute pas trop souvent ce code, c'est très rapide

C'est bourrin, je vous avais prévenu

[Médinoc]

@Pete_Rebeat: Impossible sans stocker l'information quelque part, car toi seul sais que le nombre est censé être affiché sur 5 chiffres même s'ils ne sont pas significatifs.
Il n'existe pas de type "nombre de 20 bits".

Par contre, tu peux faire une struct hexNumber { int value, int nbBits } pour stocker explicitement le nombre de bits du nombre...

----------------------------------------------------------------

Au passage, cette demande est vraiment bizarre. Pourquoi as-tu besoin d'un tel comportement? Que cherches-tu à faire, au juste?

[Bktero]

voire même sizeof(uint32_t) * 8 / 4 (comme cela, pas de variable locale à déclarer)

Ca permet de fonctionner quelque soit le type de la variable locale en fait. Deux stratégies valables, voir ce dont l'appli a besoin

Merci pour ces réponses. Ces solutions sont bonnes, sauf qu'elles ne fonctionneront pas pour un nombre avec moins de 8 quartets.

En l'occurence si j'ai une variable du style hexatest=0x02FF3, je voudrais retourner longueur=5, en tenant compte du premier zéro non significatif donc. D'autres idées?

En gros, tu veux le nombre de digits significatifs + 1 ? --> ajoute 1 au résultat de la solution d'Obsidian.
Si tu as uint64_t = 0x01; ça doit te rendre 2 ? Et uint64_t = 0x001; ?

C'est bourrin, je vous avais prévenu

En effet. Mais ça marche ^^

[Obsidian]

(EDIT: en fait, c'est ce qu'il y après ton bloc CODE )

C'est ma faute, désolé : j'ai posté trop vite et ai édité mon message juste après pour y ajouter le complément. Tu devais donc déjà être en train de lire la première partie. :-)

voire même sizeof(uint32_t) * 8 / 4 (comme cela, pas de variable locale à déclarer)

Ou encore, tant qu'à faire :

Code :

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

    (sizeof hexatest) * CHAR_BIT / 4

… comme ça, ça fonctionnera partout ! :-)

Merci pour ces réponses. Ces solutions sont bonnes, sauf qu'elles ne fonctionneront pas pour un nombre avec moins de 8 quartets.

En l'occurence si j'ai une variable du style hexatest=0x02FF3, je voudrais retourner longueur=5, en tenant compte du premier zéro non significatif donc. D'autres idées?

Je ne suis pas sûr de comprendre où tu veux en venir mais, si c'est bien ce à quoi je pense, sache qu'un nombre entier a un format fixe et qu'il ne s'agit pas du tout d'une chaîne de caractères. En l'occurrence :

Code :

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

1
2
3
4
    uint32_t hexatest = 0x14f;
    uint32_t hexatest = 0x0014f;
    uint32_t hexatest = 0x000014f;
    uint32_t hexatest = 0x0000014f;

… sont des expressions strictement équivalentes. Elles codent toutes la même valeur et seront toutes représentées sur 32 bits dans un uint32_t, quoi qu'il se passe. Et parce que uint32_t comporte exactement 32 bits, tu ne pourras jamais y stocker plus de 8 chiffres hexadécimaux.

Si c'est une suite de chiffres hexadécimaux de taille arbitraire que tu veux stocker puis traiter, et que cette chaîne peut éventuellement s'allonger jusqu'à plusieurs dizaines de chiffres, alors soit tu utilises un chaîne de caractères pour faire simple, soit tu déclares un tableau d'octets et tu y stockes tes chiffres par paire. Dans les deux cas, tu itères sur les élements, du premier au dernier.

[Pete_Rebeat]

Merci pour vos réponses, alors :

une solution bourrin :

Code :

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

1
2
3
4
if(nombre <= 0x0000000f) len = 2;
else if(nombre <= 0x000000ff) len = 3;
else if(nombre <= 0x00000fff) len = 4;
...

Si tu n'exécute pas trop souvent ce code, c'est très rapide

Effectivement bien violent mais ça devrait marcher!

@Pete_Rebeat: Impossible sans stocker l'information quelque part, car toi seul sais que le nombre est censé être affiché sur 5 chiffres même s'ils ne sont pas significatifs.
Il n'existe pas de type "nombre de 20 bits".

Justement lorsque j'écris 0x0023F0, j'écris bien 6 quartets, alors que dans 0x23F0, je n'en ai que 4. L'information est donc bien présente, sans la stocker ou que ce soit. Ce que je voudrais c'est justement récupérer cette information sans qu'elle ne soit tronquée.

Au passage, cette demande est vraiment bizarre. Pourquoi as-tu besoin d'un tel comportement? Que cherches-tu à faire, au juste?

Aha oui j'ai conscience que c'est un problème vraiment étrange. En fait je donne ensuite ce nombre Hexa à un écran, par octet, et du coup les zéros, même en début de nombre, ont leur importance. 0x02 et 0x20, ne représentent pas le même dessin par exemple.

En gros, tu veux le nombre de digits significatifs + 1 ? --> ajoute 1 au résultat de la solution d'Obsidian.
Si tu as uint64_t = 0x01; ça doit te rendre 2 ? Et uint64_t = 0x001; ?

Et bien 0x01 doit me rendre 2, 0x001 doit me rendre 3.

Etonnant qu'un problème si simple en apparence soit aussi prise de tête non?

[ram-0000]

Et bien 0x01 doit me rendre 2, 0x001 doit me rendre 3.

Etonnant qu'un problème si simple en apparence soit aussi prise de tête non?

Ce que tu ne comprends pas, c'est que 0x01 et 0x001 sont ABSOLUMENT égaux. Ce sont 2 manières différentes d'écrire le même nombre, c'est à dire 1.

C'est comme "4 = 04 = 004 = 0004", ces 4 nombres (ce sont des nombres, pas des chaines de caractères) sont ABSOLUMENT égaux. Une fois qu'ils sont stockés dans une variable, il n'y a AUCUN moyen de savoir si la valeur de cette variable provient de 4 ou 04 ou 004.

[Kannagi]

Etonnant qu'un problème si simple en apparence soit aussi prise de tête non?

J'avais un pote qui disais que les débutants font complexe alors qu'on peut faire simple.

Si j'ai compris ton probleme c'est par rapport a une chaine de caractère que tu veux voir (vu comme le dit ram-0000 0x01 ou 0x001 c'est tout a fait pareil juste une façon d'écrire différente) donc soit tu compte le nombre de caractère et la limite un simple strlen suffit soit y a un truc qui m’échappe.

[ManusDei]

Justement lorsque j'écris 0x0023F0, j'écris bien 6 quartets, alors que dans 0x23F0, je n'en ai que 4.

Non. Au moment où tu vas compiler, le compilateur va se dire (oui, mon compilateur parle tout seul, il devrait consulter un spécialiste) "Ben qu'est-ce qu'il fait Pete_Rebeat, ils servent à rien les 2 zéros devant dans 0x0023F0, allez, je gagne de la place, je change ça en 0x23F0, vu que c'est pareil."

Tu représentes un nombre entier, 0x23F0, 0x0023F0 ou 9200 ou 9,2x10^3 c'est la même chose pour ton ordinateur.

Pour faire la différence entre ces cas, tu dois stocker tout ça dans un char*, et convertir en nombre à chaque fois que tu voudras utiliser le nombre.

Edit : Ou le message de ram-0000, même principe

[Pete_Rebeat]

Alors j'ai tout à fait COMPRIS que 04 et 004 étaient parfaitement égaux arithmétiquement (j'ai du découvrir ça en CP...)

Le problème est exactement, comme l'a compris Kannagi, de capter combien de caractères j'ai écrit, et de les retourner (cf mon tout premier post).

Le problème étant que justement, lors du passage de l'hexa en string, à l'aide de sprintf, les zéros non significatifs du début sont zappés. Cela s'explique par le fait que la fonction interprete d'abord le chiffre à convertir en hexa, avant de la transformer en chaine. Si cette fonction transformait directement en chaine ce qu'elle 'voyait', je n'aurai pas de problème.

Edit : Ok ca marche, je passe directement en char alors, et le problème est reglé. Et du coup, pour repasser en hexa derriere, il ya une soution simple?

Merci encore à tous

[Kannagi]

Ah oui j'ai oublié mais tu peux pour sprintf spécifié le format , par exemple

Code :

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

int longueur = sprintf(chaine,"%.8x",hexatest);

chaine donnera 02CFF300 et si c'est plus petit ça donnera ce que tu veux j'imagine , plus grand il prendra plus en compte les zero devant (vu que j'ai mis 8 donc si en hexa ça donne plus de 8 chiffre y 'aura pas les zéro devant).

[Médinoc]

Et du coup, pour repasser en hexa derriere, il ya une soution simple?

Tu peux parser la chaîne avec la fonction strtol() ou strtoul() pour la reconvertir en nombre.

[Obsidian]

Le problème étant que justement, lors du passage de l'hexa en string, à l'aide de sprintf, les zéros non significatifs du début sont zappés. Cela s'explique par le fait que la fonction interprete d'abord le chiffre à convertir en hexa, avant de la transformer en chaine. Si cette fonction transformait directement en chaine ce qu'elle 'voyait', je n'aurai pas de problème.

Ce n'est pas la fonction qui interprète le chiffre de cette façon : c'est le fait que tu aies utilisé « uint32_t ».

Le C n'est pas un langage symbolique comme peuvent l'être certains langages interprétés comme le shell, le Perl ou le PHP. C'est le compilateur qui fait le travail a priori. Tu déclares un entier 32 bits qui vaut 0x02CFF300. Il génère donc « 00000010 11001111 11110011 00000000 » sur exactement quatre octets et inscrit cela en l'état directement dans ton exécutable. Lorsque ton programme est lancé, il dispose de cette valeur au format que tu as spécifié mais ne sait absolument pas comment il a été défini. Si tu avais écrit ce qui suit :

Code :

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

1
2
    uint32_t hexatest = 47182592 // ← La même valeur mais écrite en décimal !
    uint32_t hexatest = 11519 * 256;

… tu aurais encore obtenu exactement la même chose en mémoire. La fonction sprintf(), parmi d'autres, convertit une valeur binaire issue de nulle part au format décimal canonique mais n'a aucun lien, là encore, avec sa forme originale dans le code source (et heureusement, sinon on ne pourrait jamais afficher les valeurs calculées a posteriori).

Ton problème n'est même pas lié au C en lui-même mais à la façon dont tu l'as conçu : si c'est la suite des chiffres hexadécimaux qui t'intéresse, alors il faut déclarer… une suite de chiffres !

Relis le dernier paragraphe de mon commentaire. Si tu déclares un entier pour le convertir ensuite en chaîne de caractère, rien ne t'empêche de déclarer directement une chaîne de caractères :

Code :

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

1
2
3
4
5
6
    long unsigned int i;
    char const chaine[] = "02CFF300";
 
    printf ("Longueur totale : %lu\n",(sizeof chaine)-1);
 
    for (i=0;i<(sizeof chaine)-1;i++) printf ("chaine[%lu] = \"%c\"\n",i,chaine[i]);

[Pete_Rebeat]

Tu peux parser la chaîne avec la fonction strtol() ou strtoul() pour la reconvertir en nombre.

Merci beaucoup, je vais effectivement passer tout en chaîne et adopter la démarche inverse du coup!

Ce n'est pas la fonction qui interprète le chiffre de cette façon : c'est le fait que tu aies utilisé « uint32_t ».

Le C n'est pas un langage symbolique comme peuvent l'être certains langages interprétés comme le shell, le Perl ou le PHP. C'est le compilateur qui fait le travail a priori. Tu déclares un entier 32 bits qui vaut 0x02CFF300. Il génère donc « 00000010 11001111 11110011 00000000 » sur exactement quatre octets et inscrit cela en l'état directement dans ton exécutable. Lorsque ton programme est lancé, il dispose de cette valeur au format que tu as spécifié mais ne sait absolument pas comment il a été défini.

Ok tout est tres clair maintenant, en fait ce que je voulais faire fonctionne beaucoup mieux dans l'autre sens en effet. Merci pour ces explications.

Ah oui j'ai oublié mais tu peux pour sprintf spécifié le format , par exemple

Code :

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

int longueur = sprintf(chaine,"%.8x",hexatest);

Bon même si du coup je ne vais plus avoir besoin de ça, assez curieusement les flags supplémentaires ne fonctionnent pas dans mon code ('.8'). Mon tableau chaine n'est pas rempli et la fonction me retourne -1. Bizarre.