Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1190 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  [résolu] un fichier cpp, 2 compilateurs (g++ et avr-g++)

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[résolu] un fichier cpp, 2 compilateurs (g++ et avr-g++)

n°2189440
natha31
Posté le 09-05-2013 à 13:14:11  profilanswer
 

Bonjour.
 
À mes heures perdues je programme des microprocesseurs AVR en C++ pour des applications robotiques.
Pour mon dernier projet j'aimerais faire un petit simulateur sur PC en C++ également.
 
Comme ces 2 programmes sont écrits en C++, il y a beaucoup de code qui est un commun pour la puce est pour le simulateur.
 
Je voudrais donc compiler le programme destiné au microprocesseur 2 fois, avec 2 compilateurs différents :
- une fois pour la puce avec avr-g++
- une fois pour le simulateur avec g++
 
Il y aurait donc une partie du code qui est commune, qui appelle des fonctions destinées soit à g++ soit à avr-g++.
Exemple de 'code' qui permet de faire clignoter une led (pour simplifier je ne traite pas les pauses) :
 

Code :
  1. // partie commune
  2. for(int i=0 ; i<10 ; i++) {
  3.    led_on();
  4.    led_off();
  5. }
  7. // code pour la puce :  
  8. void led_on() {digitalWrite(13, HIGH);}
  9. void led_off() {digitalWrite(13, LOW);}
  11. // code pour le simu :  
  12. void led_on() {/*on dessine un rond rouge dans l'interface graphique*/}
  13. void led_off() {/*on efface le rond rouge*/}


 
Le compilo 'choisirait' ensuite la fonction qui lui convient.
 
Je ne sais pas trop comment m'y prendre...
 
Nathanaël

Message cité 1 fois
Message édité par natha31 le 12-05-2013 à 20:33:23
mood
Publicité
Posté le 09-05-2013 à 13:14:11  profilanswer
 

n°2189445
Farian
Posté le 09-05-2013 à 13:42:52  profilanswer
 

natha31 a écrit :

Bonjour.
 
À mes heures perdues je programme des microprocesseurs AVR en C++ pour des applications robotiques.
Pour mon dernier projet j'aimerais faire un petit simulateur sur PC en C++ également.
 
Comme ces 2 programmes sont écrits en C++, il y a beaucoup de code qui est un commun pour la puce est pour le simulateur.
 
Je voudrais donc compiler le programme destiné au microprocesseur 2 fois, avec 2 compilateurs différents :
- une fois pour la puce avec avr-g++
- une fois pour le simulateur avec g++
 
Il y aurait donc une partie du code qui est commune, qui appelle des fonctions destinées soit à g++ soit à avr-g++.
Exemple de 'code' qui permet de faire clignoter une led (pour simplifier je ne traite pas les pauses) :
 

Code :
  1. // partie commune
  2. for(int i=0 ; i<10 ; i++) {
  3.    led_on();
  4.    led_off();
  5. }
  7. // code pour la puce :  
  8. void led_on() {digitalWrite(13, HIGH);}
  9. void led_off() {digitalWrite(13, LOW);}
  11. // code pour le simu :  
  12. void led_on() {/*on dessine un rond rouge dans l'interface graphique*/}
  13. void led_off() {/*on efface le rond rouge*/}


 
Le compilo 'choisirait' ensuite la fonction qui lui convient.
 
Je ne sais pas trop comment m'y prendre...
 
Nathanaël


 
 
Bonjour !
 
Pour faire propre, je vous propose deux possibilités, qui correspondent à ce que l'on rencontre le plus souvent :  
 
* Des directives de précompilation  
 

Code :
  1. // partie commune
  2. for(int i=0 ; i<10 ; i++) {
  3.    led_on();
  4.    led_off();
  5. }
  8. void led_on()
  9. {
  10. #ifdef SIMULATEUR
  11.   /*on dessine un rond rouge dans l'interface graphique*/
  12. #else
  13.   digitalWrite(13, HIGH);
  14. #endif
  15. }
  17. void led_off()
  18. {
  19. #ifdef SIMULATEUR
  20.   /*on efface le rond rouge*/
  21. #else
  22.   digitalWrite(13, LOW);
  23. #endif
  24. }


 
Et vous compilez la partie g++ avec l'option -DSIMULATEUR
 
* Des fichiers séparés pour les codes spécifiques (ce que fait Qt, par exemple) :  
 
Fichier gestionled.cpp

Code :
  1. // partie commune
  2. for(int i=0 ; i<10 ; i++) {
  3.    led_on();
  4.    led_off();
  5. }


 
 
Fichier gestionled_hard.cpp

Code :
  1. void led_on()
  2. {
  3.   digitalWrite(13, HIGH);
  4. }
  6. void led_off()
  7. {
  8.   digitalWrite(13, LOW);
  9. }


 
Fichier gestionled_simu.cpp

Code :
  1. void led_on()
  2. {
  3.   /*on dessine un rond rouge dans l'interface graphique*/
  4. }
  6. void led_off()
  7. {
  8.   /*on efface le rond rouge*/
  9. }


 
A titre personnel, je préfère la deuxième solution, qui est aussi plus lisible si vous utilisez plusieurs plates-formes en plus du code de simulation, mais c'est une affaire de goût.
 
Bonne continuation !

n°2189467
natha31
Posté le 09-05-2013 à 16:31:35  profilanswer
 

ouah super ! !
Merci merci beaucoup !
 
Pour une solution ou l'autre, je verrais à l'usage.
La 2ème solution me parait en effet plus lisible, mais dans les cas ou la fonction ne fait qu'une ligne par exemple, je préférais la 1ere solution pour éviter d'avoir des fichiers en pagaille.
 
Du coup pour la 2ème solution, je suppose qu'il suffit d'ajouter les fichiers hard ou simu à la compil ?
genre (en simplifiant la commande de compilation) :

Code :
  1. avr-g++ gestionled.cpp gestionled_hard.cpp
  2. g++ gestionled.cpp gestionled_simu.cpp


 
Natha

n°2189475
Farian
Posté le 09-05-2013 à 16:44:49  profilanswer
 

Tout à fait ! Je ne l'ai pas précisé dans mon message précédent, mais c'est bien le cas, la liste des fichiers à compiler dépend alors de la plate-forme.
 
Bon courage !
 
Edit : après réflexion, la deuxième solution me paraît plus intéressante aussi car elle permet de mieux séparer les couches "métier" des couches "drivers", qui attaquent le matériel (ou l'interface du simulateur).


Message édité par Farian le 09-05-2013 à 16:48:14
n°2189535
natha31
Posté le 09-05-2013 à 23:27:23  profilanswer
 

Ok, par conte du coup je ne comprends pas trop comment faire mon #include dans mon gestionled.cpp, vu que le nom change...
 
Est-ce que je peux faire ça ?
 

Code :
  1. #ifdef SIMULATEUR
  2. #include gestionled_simu.h
  3. #else
  4. #include gestionled_hard.h

n°2189540
Farian
Posté le 10-05-2013 à 00:27:29  profilanswer
 

Tout à fait !
 
En revanche, les fonctions et structures d'interface devraient être les mêmes, non ? (Ou alors j'ai raté quelque chose :) ).
 
Les fonctions et structures spécifiques peuvent être déclarées dans des fichiers inclus uniquement par les .cpp spécifiques, cela permet de n'avoir que du commun dans la partie "métier".

n°2189572
natha31
Posté le 10-05-2013 à 10:47:44  profilanswer
 

Citation :

En revanche, les fonctions et structures d'interface devraient être les mêmes, non ?


Pas compris, tu peux détailler ou donner un exemple?
 

Citation :

Les fonctions et structures spécifiques peuvent être déclarées dans des fichiers inclus uniquement par les .cpp spécifiques


Pas compris non plus...

n°2189574
Farian
Posté le 10-05-2013 à 11:23:37  profilanswer
 

Dans l'exemple que vous avez donnée, les fonctions d'interface entre la couche métier et la couche driver sont les mêmes : led_on() et led_off().
 
De la même façon, on pourrait imaginer que les structures (par exemple des paramètres) soient les mêmes aussi, que le programme utilise les drivers matériels ou le simulateur.
 
Pour moi, dans le code commun (métier), on ne doit jamais se poser la question de savoir si on appelle une fonction driver du matériel cible ou celle du simulateur, on appelle simplement une fonction driver dont la signature est la même quel que soit le "matériel" derrière.
 
Donc, partant de là, au niveau du code commun, on n'a pas à avoir de #ifdef SIMULATEUR ou autres choses du genre.
 
En revanche, dans le code spécifique du matériel cible, par exemple, on peut avoir besoin de définir un type de structure partagé entre plusieurs fichiers .cpp du matériel. Ce type de structure serait alors décrit dans un fichier .h spécifique au matériel considéré et inclus uniquement par les .cpp de gestion de ce matériel (marche aussi pour la définition des IHM pour la partie "simulateur", par exemple).
 
J'espère avoir été clair, sinon, ce n'est pas bien grave non plus, cela ne remet pas en cause le principe :)
 
Bonne continuation !

n°2189637
natha31
Posté le 10-05-2013 à 18:53:09  profilanswer
 

Citation :

Pour moi, dans le code commun (métier), on ne doit jamais se poser la question de savoir si on appelle une fonction driver du matériel cible ou celle du simulateur, on appelle simplement une fonction driver dont la signature est la même quel que soit le "matériel" derrière.
 
Donc, partant de là, au niveau du code commun, on n'a pas à avoir de #ifdef SIMULATEUR ou autres choses du genre.


Oui tout à fait, sauf pour le #include comme je disais.
 

Citation :

En revanche, dans le code spécifique du matériel cible, par exemple, on peut avoir besoin de définir un type de structure partagé entre plusieurs fichiers .cpp du matériel. Ce type de structure serait alors décrit dans un fichier .h spécifique au matériel considéré et inclus uniquement par les .cpp de gestion de ce matériel (marche aussi pour la définition des IHM pour la partie "simulateur", par exemple).


 
Ok j'ai compris. Le fichier gestionled_hard.cpp peut appeler par exemple un fichier io.h qui gère les entrées/sorties de la puce, lequel peut éventuelleemnt être appelé par d'autres fichiers (gestioncapteur_hard.cpp, gestionmoteur_hard.cpp, ...)
 
J'aime bien parler par exemples :).

n°2189657
Farian
Posté le 10-05-2013 à 21:57:52  profilanswer
 

C'est exactement ça pour le deuxième point, le fichier "io.h", qui est spécifique au matériel n'est appelé que par des fichiers *_hard.cpp, mais que les codes communs ou du simulateur n'ont pas à utiliser.
 
En revanche, pour le premier, je ne vois pas quelles pourraient être les différences entre gestionled_simu.h et gestionled_hard.h, en tous cas les différences que gestionled.cpp a besoin de connaitre.
 
Mais c'est du pinaillage / de l'intégrisme, je vous l'accorde :)


Message édité par Farian le 10-05-2013 à 21:58:45
mood
Publicité
Posté le 10-05-2013 à 21:57:52  profilanswer
 

n°2189742
natha31
Posté le 12-05-2013 à 04:29:35  profilanswer
 

Citation :

En revanche, pour le premier, je ne vois pas quelles pourraient être les différences entre gestionled_simu.h et gestionled_hard.h, en tous cas les différences que gestionled.cpp a besoin de connaitre.


 
En effet, excellente remarque ! :jap:
gestionled_simu.h et gestionled_hard.h sont identiques ce sont les .cpp qui changent.
Du coup pas besoin du #ifdef SIMULATEUR, ce ne sera que le nom du fichier que l'on va changer à la compilation.
 

Citation :

Mais c'est du pinaillage / de l'intégrisme, je vous l'accorde :)


Comme quoi ça peut parfois être utile, ça m'a permis d'avancer dans mon raisonnement.
 
Merci beaucoup Farian en tout cas !

n°2189743
Farian
Posté le 12-05-2013 à 04:31:59  profilanswer
 

Cela me parait plus cohérent comme ça :)
 
Bonne continuation à vous et amusez-vous bien !

n°2190006
abuzor
Posté le 13-05-2013 à 20:48:21  profilanswer
 

Juste pour compléter, si tu fais de l'objet tu peux aussi faire ça avec l'héritage :
 

Code :
  1. class BaseGestionLed
  2. {
  3. // ...
  4. void fonctionCommune()
  5. {
  6. // partie commune
  7. for(int i=0 ; i<10 ; i++)
  8. {
  9.    led_on();
  10.    led_off();
  11. }
  12. }
  14. virtual void led_on() = 0;
  15. virtual void led_off() = 0;
  16. // ...
  17. };
  19. class HardGestionLed : public BaseGestionLed
  20. {
  21. // ...
  22. virtual void led_on()
  23. {
  24. digitalWrite(13, HIGH);
  25. }
  27. virtual void led_off()
  28. {
  29. digitalWrite(13, LOW);
  30. }
  31. // ...
  32. };
  33. class SoftGestionLed : public BaseGestionLed
  34. {
  35. // ...
  36. virtual void led_on()
  37. {
  38. /*on dessine un rond rouge dans l'interface graphique*/
  39. }
  41. virtual void led_off()
  42. {
  43. /*on efface le rond rouge*/
  44. }
  45. // ...
  46. };


 
Et tu instancie tes classes avec une Factory. Ca peut être intéressant si ton code est déjà object avec beaucoup de code commun.. Après chacun choisi ce qui est le mieux adapté ^^
 
Après je sais pas comment tu compiles, mais passer par un générateur de Makefile type CMake ou SCons peut te faciliter la tâche pour créer plusieurs targets directement en fonction du compilateur, etc, etc


Message édité par abuzor le 13-05-2013 à 20:53:00

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  [résolu] un fichier cpp, 2 compilateurs (g++ et avr-g++)

 

Sujets relatifs
FICHIER TEXTE en JAVAChanger ligne d'un fichier texte
jonction fichier MYD vers Ramdisk -> useless ?Insérer un ScrollBar dans un fichier xml - visite virtuelle
quelle volumétrie max du fichier de translation ".mo"Aide pour la création d'un fichier bat pour ping sur réseau
Batch Recherche fichier à partir d'une liste et CopierImporter un fichier ACCESS dans SQL SERVER
Remplacer un mot dans un fichierOrdonner des données dans un fichier txt
Plus de sujets relatifs à : [résolu] un fichier cpp, 2 compilateurs (g++ et avr-g++)

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.054 secondes

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR