Float to string

[Biname]

ca bugge à partir de la 1ère instruction?

As-tu essayé en désactivant l'interruption Int/RB0 et le port ?SPI ?
Le temps nécessaire au calcul float peut perturber leur fonctionnement et bugger ????

Ne laisser qu'un sprint float et commenter le reste.
-----

[kevin8z]

Je ne peut pas voir puisque le mode debug dans ce ça n'est pas fonctionnel.

Je vais essayer en désactivant tout ça.

[kevin8z]

Même constat quand tout est désactivé.

[Biname]

Même constat quand tout est désactivé.

Il faudra penser au suicide

[kevin8z]

Oh que oui ça va faire 5 jours que je suis sur ce problème qui est un vrais casse-tête, impossible à résoudre...

Sinon je vais essayer avec le compilateur C18, mais la le problème et pour le fonctionnement de l'écran et encore je n'est pas essayer le sprintf avec celui-ci...

[paulfjujo]

bonjour,

Je n'utilise pas vraiment une de ces 2 versions......

Quelle est donc cette version ?
Avec une version soit-disant "debridee", il faudra t'attendre a ce genre de probleme
insolvable .Histoire vecue qui m'a fait vite revenir sur C18.

[indri]

Pourquoi tu n'utilise pas seulement des entiers? dans ton cas, si j'ai bien vu, tu n'as besoin que du dixieme!
Ayant déjà du faire ca (affiché qqch de décimal sur un ecran lcd) me suis pas cassé la tête avec la conversion en string et j'ai gardé un entier (valeur multiplié par 10 si je voulais une décimal) et j'ai affiché chiffre par chiffre en gérant aussi 'endroit où placé le "," ou "." (selection de chaque chiffre avec division et modulo d'une puissance de 10)
C'est long et peut-être barbare pour un informaticien, mais tu t'emmerde pas avec des float dans un µc 8bits!

[kevin8z]

Quelle est donc cette version ?

Une version non limité en taille de code, mais non officiel on va dire.

Oui ben je vais surement faire ça, je vais devoir utiliser des long au lieu des float et placé la virgule au bon endroit

[inoxxam]

[...] mais tu t'emmerde pas avec des float dans un µc 8bits!

Je dirais même dès que le microcontrôleur ne dispose pas de FPU, mieux vaut les éviter comme la peste, et de toutes façons il n'arrive que dans des cas très particuliers qu'on en ait réellement absolument besoin.

[kevin8z]

Bon,donc j'ai suivi vos conseils, pas utiliser de float, j'ai donc pris des long et mis la virgule au bon endroit et ça fonctionne.
Merci à vous de m'avoir aider.
Et voici le bout de programme fait à titre d'exemple si d'autre personne on le même problème que moi:

long test = 20000000; // affichage : 2000000.0
char txt [10];
txt [9] = '\0'; // indique fin chaîne de caractères

txt [0] = test / 10000000;
txt [1] = (test / 1000000) % 10;
txt [2] = (test / 100000) % 10;
txt [3] = (test / 10000) % 10;
txt [4] = (test / 1000) % 10;
txt [5] = (test / 100) % 10;
txt [6] = (test / 10) % 10;
txt [7] = '.';
txt [8] = test % 10;


txt [0] += 48; txt [4] += 48; //Conversion de tout les chiffre en ASCII
txt [1] += 48; txt [5] += 48;
txt [2] += 48; txt [6] += 48;
txt [3] += 48; txt [8] += 48;

[Biname]

Bon,donc j'ai suivi vos conseils, pas utiliser de float, j'ai donc pris des long et mis la virgule au bon endroit et ça fonctionne.
Merci à vous de m'avoir aider.
Et voici le bout de programme fait à titre d'exemple si d'autre personne on le même problème que moi:

long test = 20000000; // affichage : 2000000.0
char txt [10];
txt [9] = '\0'; // indique fin chaîne de caractères

txt [0] = test / 10000000;
txt [1] = (test / 1000000) % 10;
txt [2] = (test / 100000) % 10;
txt [3] = (test / 10000) % 10;
txt [4] = (test / 1000) % 10;
txt [5] = (test / 100) % 10;
txt [6] = (test / 10) % 10;
txt [7] = '.';
txt [8] = test % 10;


txt [0] += 48; txt [4] += 48; //Conversion de tout les chiffre en ASCII
txt [1] += 48; txt [5] += 48;
txt [2] += 48; txt [6] += 48;
txt [3] += 48; txt [8] += 48;

Pas vérifié mais il est raisonnable de penser que tu ne t'es pas trompé.
Les divisions de nombres entiers sont beaucoup plus rapides que les divisions de float mais elles sont quand même très lentes. On est pas en 64 bits sur un processeur multicore à 3GHz ... mais au moins 32000 fois plus lent (4MHz = 1 MIPS en 8 bits) !

Des routines doivent exister ?

' ----------------
int aInt = 368;
char str[15];
sprintf(str, "%d", aInt);
' ----------------

Sinon, soustraire n fois un millions pour compter les millions est beaucoup plus rapide (??10X au moins) que de prendre le résultat de la division par 10.

Je te laisse coder ...





Un bon exercice pour toi serait d'écrire une routine assembleur en 8 bits divisant un entier 32 bit par un entier 32 bits ... une galère pour toi et un boulot d'enfer pour le processeur !

[kevin8z]

Alors ce que j'ai fait fonctionne, j'ai vérifier sur mon LCD.
Oui c'est sur j'aurai pu soustraire n fois un million est après fait un modulo ce serait plus rapide. C'est surement ce que je vais faire.
Avec mikroC la fonction sprintf(), ne fonctionne pas non plus dans ce cas. J'ai une autre fonction LongToStr (), mais ça ne fonctionne pas non plus.
Après certes en assembleur ce serait beaucoup plus optimisé, mais je ne connais pas ce langage.

[kevin8z]

Si le calcul est fait comme ça, j'obtient un gain de temps *10:

txt [0] = test / 10000000;
txt [1] = ((test - 10000000) / 100000) % 10;
txt [2] = ((test - 11000000) / 10000) % 10;
txt [3] = ((test - 11100000) / 1000) % 10;
txt [4] = ((test - 11110000) / 100) % 10;
txt [5] = ((test - 11111000) / 10) % 10;
txt [6] = (test - 11111100) % 10;
txt [7] = '.';
txt [8] = (test - 11111110)  % 10;

[invite635643ae]

Bon,donc j'ai suivi vos conseils, pas utiliser de float, j'ai donc pris des long et mis la virgule au bon endroit et ça fonctionne.
Merci à vous de m'avoir aider.
Et voici le bout de programme fait à titre d'exemple si d'autre personne on le même problème que moi:

long test = 20000000; // affichage : 2000000.0
char txt [10];
txt [9] = '\0'; // indique fin chaîne de caractères

txt [0] = test / 10000000;
txt [1] = (test / 1000000) % 10;
txt [2] = (test / 100000) % 10;
txt [3] = (test / 10000) % 10;
txt [4] = (test / 1000) % 10;
txt [5] = (test / 100) % 10;
txt [6] = (test / 10) % 10;
txt [7] = '.';
txt [8] = test % 10;




txt [0] += 48; txt [4] += 48; //Conversion de tout les chiffre en ASCII
txt [1] += 48; txt [5] += 48;
txt [2] += 48; txt [6] += 48;
txt [3] += 48; txt [8] += 48;

Super, ca devrait marcher,


Par contre, dans un de mes programmes, j'ai décomposé un entier pour sortir une valeur float sans utiliser de float mais après pour comparer ca avec une valeur de référence, j'ai un peu galérer,

par exemple, supposons que tu ai 200000.5 que tu veuille que lorsque cette valeur dépasse (au hasard) 210000.3, On déclenche une sortie, comment tu ferais pour effectuer la comparaison puisque il ne s'agit pas d'un vrai float en tant que tel qu'il faudrait comparer toute la boucle de txt[]! !

[kevin8z]

Je multiplie les 2 nombres par 10 et je l'ai compare. Je pense que c'est une DES solutions

Question à par: pour organiser mieux mon programme j'ai créer plusieurs feuilles .c
Je déclare une variable global dans la feuille GBF.c ( c'est mon main.c en faite) et un #define SELEC PORTC.RC0
Le problème est que par exemple dans ma feuille FREQUENCE.c j'utilise cette variable et ce SELEC, mais il me créer une erreur à la compilation me disant que c'est 2 choses ne sont pas déclarer. Comment faire?

[invite635643ae]

mais ton nombre est décomposé en 8 unités, le resultat que tu auras en multipliant par 10 ne sera pas du tout cohérent?

[invite635643ae]

enfin si ce sont des vrai float, en utilisant la convertion floattostring la aucun probleme, ca marcherait mais en utilisant la décomposition comment faire un test d'égalité, quelqu'un a une idée

[kevin8z]

Si je veut faire ça, je récupère ma chaîne de caractère sans la virgule, donc j'aurai mon nombre * 10, au lieu d'avoir 2000000,5 j'aurai 20000005, et je le compare à 21000003. Non?

[invite635643ae]

je sais pas trop faudrait essayer mais ca pourrait peut etre marcher sans certitude, et ca fait perdre du temps au microcontroleur donc evidemment programme encoire moins optimisé

[Biname]

Si le calcul est fait comme ça, j'obtient un gain de temps *10:

txt [0] = test / 10000000;
txt [1] = ((test - 10000000) / 100000) % 10;
txt [2] = ((test - 11000000) / 10000) % 10;
txt [3] = ((test - 11100000) / 1000) % 10;
txt [4] = ((test - 11110000) / 100) % 10;
txt [5] = ((test - 11111000) / 10) % 10;
txt [6] = (test - 11111100) % 10;
txt [7] = '.';
txt [8] = (test - 11111110)  % 10;

int test;
char txt[9];

While (Test > 1000000) {
txt[0] += 1;
Test = Test - 1000000;
}


While (test > 100000) {
txt[1] += 1;
test = test - 100000;
}

et ainsi de suite

A fignoler, pas très habile en C moi.

[Jack]

Mets ce qui est global dans un fichier d'entête, par exemple global.h et dans tes fichiers .c qui ont besoin de ces déclarations tu mets
#include "global.h"

Pour éviter les inclusions multiples, commence global.h par
#ifndef _GLOBAL_
#define _GLOBAL_
et termine le fichier par
#endif

[kevin8z]

int test;
char txt[9];

While (Test > 1000000) {
txt[0] += 1;
Test = Test - 1000000;
}


While (test > 100000) {
txt[1] += 1;
test = test - 100000;
}

Le problème avec cette méthode et qu'a la fin la variable test sera égale à 0. Au pire je peut créer une variable TestBuffer... A voir si j'en est vraiment l'utilité. Mais je vais y réfléchir.

Jack: Pour ma variable global, j'ai utiliser extern dans mes fichiers .c, et redeclarer mon #define dans chaque fichier. Je vais voir la méthode proposer.

[kevin8z]

Alors encore un nouveau problème, je pense que je vais changer de compilateur car la ça m'étonnerai que le problème viens d'ailleurs. Lorsque je met cette condition dans mon programme, et ben... Il plante.

 if ((appui == 1) && (modulo <= 8000000)){
         
            freq += 1000000;
         
         }

Appui et un static unsigned char
modulo est un static unsigned long

La je ne pense vraiment pas avoir fait d'erreur et que le problème n'est pas en cause avec le compilo.

Si quelqu'un sait m'expliquer pourquoi, ce serait sympa.

[invite635643ae]

Alors je suis sur mikroc et pour info parfois j'écris du code vraiment tres correct sans erreur et ca arrive tres tres souvent qu'il ne veule pas compiler!! donc le compilo a pas mal de beug ca confirme mon hypothese

[kevin8z]

Ok merci, bon ben je vais définitivement passer au compilateur de microchip. Au moins je n'aurai plus besoin de me prendre la tête à chercher des erreurs qui en fait vienne du compilateur.