Discussion :

[Grokiff]

Bonjour,

J'ai un choix à faire concernant la façon de coder un bout de programme et j'aimerai avoir des avis extérieurs :
Je travaille sur microcontrôleur en C.
J'ai une partie de configuration du microcontrôleur en EEPROM.
J'ai donc créé une structure qui contient la page de configuration :

Code :

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

1
2
3
4
5
6
7
8
Typedef struct
{
unsigned int Param1;
float Param2;
unsigned char Param3;
[...]
char Paramx[SIZE];
} T_EEPROM;

Considérons que cette structure est lourde compte tenu de l'espace mémoire du microcontrôleur.

Cette structure est instanciée par une variable globale :

Code :

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

T_EEPROM MaConfig;

Cela me permet de mettre à jour l'EEPROM par exemple :

Code :

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

1
2
MaConfig.Param1 = NewValue;
WriteEEPROM(MaConfig);

Maintenant je souhaite pouvoir initialiser cette structure avec différentes configurations d'usine (Config A, config B, etc...)
Tous les paramètres de chaque type de configuration sera fixe et peuvent donc être défini par des #define

C'est là que j'hésite sur la bonne méthode :

1) écrire une fonction d'initialisation qui prend tous les champs en paramètre et initialise les champs dans le corps de la fonction :

Code :

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

1
2
3
4
5
6
7
8
bool InitEEPROM(unsigned int param1, float param2, unsigned char param3, [...], char *Paramx)
{
MaConfig.Param1 = param1;
MaConfig.Param2 = param2;
MaConfig.Param3 = param3;
[...]
MaConfig.Paramx = paramx;
}

En appelant la fonction à chaque fois avec le type de conf voulu :

Code :

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

1
2
3
4
5
6
7
8
9
void InitFactoryEEPROM (unsigned char type)
{
if (type == 1)
InitEEPROM(DEFINE_PARAM1_CONFIG_1, DEFINE_PARAM2_CONFIG_1,DEFINE_PARAM3_CONFIG_1, [...], DEFINE_PARAMx_CONFIG_1);
else if (type == 2)
InitEEPROM(DEFINE_PARAM1_CONFIG_2, DEFINE_PARAM2_CONFIG_2,DEFINE_PARAM3_CONFIG_2, [...], DEFINE_PARAMx_CONFIG_2);
else if (type == 3)
[...]
}

Inconvénient : Je trouve très lourd en code et moche

2) Créer un gros tableau de structure comme ceci :

Code :

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

1
2
3
4
5
6
T_EEPROM FactoryEepromConfig[CONFIG_COUNT] =
{
{DEFINE_PARAM1_CONFIG_1, DEFINE_PARAM2_CONFIG_1, DEFINE_PARAM3_CONFIG_1, [...], DEFINE_PARAMx_CONFIG_1},
{DEFINE_PARAM1_CONFIG_2, DEFINE_PARAM2_CONFIG_2,DEFINE_PARAM3_CONFIG_2, [...], DEFINE_PARAMx_CONFIG_2},
[...]
};

Avec une fonction d'init plus simple :

Code :

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

1
2
3
4
5
6
7
8
bool InitEEPROM(T_EEPROM factoryConfig)
{
MaConfig.Param1 = factoryConfig.Param1 ;
MaConfig.Param2 = factoryConfig.Param2;
MaConfig.Param3 = factoryConfig.Param3;
[...]
MaConfig.Paramx = factoryConfig.Paramx;
}

Et un appel à la fonction :

Code :

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

1
2
3
4
void InitFactoryEEPROM (unsigned char type)
{
InitEEPROM(FactoryEepromConfig[type]);
}

Inconvénient :
Très très lourd en RAM puisque je crée un tableau de structure avec autant de structure que de configurations...

Est ce que quelqu'un aurait une idée ?

Merci d'avance pour votre aide

Baptiste

[Vincent PETIT]

Salut,
J'ai ne suis pas sur d'avoir tout compris mais je vais prendre un cas que je rencontrais souvent.

- Une carte électronique avec différentes configurations logiciels.
- Toutes les configurations étaient dans l'EEPROM à des adresses évidemment différentes.
- Le choix de telle ou telle configuration était déterminé par le hardware (point de programmation, une dépose particulière de composant, par dipswitch, ou autre)

Jusque là, je pense qu'on parle du même genre de problème a gérer ?

Moi je faisais une chose très simple avec mon micro :

Code :

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

1
2
3
4
- Créer un tableau en RAM pouvant contenir une seule config
- Aller lire le hard pour savoir quelle config choisir
- Me rendre à la bonne adresse dans l'EEPROM
- Charger en RAM uniquement la config de l'EEPROM

Il n'est pas utile de charger toutes les configurations dans l'EEPROM pour en choisir qu'une seule à la fin. Autant aller au bon endroit dans l'EEPROM et charger uniquement la bonne config. Quand j'écris Aller lire le hard pour savoir quelle config choisir ça peut être lire une tension analogique, exemple :

entre 3.3V et 3V = config 1,
entre 2.5V et 2V = config 2,
entre 1.5V et 1V = config 3.

Tu vois le principe ?

Si le choix de la configuration se fait pendant la compilation (ce qui me semblerait curieux mais bon ) Tu peux très bien mettre en place un #define et des conditions #if, #ifdef pour mettre en place une règle du préprocesseur simple :

Code C :

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

1
2
3
4
#ifdef CONFIG1
ADRR_CONF 0x0000
#ifdef CONFIG2
ADRR_CONF 0x0100

Et ta structure vient charger la config se trouvant à l'adresse ADRR_CONF de l'EEPROM suivant que tu as déclaré un #define CONFIG1 ou #define CONFIG2

[Grokiff]

Bonjour,
Mon problème est inverse, je dois écrire en EEPROM une configuration qui est choisie par l'utilisateur.

[Vincent PETIT]

D'accord mais dans ce cas je ne comprends pas le problème.

Comment l'utilisateur fait pour définir une configuration ? Pas via la compilation quand même ? L'utilisateur n'a pas les sources ?

[Grokiff]

L'utilisateur choisit une configuration via un terminal et le port série

[Vincent PETIT]

Ok et l'utilisateur peut envoyer plusieurs configurations différentes dans le micro via le port série ?

Comment ça se fait qu'il puisse faire ça ? L'intérêt ?

Ces configurations vont où ? Dans l'EEPROM direct ?

Lorsque le micro démarre, comment il sait quelle configuration il doit lancer ?

En réalité je ne pige pas comment tu peux en arriver à envisager des solutions comme dans ton premier post ? Je pense que c'est très clair pour toi car c'est ton projet mais pour moi ça l'est beaucoup moins. Tu peux réexpliquer différemment ?

A+

[Grokiff]

En fait,
La page de configuration en EEPROM peut contenir la configuration d'une centaine de capteurs météorologiques
Pour chaque capteur il y a 18 paramètres qui représentent une centaine d'octets (polynôme, seuils, identifiant, entrée de la carte utilisée, type de signal électrique etc).
Actuellement via le terminal et un port série, l'utilisateur peut ajouter des capteurs. La méthode est très fastidieuse puisqu'il doit renseigner les valeurs de chacun des 18 paramètres.
Mon but est de définir des pré-configurations de capteurs via une simple commande du terminal.
Par exemple si l'utilisateur tape "AJOUT CAPTEUR AIR_TEMP", celà lui ajoutera en EEPROM un capteur de température d'air avec la configuration usuelle. L'utilisateur n'aura alors plus qu'à modifier quelques paramètres spécifiques plustôt que les 18 habituels.
Le problème est que je peux avoir 40 capteurs différents, donc 40 pré-configurations à enregistrer dans le programme, ce qui est lourd pour le microcontrôleur

[Vincent PETIT]

J'ai compris (enfin j'espère ) mais la question que je me pose c'est comment se fait il que ce soit au microcontrôleur de gérer ça ? Pourquoi ce n'est pas le logiciel côté utilisateur qui prend en charge la génération de pré-configuration à envoyer dans l'EEPROM du micro ?

J'ai déjà bossé sur un cas très similaire :
- Une centrale où on pouvait connecter 256 capteurs de gaz différents ou cartes relais ou cartes entrées logiques / analogiques ou carte générateur 4-20mA, .....
- On envoyer dans la centrale 256 config qui contenait des seuils de déclenchement des alarmes, des temps d'intégration, des actions, des courants a générer, .....

Et c'est le logiciel PC qui pré-remplissait les configurations car tout comme toi on connaissait grosso modo les valeurs recommandés ou approchés qui convenait dans bien des cas.

Tu ne peux pas envisager ça ?

[Delias]

Bonsoir à tous

Vincent va chercher un peu trop loin dans le pourquoi du comment, mais ses réflexions sont pleines de bon sens! Il est éventuellement le temps de faire une application PC de dialogue avec ton micro et de laisser le terminal aux développeurs...

La réponse bête et brute à ta première question c'est qu'il faut stocker tes jeux de données dans la mémoire programme. Et cela la norme C ne le défini pas! Les instructions sont spécifiques à chaque architecture (ou famille d'architectures), par exemple ici pour les AVR (Arduino Uno, Nano, Mega, etc...).
L'autre possibilité c'est en déclarant le tableau mammouth de la solution 2 comme constant, sauf que cela ne marchera pas à chaque fois. Cela va dépendre de ce que le compilateur peut calculer à la compilation, de l'architecture et du niveau d'optimisation choisi.

Bonne suite

Delias

[Grokiff]

J'ai compris (enfin j'espère ) mais la question que je me pose c'est comment se fait il que ce soit au microcontrôleur de gérer ça ? Pourquoi ce n'est pas le logiciel côté utilisateur qui prend en charge la génération de pré-configuration à envoyer dans l'EEPROM du micro ?

J'ai déjà bossé sur un cas très similaire :
- Une centrale où on pouvait connecter 256 capteurs de gaz différents ou cartes relais ou cartes entrées logiques / analogiques ou carte générateur 4-20mA, .....
- On envoyer dans la centrale 256 config qui contenait des seuils de déclenchement des alarmes, des temps d'intégration, des actions, des courants a générer, .....

Et c'est le logiciel PC qui pré-remplissait les configurations car tout comme toi on connaissait grosso modo les valeurs recommandés ou approchés qui convenait dans bien des cas.

Tu ne peux pas envisager ça ?

Bonjour,

Tout simplement parce qu'il n'y a pas de logiciel côté client. La carte électronique représente la centrale d'acquisition de la station météo qui est installée sur le terrain et qui est autonome.
Il y a une phase de configuration usine avant installation terrain et la déclaration des capteurs présents physiquement sur la station fait parti de cette configuration qui se fait via un terminal RS232

[Grokiff]

Bonsoir à tous

Vincent va chercher un peu trop loin dans le pourquoi du comment, mais ses réflexions sont pleines de bon sens! Il est éventuellement le temps de faire une application PC de dialogue avec ton micro et de laisser le terminal aux développeurs...

La réponse bête et brute à ta première question c'est qu'il faut stocker tes jeux de données dans la mémoire programme. Et cela la norme C ne le défini pas! Les instructions sont spécifiques à chaque architecture (ou famille d'architectures), par exemple ici pour les AVR (Arduino Uno, Nano, Mega, etc...).
L'autre possibilité c'est en déclarant le tableau mammouth de la solution 2 comme constant, sauf que cela ne marchera pas à chaque fois. Cela va dépendre de ce que le compilateur peut calculer à la compilation, de l'architecture et du niveau d'optimisation choisi.

Bonne suite

Delias

Merci beaucoup pour cette réponse.
Comme indiqué à M.Petit, je n'ai pas de logiciel la possibilité de développer un logiciel dédié, il faudrait que je le diffuse à chaque personne qui interviendrait sur la station météo et ce n'est pas dans notre process.

En revanche votre réponse concernant le stockage du tableau m'aide pas mal.
Je vais essayer de stocker le tableau en static const.

Par contre j'ai un nouveau problème concernant précisément ce tableau mamouth comme vous l'avez judicieusement nommé :

C'est un tableau de structures :

Code :

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

1
2
3
4
5
6
7
8
typedef struct
{
unsigned int Param1;
float Param2;
char *Param3;
signed short int Param4[2][16];
[...]
} T_CapteurConfig;

Avec la déclaration du tableau :

Code :

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

1
2
3
4
5
T_CapteurConfig MonTableau[100] =
{
{200, 4.6, "Temperature d'air", {}, [...]},
{350, 9.1, "Humidité de l'air", {}, [...]},
};

Je ne sais pas comment initilaiser le tableau de signed short int (Param4) de cette façon.

Est-ce que quelqu'un a une idée ?

Quoi qu'il en soit, merci beaucoup pour votre aide

[Vincent PETIT]

Ça devrait ressembler à ça :


Définition

Code C :

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

1
2
3
4
5
6
7
8
typedef struct
{
unsigned int Param1;
float Param2;
char *Param3;
signed short int Param4[2][16];
[...]
} T_CapteurConfig;

Initialisation

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
T_CapteurConfig MonTableau[100] = {
{200, 
 4.6, 
 "Temperature d'air", 
 {{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}, 
  {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}}, 
 [...]},
 
{350,
 9.1,
 "Humidité de l'air",
 {{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}, 
  {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}}, 
 [...]},
};

[Grokiff]

En effet, ça compile et fonctionne ainsi.

En vous remerciant pour votre aide !