Discussion :

[MarcO_-]

Bonjour a tous,
Je programme en ce moment un PIC18F877.
Je dois acquerir une chaine de caracteres en HEXA, puis l'afficher sur un LCD
Cependant, j'ai qques problemes avec la conversion.
Voici le programme que j'ai fait;

char conversion(char y)
{
for(y=0x00;y<=0x09;)
{
y = y+0x30;
}
for(y=0x0A;y<=0x0F;)
{
y = y+0x37;
}
return y;
}

Je lui envoie une tableau,je fais tourner cette sous fonction avec une boucle for et il me renvoie "AAAAAAAA" (par RS232)
Extrait de ma boucle a la con:

for(x=7;x<16;x++)
{
tabconv[x] = conversion(tab[x]);

}

Je ne comprend pas mon erreur,
Je sais qu'il y en a une mais je ne la comprend pas.
A l'avance merci de votre aide.

[Sanguko]

Bonjour a tous,
for(y=0x00;y<=0x09
{
y = y+0x30;
}
for(y=0x0A;y<=0x0F
{
y = y+0x37;
}

A mon avis, c'est plutot

Code :

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

1
2
3
4
5
6
7
8
9
 
if(y>=0x00 && y<=0x09)
{
  y = y+0x30;
}
else if(y>=0x0A && y<=0x0F;)
{
  y = y+0x37;
}

[JeitEmgie]

Bonjour a tous,
Je programme en ce moment un PIC18F877.
Je dois acquerir une chaine de caracteres en HEXA, puis l'afficher sur un LCD
Cependant, j'ai qques problemes avec la conversion.
Voici le programme que j'ai fait;


Je lui envoie une tableau,je fais tourner cette sous fonction avec une boucle for et il me renvoie "AAAAAAAA" (par RS232)
Extrait de ma boucle a la con:


Je ne comprend pas mon erreur,
Je sais qu'il y en a une mais je ne la comprend pas.
A l'avance merci de votre aide.

Code :

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

1
2
3
4
5
6
7
8
9
 
// from i int [0:15] to c char : hex representation of i
char conversion(int i)
{
static char *hexchars = "0123456789ABCDEF" ;
 
    assert((i>=0) && (i<16));
    return hexchars[i];
}

[Emmanuel Delahaye]

Code :

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

1
2
3
4
5
6
7
8
9
 
// from i int [0:15] to c char : hex representation of i
char conversion(int i)
{
static char *hexchars = "0123456789ABCDEF" ;
 
    assert((i>=0) && (i<16));
    return hexchars[i];
}

Pas mal. Attention, assert() n'est pas compilé en mode Release... J'aurais mis

Code :

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

1
2
3
 
/* /!\ N'est pas une chaine valide */
static char const hexchars[16] = "0123456789ABCDEF" ;

Ca prend moins de place (important en embarqué, surtout PIC où chaque byte compte).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
int conversion (size_t i)
{
   int c = -1;
   /* /!\ N'est pas une chaine valide */
   static char const hexchars[16] = "0123456789ABCDEF" ; 
 
   if (i < 16)
   {
      c = hexchars[i];
   }
   return c;
}

http://emmanuel-delahaye.developpez....tes.htm#size_t

[MarcO_-]

Merci a tous!
Ca marche!

[JeitEmgie]

Code :

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

1
2
 
int conversion (size_t i)

size_t est normalement utilisé pour exprimé "la taille" de quelque chose…
ici c'est plutôt "unsigned" qui exprimerait le mieux le type de paramètre que l'on attend…

et quitte à être strict, c'est un char que l'on renvoit par un int…

Code :

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

1
2
 
char conversion (unsigned i)

car en supposant que l'on puisse renvoyer -1 vous obligez un test côté appelant… (vous pourriez plutôt renvoyer '\0' … ce qui "terminera" proprement la chaîne accumulée par l'appelant au premier paramètre out of range…)

et en tenant compte du contexte embarqué on pourrait même "pousser le bouchon" jusqu'à écrire :

Code :

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

1
2
3
4
5
6
7
 
char conversion (unsigned i)
{
   static char const hexchars[16] = "0123456789ABCDEF" ; 
 
   return hexchars[i % 16];
}

à l'utilisateur de voir ce qui lui convient le mieux…

[Emmanuel Delahaye]

size_t est normalement utilisé pour exprimé "la taille" de quelque chose…
ici c'est plutôt "unsigned" qui exprimerait le mieux le type de paramètre que l'on attend…

Ici, OK. Mais d'une manière générale, un size_t est le bon type pour un indice (ici, i est un indice...)

et quitte à être strict, c'est un char que l'on renvoit par un int…

Euh, renvoyer un char ? jamais vu ça. C'est techniquement possible, mais dans la pratique on ne le fait pas, car ça génère du code inutilement complexe. Rien de tel dans la bibliothèque C, par exemple...

Code :

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

1
2
 
char conversion (unsigned i)

car en supposant que l'on puisse renvoyer -1 vous obligez un test côté appelant… (vous pourriez plutôt renvoyer '\0' … ce qui "terminera" proprement la chaîne accumulée par l'appelant au premier paramètre out of range…)

Je préfère une valeur volontairement hors gamme et testable. Ce n'est pas un hasard si getchar(), par exemple, renvoi un int...

et en tenant compte du contexte embarqué on pourrait même "pousser le bouchon" jusqu'à écrire :

Code :

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

1
2
3
4
5
6
7
 
char conversion (unsigned i)
{
   static char const hexchars[16] = "0123456789ABCDEF" ; 
 
   return hexchars[i % 16];
}

à l'utilisateur de voir ce qui lui convient le mieux…

La correction d'erreur silencieuse n'est pas le meilleur moyen de rendre son code fiable...

[JeitEmgie]

Euh, renvoyer un char ? jamais vu ça. C'est techniquement possible, mais dans la pratique on ne le fait pas, car ça génère du code inutilement complexe. Rien de tel dans la bibliothèque C, par exemple...

ben voyons :
étant donné que l'on assigne le résultat extrait d'un tableau de char à des éléments d'un autre tableau de char, autant renvoyé un char… de toute façon le compilateur va arranger cela à sa sauce en fonction du CPU cible…

mais la vraie bonne façon d'être efficace ici est évidemment de ne pas faire une fonction pour si peu !

Je préfère une valeur volontairement hors gamme et testable. Ce n'est pas un hasard si getchar(), par exemple, renvoi un int...

avec getchar() (toutes les fonctions du genre) c'est parce que on a besoin de tester EOF ((int)-1) et que l'on ne veut pas s'emmêler les pinceaux avec l'extension de signe du caractère ASCII 255…

La correction d'erreur silencieuse n'est pas le meilleur moyen de rendre son code fiable...

certes,
mais dans le contexte embedded ici décrit c'est l'utilisateur qui sait à quel niveau il doit placer les checks de validité des données qu'il manipule…
et en général quand on programme ce genre d'application, on évite de mettre ces tests dans les feuilles de l'arbre d'appels des fonctions parce que cela complique le code et que l'on n'a pas nécessairement la place en ROM pour faire ce que l'on ferait dans une application "desktop"…

(et mettre une chaîne "0123456789ABCDEF" dans une static d'une sous-routine alors qu'il y 9 chances sur 10 qu'on en aura besoin ailleurs n'est pas non plus quelque chose que je laisserais ainsi pour du code "embedded"…)

mais,
il faudrait peut-être aussi le laisser faire ses devoirs tout seul comme un grand, non ?