J'aimerai ajouter du code de DEBUG dans une librairie, et pour bien faire, j'aimerai que ce code son condionné par un #idfef DEBUG, comme ça on le compile pas si on ne débugge pas.
Le problème c'est que actuellement je suis obligé d'aller mettre un
#define DEBUG 1
Dans la librairie, alors que je voudrais "activer" le mode DEBUG directement à partir du main code, sans aller modifier ma librairie, qui est bien rangée dans son répertoire ....\arduino\libraries.
L'ide arduino compile les librairies et le code utilisateur de manière séparé (ce qui est logique).
Donc si ce n'est pas dans le .h "commun" au deux codes ça ne marchera pas.
(à moins de faire une variable "extern" globale dans le .h et la déclarer en globale dans le code utilisateur, mais ça c'est crade)
Quand tu développes une librairie c'est toi qui la debug, ton #define DEBUG doit donc être dans le .cpp (même pas dans le .h) de ta librairie.
Une fois la phase de debug finit tu commentes le #define, d'un point de vue utilisateur la librairie ne doit pas avoir à être débuggé.
En fait, c'est pas pour du DEBUG, mon objectif est de permettre aux utilisateur de ma librairie d'utiliser la LED de leur Ardunio (pin 13), pour visualiser l'état du signal reçu comme suit :
Si ça clignote rapidement c'est qu'on reçoit bien du PPM valide.
Si ça clignote lentement c'est qu'on a un problème de réception PPM.
Mais je veux aussi leur laisser le choix d'utiliser la LED de l'arduino pour autre chose.
Et si ils ne veulent pas utiliser la LED pour PPMread, bha je ne souhaite pas compiler tout le code en rapport avec ça...
Pourtant, dans la librairie PinChangeInt, on utilise des "#define" du sketch récupérés dans la LIB :
// #define NO_PORTB_PINCHANGES // to indicate that port b will not be used for pin change interrupts
// #define NO_PORTC_PINCHANGES // to indicate that port c will not be used for pin change interrupts
// #define NO_PORTD_PINCHANGES // to indicate that port d will not be used for pin change interrupts
Utilisé comme suit dans mon sketch de l'époque :
// Sketch to read a Rx receiver and to apply first channels to some servos
// V003
// Frome Sev
#define NO_PORTB_PINCHANGES //to go faster
#define NO_PORTC_PINCHANGES //to go faster
#include <PinChangeInt.h>
#include <Servo.h>
Je me souviens qu'il fallait que le #define soit avant l'include de la LIB... mais quand je teste ça dans ma LIB ça ne donne rien.
Il n'y a qu'à faire une méthode/fonction dans ta librairie par laquelle l'utilisateur indique qu'il veut utiliser tel pin pour le debug. Par défaut la librairie ne définit aucune pin et dans ce cas l'option de debug n'est pas active.
Ou alors si ta librairie se présente sous la forme d'une classe tu peux le faire à travers le constructeur avec un paramètre optionnel.
C'est pas tout à fait comme du code conditionnel, le code sera toujours là mais bon c'est une solution possible....
Je suis un maniaco-depressif du code UTILE, je ne souhaite pas polluer mes interruptions avec des IF inutiles si l'utilisateur ne souhaites pas utiliser la LED.
On utilise la LED pour vérifier sa liaison quand on a un doute... sinon on ne le l'utilise quasiment jamais.
Je crois que faire "une librairie flexible" que tout le monde peut utiliser/paramétrer est en contradiction avec faire "une librairie optimisée"... au vu du nombre d'utilisateurs... (pour l'instant 1) je pense que je vais plutôt continuer dans une voie optimisée / non flexible.
Ce qu'il te faudrait c'est l'option -D de gcc pour définir un #define dans tout les fichiers à compiler.
Mais comme l'ide ne permet pas de modifier la ligne de commande pour la compilation c'est cuit.
Seul solution : un #define dans le .cpp que l'utilisateur modifie à chaque fois qu'il en a besoin.
skywodd:
Seul solution : un #define dans le .cpp que l'utilisateur modifie à chaque fois qu'il en a besoin.
C'est ce que j'utilise actuellement, mais dans le H.
Je suis vraiment partagé à propos de l'IDE Arduino, d'un côté je trouve ça génial de simplicité (ça m'a quand même permis de commencer sans douleur) et d'un autre côté le cadre est tellement rigide !
Je sais bien que c'est lié, et que c'est la rigidité de ce cadre qui permet une grande uniformité des développements... mais la je me sens vraiment contraint à plusieurs niveaux, et passer le cap de l'étideur alternatif me fait peur, car je ne pourrais plus partager aussi facilement...
UniseV:
Je suis vraiment partagé à propos de l'IDE Arduino, d'un côté je trouve ça génial de simplicité (ça m'a quand même permis de commencer sans douleur) et d'un autre côté le cadre est tellement rigide !
C'est l'éternel dilemme entre simplicité et rigidité.
L'un ne va pas sans l'autre.
Je relance, vu que j'avais une question similaire...
Et là, après quelques essais, stuppeur!!!
Effectivement, un #define avant l'appel d'un .h, on peut le retrouver dans le .h, mais comme les libs sont compilées séparément, ben au second passage, le #define a disparu.
Je croyais que le compilateur prenait TOUS les fichiers pour n'en faire plus qu'un, puis compilait, bah non, c'est le contraire, il compile puis rassemble après, trop déçu!
C'est le principe du C (ou C++) et des "unités de compilation". Chaque fichier ".c" ou ".c++" produit un fichier "objet" homogène, qui est concaténé durant la phase d'édition des liens. Avant, l'optimisation se faisait en prenant ou pas des "fichiers objets", en fonction des besoins. Maitnenant, les compilateurs vont plus loin en désactivant du code inutilisé dans ces objets (si je ne me trompe pas).
Je crois qu'il ne reste qu'une chose à faire, c'est de réussir à rajouter un paramètre dans l'appel à avr-gcc... il suffirait d'avoir un -DCONF_FILE=c:... pour que dans toutes mes libs, je n'aie qu'à aller includer CONF_FILE (ça marche, j'ai essayé...) Reste à trouver un moyen de mettre ce truc dans arduino, j'ai récupéré les sources de l'IDE, mais le java, j'y comprends rien et je trouve même pas un fichier qui me parle... ça doit pas être compliqué à coder, ça...
ou plus bourin : renomer le fichier avr-gcc.exe et créer un avr-gcc.bat qui lui saurait rajouter le -D...
XavierMiller:
ou définir un "config.h" que tu #include dans chaque source nécessaire
Oui, mais il faut réécrire ce config.h pour chaque projet, donc ça ne simplifie pas les choses. je suis en train de voir avec PSPad, un éditeur que je connais bien, dès fois qu'il arrive à me lancer un avr-gcc... mais encore faut-il connaître la liste des appels...