des #INCLUDE récalcitrants
Répondre à la discussion
Affichage des résultats 1 à 19 sur 19

des #INCLUDE récalcitrants



  1. #1
    abracadabra75

    des #INCLUDE récalcitrants


    ------

    Bonjour.

    Un de mes projets peut être implanté sur deux platines.
    L'une avec un processeur Atmel MEGA16;
    L'autre, un processeur Tiny2313.

    Pour s'adapter sans avoir à ré-écrire de nombreuses lignes, j'utilise des '.INCLUDE xxx' qui contiennent les lignes particulières à chaque processeur.

    Pour le Mega16 j'ai
    Code:
    .INCLUDE "E:\Processeur_Mega.00.inc"
    .INCLUDE "E:\Platine_Mega.00.inc"
    Pour le Tiny:
    Code:
    .INCLUDE "E:\Processeur_Tiny.00.inc"
    .INCLUDE "E:\Platine_Tiny.00.inc"
    Afin de n'avoir qu'une seule procédure pour compiler l'un ou l'autre version, j'ai alors voulu utiliser les 'if defined' du préprocesseur;
    (voir: https://www.microchip.com/webdoc/avr...irectives.html)

    J'ai fait deux en-têtes , pour chacun des processeurs
    puis une partie commune aux deux, nommée "commun.inc"

    Pour le mega:
    Code:
    #define Processeur Mega
    .INCLUDE "E:\commun.inc'
    Pour le tiny:
    Code:
    #define Processeur Tiny
    .INCLUDE "E:\commun.inc'
    la partie commune:
    Code:
    #if defined (Mega)
    #INCLUDE "E:\ Processeur_Mega.00.inc"
    #INCLUDE "E:\Platine_Mega.00.inc"
    #endif
    ;----------------
    #if defined (Tiny)
    #INCLUDE "E:\Processeur_Tiny.00.inc"
    #INCLUDE "E:\Platine_Tiny.00.inc"
    #endif
    Je fais certainement une erreur car cela ne fonctionne pas...: les #INCLUDE de la partie commune sont ignorés.
    Où est l'erreur?

    Merci si vous pouvez me l'indiquer.

    -----
    Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.

  2. #2
    lou_ibmix_xi

    Re : des #INCLUDE récalcitrants

    Sans être sûr, j'ai l'impression que tu mélange les choux et les pommes...

    La directive "#include" (en minuscule!) est faite pour inclure des fichiers ".h" (éventuellement des ".c" mais c'est une très mauvaise pratique).
    Or les fichiers qu tu décries sont des ".inc", je ne sais pas ce qu'ils contiennent, probablement pas des déclarations/définitions C. Peut-être bien de l'assembleur pour les "couches basses" (crt, interruptions...), auquel cas c'est plus au iveau de l'édition de lien que ça doit se jouer, donc dans la définition du projet / de la toolchain à utiliser.

    A prendre avec des pincettes.

  3. #3
    abracadabra75

    Re : des #INCLUDE récalcitrants

    Bonjour lou_ibmix_xi.

    Dans le cas présent, il s'agit d'Assembleur, dont les directives sont presque identique à celles du C.
    L'assembleur ne fait pas de différence entre majuscules et minuscules.

    J'ai du mal poser ma question, car celle-ci ne porte pas sur le contenu des fichiers appelant/appelé, mais sur la syntaxe des instructions du préprocesseur.
    Je reprends autrement, en simplifiant:

    Un fichier appelant contient une instruction "define..." et un ".include..."
    #define Processeur Mega
    .include "commun"

    le fichier appelé "commun" contient une directive de test qui si réalisé appelle par "#include ..."
    un (ou des, peu importe) ce qui doit suivre:
    #if defined (Mega)
    #include "toto"
    #endif

    Ce qui ne marche pas est l'inclusion de "toto".
    Ou bien j'ai mal rédigé le "#define Mega"
    soit le "if defined Mega"

    C'est là l'objet de ma question: les instructions sont-elles mal écrites, ce qui empêche le bon fonctionnement?

    Je te remercie de me rappeler les dangers d'une mauvaise utilisation, mais ici le contenu des fichiers n'est pas en cause, il n'est question que de leur appel.

    J'utilise Atmel studio 7 pour compiler.
    (Bizarre: la balise "code" a disparu....)
    Dernière modification par abracadabra75 ; 09/07/2018 à 14h11.
    Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.

  4. #4
    lou_ibmix_xi

    Re : des #INCLUDE récalcitrants

    Citation Envoyé par abracadabra75 Voir le message
    Bonjour lou_ibmix_xi.

    Dans le cas présent, il s'agit d'Assembleur, dont les directives sont presque identique à celles du C.
    L'assembleur ne fait pas de différence entre majuscules et minuscules.

    J'ai du mal poser ma question, car celle-ci ne porte pas sur le contenu des fichiers appelant/appelé, mais sur la syntaxe des instructions du préprocesseur.
    Je reprends autrement, en simplifiant:

    Un fichier appelant contient une instruction "define..." et un ".include..."
    #define Processeur Mega
    .include "commun"

    le fichier appelé "commun" contient une directive de test qui si réalisé appelle par "#include ..."
    un (ou des, peu importe) ce qui doit suivre:
    #if defined (Mega)
    #include "toto"
    #endif

    Ce qui ne marche pas est l'inclusion de "toto".
    Ou bien j'ai mal rédigé le "#define Mega"
    soit le "if defined Mega"

    C'est là l'objet de ma question: les instructions sont-elles mal écrites, ce qui empêche le bon fonctionnement?

    Je te remercie de me rappeler les dangers d'une mauvaise utilisation, mais ici le contenu des fichiers n'est pas en cause, il n'est question que de leur appel.

    J'utilise Atmel studio 7 pour compiler.
    (Bizarre: la balise "code" a disparu....)
    Je comprends mieux, et ma réponse n'étais pas terrible...
    Je recommence.

    La directive d'inclusion du preprocesseur est:
    Code:
    #include "chemin/du/fichier"
    (ou #include<fichier>" si dans le "path")

    je parlais de l'utilisation du pre-processeur dans le cas du C. Il est vrai qu'il peut servir pour "prémacher" n'importe quoi comme langage, C++, assembleur... à condition que les fichiers respectent la syntaxe de l'étape d'après (C++, assembleur), _ET_ que les directives cpp respectent la syntaxe cpp.

    par ex:
    Code:
    #define ATMEGA 1
    #if defined ATMEGA && ATMEGA > 0
        #if defined PIC && PIC > 0
             #error "Choose beween PIC end ATMEGA"
        #endif
        #include "atmega.h"
    #endif
    Dernière modification par lou_ibmix_xi ; 09/07/2018 à 19h29.

  5. A voir en vidéo sur Futura
  6. #5
    pm42

    Re : des #INCLUDE récalcitrants

    Citation Envoyé par abracadabra75 Voir le message
    Je fais certainement une erreur car cela ne fonctionne pas...: les #INCLUDE de la partie commune sont ignorés.
    Plus haut, tu utilises des .INCLUDE et là des #INCLUDE. C'est normal ?

  7. #6
    abracadabra75

    Re : des #INCLUDE récalcitrants

    Bonjour.
    Bonne remarque...
    Il semblerait que l'Assembleur ait complété ses directives (commençant par un point .) par celles du C (qui commencent par un #) qui lui manquaient.
    Les directives du C sont obligatoirement en minuscules. Ainsi les directives complémentaires doivent respecter la graphie du C. #define ne peut être écrit en majuscules (===>erreur!). Ceci concerne les déclaratives listées dans le document cité plus haut.
    Pour include, c'est vicieux car existant dans l' assembleur, .INCLUDE (appartenant à l'assembleur) est autorisé tandis que #include (appartenant au C) est obligatoirement en minuscules.
    Ceci ressort des tests que j'ai effectués, je ne l'ai trouvé nulle part; je pense ne pas me tromper.

    Pour en revenir à mon problème, il se résume à ceci:
    -1) une condition est posée
    -2) si elle est réalisée, un action est exécutée, sinon rien ne se passe

    ce que je traduis en
    #define xx=0 //1) la condition est posée
    #if defined xx //2) le test
    #include "toto.inc" // l'action
    #endif

    Quelle que soit la valeur que je donne à xx, la condition est considérée vraie et l'action s'exécute. Si je change le nom xx en yy, ( le 2) restant avec xx), même punition.

    Comment poser une condition qui soit reconnue vraie ou fausse?
    Dernière modification par abracadabra75 ; 10/07/2018 à 09h08.
    Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.

  8. #7
    pm42

    Re : des #INCLUDE récalcitrants

    Tu supposes que "defined" teste que la valeur est 0 ou 1. Ce n'est pas le cas : il teste si la variable existe ou pas indépendamment de sa valeur.

    Si tu veux tester une valeur, il faut utiliser #if. Tu peux regarder ici : https://gcc.gnu.org/onlinedocs/gcc-3...p_4.html#SEC38

  9. #8
    abracadabra75

    Re : des #INCLUDE récalcitrants

    Tester une valeur ou une existence, je viens d'essayer...
    Concrètement, ce que je n'arrive pas à faire, c'est d'écrire quelque chose qui marche.
    Je pédale dans la choucroute!
    Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.

  10. #9
    lou_ibmix_xi

    Re : des #INCLUDE récalcitrants

    Les directives du C sont obligatoirement en minuscules. Ainsi les directives complémentaires doivent respecter la graphie du C.
    Pour préciser, non ce qui commence par "#" sont des directives du preprocesseur qui est un langage en soit, et qui n'est pas du C.

    Le préprocesseur ne sait faire que du remplacement de texte, éventuellement conditionné.

    Code:
    #define FOO
    définie une "variable" préprocesseur, à chaque fois que le préprocesseur croisera le symbole FOO, il le remplacera par sa valeur... Si elle est non précisée, elle sera à 0 (de mémoire), sinon tu peux fixer sa valeur, par exemple:

    Code:
    #define FOO 1
    Tu peux également faire de l'inclusion conditionnelle avec "#if", "#ifdef" (un raccourci pour "#if defined") test juste s'il le symbole est défini, mais "#if" peut tester une expression contenant des symboles préprocesseur, des constantes et les opérateurs classiques +, -, <, ==, >, &&, &, ||, | etc...

    Pour être complet, lorsque le préprocesseur croise le #include, il le remplace par le contenu du fichier inclue.

    Inspire toi de mon exemple, et poste ta version pour qu'on puisse t'aider à avancer.

  11. #10
    abracadabra75

    Re : des #INCLUDE récalcitrants

    Citation Envoyé par lou_ibmix_xi Voir le message
    Pour préciser, non ce qui commence par "#" sont des directives du preprocesseur qui est un langage en soit, et qui n'est pas du C.
    Tout à fait exact. J'aurais du écrire 'appartenant au domaine C'.

    Voici ce que j'ai écrit dans mon dernier test:
    Code:
    #define mega 1					//la conditionest posée
    
    #if defined mega > 0			    //exécution du test				 
          #include "E:\TST\00.PROCESS\000_Processeur_Mega.00.inc"
    #else
          #include "E:\TST\00.PROCESS\000_Processeur_Tiny.00.inc"
    #endif
    L'exécution est correcte, c'est le bon #include qui s'exécute, mais....
    si je fais
    Code:
    #define mega 0					//la conditionest posée
    
    #if defined mega > 0			    //exécution du test				 
          #include "E:\TST\00.PROCESS\000_Processeur_Mega.00.inc"
    #else
          #include "E:\TST\00.PROCESS\000_Processeur_Tiny.00.inc"
    #endif
    c'est toujours le "....Processeur_Mega" qui est inclus et non pas le "....Processeur_Tiny"
    Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.

  12. #11
    jacknicklaus

    Re : des #INCLUDE récalcitrants

    attention, defined mega est en soi un booléen (1 si mega a une valeur quelconque, 0 sinon).
    si mega est défini, ton test #if defined mega > 0 est traduit par if 1 > 0 ce qui est toujours vrai quelle que soit la valeur de mega !

    soit tu teste la définition de mega : #if defined mega
    soit tu teste sa valeur (en supposant qu'elle est définie) : #if mega > 0
    soit tu prend ceinture et bretelle : #if defined mega && mega > 0
    Dernière modification par jacknicklaus ; 10/07/2018 à 11h35.
    There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.

  13. #12
    abracadabra75

    Re : des #INCLUDE récalcitrants

    J'ai testé la ceinture, j'ai testé la bretelle, mais pas (encore) les deux:
    Question du bourrin intégral: que faut-il écrire pour que le test fonctionne?
    Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.

  14. #13
    lou_ibmix_xi

    Re : des #INCLUDE récalcitrants

    Question du bourrin intégral: que faut-il écrire pour que le test fonctionne?
    ce qui est sûr c'est que comme dit ci-dessus '#if defined mega > 0' n'est pas correct, il faut un opérateur logique entre les 2 tests (existence puis si il existe sa valeur)... donc essaye ce qu'il te reste à essayer, tu n'es pas à l'abri d'une bonne surprise...

    Ceci dit, ça peut dépendre également des directives au-dessus, donc n'hésite pas à nous en mettre un peu plus.

    Dernière remarque, le test est facile en préprocesseur, certains compilateurs te permettent d'accéder au résultat de cette étape (de mémoire option -E pour gcc), tu peux également mettre un message afficher durant le préprocessing (si une directive #warning, #message ou #error est disponible). Où carrément mettre un include d'un fichier qui n'existe pas pour "tracer" par où tu passes (l'inclusion d'un fichier inexistant doit claquer une erreur).

  15. #14
    abracadabra75

    Re : des #INCLUDE récalcitrants

    Comme je l'ai indiqué tout au début, le but de cette manip est de n'avoir qu'une procédure pour s'adapter au changement de processeur. Actuellement, j'ai deux procédures, adaptées chacune à son processeur (et là je n'ai pas d'ennui).
    Je cherche donc à en faire une seule où en mettant en tête le type de processeur les adaptations se font automatiquement.
    Cette procédure n'est précédée par rien, le #define indiquant le processeur concerné vient en première ligne.
    J'at testé la "tenue intégrale" en testant la valeur booléenne sur l'égalité:
    Code:
    #define mega (1)					             //la condition est posée
    
    #if defined mega && mega == 1 			            //exécution du test	
    	#include "E:\TST\00.PROCESS\000_Processeur_Mega.00.inc"
    #else
    	#include "E:\TST\00.PROCESS\000_Processeur_Tiny.00.inc"
    #endif
    L'include demandé vient correctement .
    Par contre, si je teste:
    Code:
    #define mega (0)					             //la condition est posée
    
    #if defined mega && mega == 1 			            //exécution du test
    	#include "E:\TST\00.PROCESS\000_Processeur_Mega.00.inc"
    #else
    	#include "E:\TST\00.PROCESS\000_Processeur_Tiny.00.inc"
    #endif
    j'ai la totale!!!
    Les deux include sont chargés, ce qui évidemment f....t le bazar. Pas de divine surprise.
    Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.

  16. #15
    lou_ibmix_xi

    Re : des #INCLUDE récalcitrants

    Bizarre, à la lecture je penserai que ça marche... je vais tester ça chez moi...
    2 remarques:
    - je vais tester avec le préprocesseur de gcc et de clang, ce ne sont probablement pas les mêmes que le tien, mais normalement c'est normalisé.
    - évite les caractères accentués et autre non ASCII 7bits, ils ne sont peut être pas supportés.

  17. #16
    lou_ibmix_xi

    Re : des #INCLUDE récalcitrants

    en remplaçant les #include par des #warning, ça marche avec gcc et clang (option -E), et avec les accents aussi...

  18. #17
    abracadabra75

    Re : des #INCLUDE récalcitrants

    A la suite de ton message, j'ai changé de compilateur. J'ai repris le vieux Studio 4 que j'avais abandonné à cause de ses plantages trop fréquents.
    Et avec lui, ça marche (même avec les accents des commentaires).

    Donc affaire résolue.
    Je vais quand même essayer de voir pourquoi ça ne marche pas avec Studio 7, avec lequel je suis nettement moins à l'aise vue sa complexité, m'enfin...
    Où chercher dans son usine à gaz?

    Je vous remercie tous pour votre aide qui m'a permis de résoudre mon problème.

    A+
    Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.

  19. #18
    abracadabra75

    Re : des #INCLUDE récalcitrants

    J'ai du faire une faute de frappe quelle que part, car ce matin en reprenant le problème, cela fonctionne également sur Atmel Studio 7.
    Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.

  20. #19
    lou_ibmix_xi

    Re : des #INCLUDE récalcitrants

    Citation Envoyé par abracadabra75 Voir le message
    J'ai du faire une faute de frappe quelle que part, car ce matin en reprenant le problème, cela fonctionne également sur Atmel Studio 7.
    Tant mieux... Plus de mystère

Discussions similaires

  1. Raccourcis récalcitrants [Résolu]
    Par klodio70 dans le forum Logiciel - Software - Open Source
    Réponses: 1
    Dernier message: 03/04/2016, 13h12
  2. [Blanc] LL (ou prise??) récalcitrants ? [Résolu]
    Par Sabaha dans le forum Dépannage
    Réponses: 9
    Dernier message: 10/12/2014, 21h00
  3. TCI4.3 et SDS3 récalcitrants
    Par invite9b9def91 dans le forum Électronique
    Réponses: 5
    Dernier message: 08/11/2013, 20h00
  4. Deux trojans récalcitrants
    Par invite30ca8e50 dans le forum Sécurité et malwares : désinfectez votre machine
    Réponses: 23
    Dernier message: 06/02/2012, 20h51
  5. Un include() qui ne fonctionne pas
    Par invite234d9cdb dans le forum Internet - Réseau - Sécurité générale
    Réponses: 5
    Dernier message: 11/01/2009, 15h45