Comment récupérer des erreurs pour les traiter ?

[JuanLuis]

Bonjour à tous !

Dans le cadre d'un projet je dois concevoir une architecture d'une couche logicielle (dite "couche d'abstraction matériel"). Elle doit faire un lien entre un code fonctionnel et les drivers utilisant le matériel.

Je suis en ce moment en train de me pencher sur la gestion des erreurs.
Les pilotes des liaisons peuvent en générer, mais ils ne renvoient pas forcément tous les même types de données. Certains vont renvoyer un booléen, d'autres vont renvoyer des "char" , ainsi de suite...
Ce que je cherche à faire est donc une fonction, qui pourra gérer tous ces retour d'erreurs.

Pour être plus précis, première question, est ce que je peux faire ça ?? :

Code C :

1
2
3
4
5
 
float ma_variable ;
char ma_fonction_diver(uint8 adresse, uint8 data); //Prototype de ma_fonction_driver
ma_variable=ma_fonction_driver(adresse,data);
ma_gestion_derreur(ma_variable);

j'y crois pas trop parce que j'assigne un "char" à un float ?! Dite moi ce que vous en pensez svp !!
Si j'ai le droit e faire ça, c'est gagné!!! je pourrai prendre n'importe quel erreur pour ensuite pouvoir travailler dessus. Mais du coup ça me parait trop simple...
Je suis ouvert à toutes vos remarques et idées !

Merci de m'avoir lut ! JL

[Bktero]

Je regarde dans la norme C99 à la partie sur les conversions de type (6.3).

Dans la partie 6.3.1.4 Real floating and integer, tu liras au point 2 :

When a value of integer type is converted to a real floating type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an implementation-defined manner. If the value being converted is outside the range of values that can be represented, the behavior is undefined.

Si ton compilateur suit la norme C, ton char devrait être donc inchangé dans un float, d'après ce que je comprends.

[JuanLuis]

Merci pour la réponse. Mais du coup rien de sur quoi !!
Le truc c'est que là j'ai traiter pour un char en retour, mais ptet que je vais avoir un int, ou un double, ou plein d'autre chose.
Comment faire pour récupérer une variable de n'importe quel type dans une variable d'un type précis ??

[Bktero]

C'est sûr si ton compilateur respecte la norme. As-tu lu la partie de la norme que je t'indique ? Elle pourra t'aider à comprendre les mécanismes de conversion et à choisir le type qui va bien.

De prime abord, je pense qu'en prenant un double, tu dois pouvoir y stocker tous les autres types sans perte (tu n'as quand même pas de long double en code d'erreur ?)

[JuanLuis]

En fait je travaille sur un projet existant, ma nouvelle couche doit s'intégrer au projet. Pour ensuite pouvoir être extraite et réutiliser dans différent projets.
Et j'ai regarder, mais du coup moi j'utilise le compilateur C18.
Comment je peut trouver le document qui m'indiquera les normes pour ce compilateur?

Envoyé par Bktero

De prime abord, je pense qu'en prenant un double, tu dois pouvoir y stocker tous les autres types sans perte (tu n'as quand même pas de long double en code d'erreur ?)

Non je ne vais pas avoir de long double !!!! En gros je pense toujours retrouver les int, bool, char et les long, le tout en signé et non-signé. Du coup si je met n'importe lequel dans un double (est ce que double = long ?? ) je devrait pouvoir récupérer mes billes après pour les traiter !

Et en fait je viens de penser à ça ! Si j'ai une fonction qui me renvoi rien (void), est ce que je peux écrire :

Code C :

1
2
3
void ma_fonction_driver(int data); //proto de la fonction
double ma_variable;
ma_variable=ma_fonction_driver(data);

le compilateur ne vas pas me hurler dessus à la compilation ??? je pense que si ! :/

[Bktero]

Je me souviens que la documentation de C18 te donne la liste des différences entre ce qu'il fait et ce que demande la norme ISO. Voir ici :
http://www.microchip.com/stellent/id...cName=en010014

Document : MPLAB C18 C Compiler User's Guide and Release Notes

Partie : Appendix B. ANSI Implementation-defined Behavior


Oui, le compilo va hurler. Tu peux utiliser une zone que tu alloues comme nécessaire, et tu y accèdes avec un pointeur void*. Il suffit au moment de la lecture de savoir le type de données à lire pour caster void* en type*.

[JuanLuis]

Okay okay!! bon je vais lire tous ça!! Ça va surement m'apporter un peu de réponses !
Par contre je comprend pas quand tu parles d'accéder à une zone mémoire avec le pointeur void??
Pourrai tu me faire un mini exemple s'il te plait!? merci d'avance !!!

[Bktero]

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
void f_ints(void* data)
{
    * (int*)data = 42;
    * ((int*)data + 1)  = 43;
}

void f_double(void* data)
{
    *((double*)data) = 3.14;
}

int main(void)
{
    void * data = malloc( 10 * sizeof(double) );

    f_ints(data);
    printf("%d %d\n", * (int*)data, * (int*)data+1 );

    f_double(data);
    printf("%f\n", * (double*)data);

    return 0;
}

J'utilise une zone pointée par un void*, cad un pointeur générique. Je peux ainsi écrire le type de données que je souhaite dans cette zone, à condition que je sois sûr de ne pas dépasser la zone allouée. Pour lire cette zone, il faut par contre connaitre le type des données stockées pour correctement les interpréter.

[JuanLuis]

Okay merci pour l'exemple !!

Est ce que cela veut dire que je peux faire cela :

Code C :

1
2
3
4
5
6
 
 
void * ma_variable= malloc( 10 * sizeof(double) );  //je déclare ma variable d'erreur
char ma_fonction_diver(uint8 adresse, uint8 data); //Prototype de ma_fonction_driver
ma_variable=ma_fonction_driver(adresse,data); //j'appel ma fonction qui retourne quelque chose à ma_variable
return ma_gestion_derreur(&ma_variable); //j'appel la gestion d'erreur qui retourne un beau code erreur exploitable par l'applicatif!

[Bktero]

Non, tu es bien obligé de caster le pointeur void* pour y mettre des choses. De plus, tu veux modifier le contenu du pointeur et non le pointeur lui-même.

Code :

1
2
3
4
5
6
void * ma_variable= malloc( 10 * sizeof(double) );  //ok
char ma_fonction_diver(uint8 adresse, uint8 data); //ok

ma_variable=ma_fonction_driver(adresse,data); // ici, il faut caster et modifier ce qui est pointé et non le pointeur

return ma_gestion_derreur(&ma_variable); // oui, mais le & n'est pas nécessaire

Tu cherches en fait à entourer les appels aux fonctions de la couche basse par mécanismes d'uniformisation pour renvoyer des codes d'un seul type à la couche haute ?
J'ai essayé de faire un bout de code dans le genre. C'est la première idée qui m'est venu en voyant ton dernier extrait de code. Je ne sais pas si c'est une bonne idée, mais ça pourrait peut-être t'aider

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <stdbool.h>

char driver_char(void)
{
    return 110;
}

double driver_double(void)
{
    return 3.14;
}

bool gestion_erreur(void* code, char data_type)
{
    switch(data_type)
    {
    case 'c':
        if (* (char*)code == 110)
            return false;
        else
            return true;

    case 'd':
        if (* (double*)code == 3.14)
            return true;
        else
            return false;
    default:
        return false;
    }
}

int main(void)
{
    void * code_retour = malloc( 10 * sizeof(double) ); // bon.... 10 ce n'est surement pas necessaire pour stocker un nombre ^^

    * (char*)code_retour = driver_char();
    bool un = gestion_erreur(code_retour, 'c');

    * (double*)code_retour = driver_double();
    bool deux = gestion_erreur(code_retour, 'd');

    printf("Un = %s\n"
           "Deux = %s", un ? "True" : "False", deux ? "True" : "False");

    return 0;
}

[JuanLuis]

Merci bcp pour l'exemple!
Je trouve ça pas mal comme solution, ça va pouvoir s'adapter je pense a mon projet.
Cela me permet d'avoir une fonction de gestion d'erreur qui peut prendre n'importe quel type en entrée. C'est juste dommage que je dois appliquer un cast dans le main, mais je ne vais pas avoir le choix!
merci encore pour l'aide.
si tu as d'autre idées, je t'en prie, fait toi plaisir !!!!!

[Bktero]

Ah oui avec les void*, le cast est obligatoire. Tu peux le cacher, avec une macro :

Code :

1
2
3
4
5
6
7
    #define OBTENIR_CODE(fonction, type) ( * (type*)code_retour = fonction )

    ...

    //* (double*)code_retour = driver_double();
    // devient
    OBTENIR_CODE(driver_double(), double);

ou encore :

Code :

1
2
3
4
5
6
   #define CODE_TYPE(type) ( * (type*)code_retour )

    ...

    //* (char*)code_retour = driver_char();
    CODE_TYPE(char) = driver_char();

Tu peux aussi inclure le nom de la variable avec dans la macro pour quelle soit plus générique :

Code :

1
2
#define CODE(variable, type) ( * (type*)variable )
CODE(code_retour, char) = driver_char();

J'espère que la solution sera aussi bonne une fois testée qu'elle n'en a l'air de prime abord. Tu me diras ce que ça a donné, ça m'intéresse !

[JuanLuis]

Merci encore pour le temps passé sur mon sujet!
Je ne connaissais pas c'est mécanisme de macro, enfin le fait d'inclure une fonction dans la macro !! C'est cool ça!! ça peut permettre un sacré allègement du code dans certain cas!!
Pour l'instant je suis dans la phase de conception de ma couche d'abstraction qui doit se terminer fin aout. Je dois mettre tout au point sur papier pour ensuite passer au développement et du coup avoir un minimum de debug à faire.
Du coup le développement ne viendra pas avant le mois d'octobre, car je vais être mis avant sur un autre projet pendant septembre, mais no problem je te donnerai un suivis de cette méthode! C'est la moindre des choses ^^
Merci encore!

[Bktero]

Tu fais ce que tu veux avec une macro

Un ami m'a montré des macros utilisées dans le noyau Linux pour faire un for sur les éléments d'une liste chaine. Et du coup, dans le code, tu as un truc du genre :

Code :

1
2
for_each_in(ma_list_chaine)
{ /* .... /*}

!

Ton pré-processeur remplace juste la macro par ce que tu lui demandes, avant la compilation. Tu peux faire ce que tu veux, je le répète
D'ailleurs, il y a une option de gcc pour voir le code tel qu'il est après le passage du pré-processeur : http://gcc.gnu.org/onlinedocs/gcc/Pr...r-Options.html Je n'ai jamais essayé, mais ça peut-être intéressant de regarder un jour comme nos macros sont remplacées.

PS : je crois que la possibilité de mettre plusieurs paramètres à une macro est une possibilité du C99 et non du C89/90. A voir si C18 est OK de le faire aussi.

[3DArchi]

Salut,
je pense qu'il s'agit d'une très très mauvaise idée de passer des entiers sur des float/double/long double. Je ne connais aucun système qui gère ses erreurs sur des réels.
La manipulation des nombres réels devrait supposer une analyse numérique pour mesurer la propagation des erreurs de calculs.

Pour reprendre la norme citée plus haut, je souligne :

if the value being converted can be represented exactly in the new type

La conversion la plus intéressant de différents types d'entier représentant des codes d'erreur est probablement vers un unsigned long

[Bktero]

Euh.... Oui je pense qu'on est tous d'accord pour dire que les conversions de types posent beaucoup de problèmes, surtout pour mettre des flottants dans des entiers ou l'inverse. Si tous les codes sont entiers, on peut éventuellement tout mettre dans un unsigned long mais quid des nombres négatifs ? Pour ça que la technique du void*, bien que lourde, permet de vraiment conserver le code retour. La bonne technique serait de mettre des normes de développement sur le projet pour que les retours soient uniformisées pour toutes les fonctions.

[3DArchi]

Envoyé par Bktero

Si tous les codes sont entiers, on peut éventuellement tout mettre dans un unsigned long mais quid des nombres négatifs ?

En pratique, les conversions signed [char|short|long] -> unsigned long -> signed [char|short|long]se feront sans perte. S'il veut effacer les différents types d'erreur des couches en dessous, ça me semble assez raisonnable comme choix de type d'erreur.

Envoyé par Bktero

Pour ça que la technique du void*, bien que lourde, permet de vraiment conserver le code retour.

En embarqué, souvent les malloc/free sont interdits. Et si autorisés, ils sont diablement inefficaces en terme de mémoire consommée et en terme de temps d'exécution. Et puis cela suppose de transporter le type effectif qui se cache derrière le void*. Car si on alloue pour un char et qu'on déréférence un long =>

[Bktero]

Le code suivant me donne les warnings indiqués (avec MinGW) :

Code :

1
2
3
4
    signed long a = LONG_MIN;
    unsigned long b = a;
    signed long c = b;
    printf("a =%ld b = %ld c = %ld",a,b,c);

warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result|
warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result|

Alors que pourtant, il m'affiche quelque chose de correct. Pour me mettre des warnings alors que les conversion se passent bien ?

En embarqué, souvent les malloc/free sont interdits.

C'est contournable avec une allocation statique, non ?

Car si on alloue pour un char et qu'on déréférence un long =>

Oui et c'est pareil si tu mets ton doigt dans la prise électrique.

[3DArchi]

Envoyé par Bktero

Le code suivant me donne les warnings indiqués (avec MinGW) :

Code :

Alors que pourtant, il m'affiche quelque chose de correct. Pour me mettre des warnings alors que les conversion se passent bien ?

C'est %lu pour b : printf("a =%ld b = %lu c = %ld",a,b,c);. Ce qui produit bien :

a =-2147483648 b = 2147483648 c = -2147483648

Qui change bien le signe d'une conversion à l'autre ... Trop fort ce compilo

Envoyé par Bktero

C'est contournable avec une allocation statique, non ?

Ca reste très très lourd.

Envoyé par Bktero

Oui et c'est pareil si tu mets ton doigt dans la prise électrique.

Ce que je veux dire, c'est que ça implique de trimbaler l'information de type. A ce moment autant partir sur une solution de type :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
typedef struct{
    enum{
        E_u8,
        E_s8,
        E_u16,
        E_s16,
        E_u32,
        E_s32
    } type;
    union{
        uint8_t u8;
        int8_t i8;
        uint16_t u16;
        int16_t i16;
        uint32_t u32;
        int32_t i32;
    } error;
} error_t;

C'est beaucoup plus explicite, ça ne nécessite pas de conversion risquée et ça se trimbale très bien sur la pile au besoin.

[JuanLuis]

Salut !
Cooooll !!! Je reviens faire un tour sur DVP, et je vois que mon sujet s'enrichit
Merci pour les messages, j'en apprend beaucoup!

Envoyé par 3DArchi

Ce que je veux dire, c'est que ça implique de trimbaler l'information de type. A ce moment autant partir sur une solution de type :

Code C :

C'est beaucoup plus explicite, ça ne nécessite pas de conversion risquée et ça se trimbale très bien sur la pile au besoin.

Je ne comprend pas ce que tu veux faire avec l'enum, et l'union là ???
Je ne connais pas très bien c'est mécanisme, je vais aller lire quelques trucs la dessus. Mais je veux bien que tu m'explique l'idée please !!

Je pense que oui je vais devoirs limiter les types de retours des drivers a quelqu'un sinon ça sera ingérable.
Comme j'ai déjà dit, le but est de simplifier le travail dans les projets futur, en cas de changement de matériel avoir le moins de changement possible dans toutes mes couches logiciel.
Et donc si mon driver que je viens de changer renvoi un int alors que celui d'avant renvoyait un bool, bah j'aimerai que ça le gère de façon invisible !!

merci encore pour les pistes en tous cas!!!