Utiliser le code ASCII pour extraire deux valeurs.
Bonjour à tous
J'aurais besoin de créer un caractère dont le code ASCII décimal irait de 11 à 99. La création se ferait par l'ajout de 2 chiffres: le premier pour la dizaine et le second pour l'unité.
Code:
1
2
3
4
5
6
7
8
|
char carte, relais, codeAscii;
int code;
//example:
carte='1'; relais='8';
code = (int(carte)-48)*10 + int(relais)-48;
codeAscii= char(code); |
puis pour extraire les données ainsi codées:
Code:
1
2
3
|
int laCarte = int(codeAscii)/10;
int leRelais = codeAscii - laCarte*10; |
Cela ne semble pas fonctionner.
Si quelqu'un(e) a une idée. Merci
Modèle Vue Contrôleur, what else ?
Bonjour,
Que cela fonctionne est très bien mais il y a une erreur de conception qui amène des gymnastiques qui limiteront maintenance et évolution. La communication (en ASCII) ne doit pas structurer les données (voir MVC).
Peu importe le format d'échange (ici la Vue est essentiellement le Moniteur et la liaison série), l'organisation des données (Modèle) n'y est pas liée. Par exemple, mais il y en a d'autres certainement meilleurs :
Code:
1
2
3
4
5
6
7
8
| typedef enum action_t {
actNone, actOn, actOff, actOnTemp, actOffTemp
};
typedef struct Prog_t {
action_t action;
uint8_t iCarte, iRelais, h, mn, actParam;
} |
On considère ici que la carte 0 désigne la carte de base. Les actions types sont dans une énumération qui permet d'utiliser un symbole signifiant. dans le programme (ma liste est bidon, juste pour illustration). Au total cela consomme 6 octets. En utilisant des champs binaires (ou explicitement v >> 4 et v & 0x0F) associant iCarte et iRelais, on pourrait gagner encore un octet.
La traduction (C) entre caractères (V) et enregistrement (M) a lieu à réception et non, comme dans le schéma d'origine, à chaque utilisation d'un enregistrements. Outre les gains de places et performances, cela permet de signifier, dès la réception, les erreurs détectées (par exemple 2 ordres consécutifs de collage du même relais).
Comme on le voit, cela amène à gérer séparément les échanges avec l'utilisateur et les traitements et stockage. Ce n'est pas juste pour faire joli, c'est plus fiable et plus évolutif. Il est possible de faire varier le dialogue Homme-machine en ne changeant que la traduction de ceux-ci sans altérer rien d'autre.
C'est déjà remarquable d'avoir un programme qui fonctionne. C'est une base pour l'améliorer, pas nécessairement avec plus de fonctionnalités, mais en repensant certains choix.
Ce qui m'a toujours fasciné est que le travail de réflexion préalable, parfois long et ardu, aboutisse souvent à un programme bien plus simple, efficace et lisible qu'une écriture directe qui doit être caviardée avec des astuces peu lisibles pour corriger le tir.
Salutations
