Bienvenue aux nouveaux arrivants sur FantasPic !

- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.

--- L’équipe FantasPic ---

encore un soucis avec MPASM

Forum général sur l'Assembleur !

Modérateur : mazertoc

JJE
Passioné
Passioné
Messages : 399
Enregistré en : novembre 2017
Localisation : Picardie

encore un soucis avec MPASM

Messagepar JJE » dim. 12 avr. 2020 18:16

Bonjour à tous,
La macro suivante :

Code : Tout sélectionner

TMR0_IT macro
    movwf    TMR0_W_TEMP          
; sauver registre W
    
; et les autres chez soi
    swapf    STATUS
,w            ; swap status dans w
    banksel TMR0_DATAS
    movwf    TMR0_status_temp        
; sauver status swappé
    movf    PCLATH
, w
    movwf   TMR0_pclath_temp
    bcf     INTCON
, T0IF
    
; fin des sauvegardes, déjà 13 cycles perdus
    
; cette IT est-elle pour ici ?
    btfss   INTCON, T0IE
    return
    btfss   INTCON
, T0IF
    return
    
; oui
    variable i 
= 0
    while i 
< 8
        
; boucle i
        btfsc   TMR0_Flags
, TMR0_IT_BCL1_DONE+i
        goto    TMR0_IT_2
    
;    #DEFINE CMPT_TailleVar  TMR0_TAILLE_COMPTEURS
    ;    CMPT_ISNUL  TMR0_Cmpt_Bcl1
        
; les deux instructions suivantes remplacent les 2 lignes
        
; précédentes pour être sûr du nombre de cycles
        movf    TMR0_Cmpt_Bcl1
+2*i, w
        iorwf   TMR0_Cmpt_Bcl1
+2*i+1, w
        btfsc   STATUS
, Z
        goto    TMR0_IT_1
        
; pour équilibrer les deux situations en nombre de cycles perdus
        goto    
$+1
        nop
        
; 9 cycles perdus
        clrf    TMR0
        
#DEFINE CMPT_TailleVar  TMR0_TAILLE_COMPTEURS
        CMPT_DECUF  TMR0_Cmpt_Bcl1+2*i
        goto    TMR0_IT_FIN
        local TMR0_IT_1
TMR0_IT_1  
        bsf     TMR0_Flags
, TMR0_IT_BCL1_DONE+i
        movf    TMR0_Reste_Bcl1
+2*i, w
        
; 9 cycles perdus
        movwf   TMR0
        goto    TMR0_IT_FIN
i set i
+1
        local TMR0_IT_2
TMR0_IT_2    
    endw
TMR0_IT_FIN
    endm

me pose des problèmes d'assemblage que je ne comprends pas:
Executing: "C:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe" /q /p16F884 "test TMR0.asm" /l"test TMR0.lst" /e"test TMR0.err" /d__DEBUG=1
Error[116] ./TMR0.INC 561 : Address label duplicated or different in second pass (_3TMR0_IT_1)
Error[116] ./TMR0.INC 569 : Address label duplicated or different in second pass (_3TMR0_IT_2)
Error[116] ./TMR0.INC 561 : Address label duplicated or different in second pass (_3TMR0_IT_1)
Error[116] ./TMR0.INC 569 : Address label duplicated or different in second pass (_3TMR0_IT_2)
Error[116] ./TMR0.INC 561 : Address label duplicated or different in second pass (_3TMR0_IT_1)
Error[116] ./TMR0.INC 569 : Address label duplicated or different in second pass (_3TMR0_IT_2)
Error[116] ./TMR0.INC 561 : Address label duplicated or different in second pass (_3TMR0_IT_1)
Error[116] ./TMR0.INC 569 : Address label duplicated or different in second pass (_3TMR0_IT_2)
Error[116] ./TMR0.INC 561 : Address label duplicated or different in second pass (_3TMR0_IT_1)
Error[116] ./TMR0.INC 569 : Address label duplicated or different in second pass (_3TMR0_IT_2)
Error[116] ./TMR0.INC 561 : Address label duplicated or different in second pass (_3TMR0_IT_1)
Error[116] ./TMR0.INC 569 : Address label duplicated or different in second pass (_3TMR0_IT_2)
Error[116] ./TMR0.INC 561 : Address label duplicated or different in second pass (_3TMR0_IT_1)
Error[116] ./TMR0.INC 569 : Address label duplicated or different in second pass (_3TMR0_IT_2)
Skipping link step. Not all sources built successfully.


1 - pourquoi les étiquettes TMR0_IT_1 et TMR0_IT_2 sont-elles toujours préfixées de _3 alors qu'elles devraient l’être de _i, i = 1 à 8 ?ê
2 - pourquoi le local n'est-il pas pris en compte, ou mal.

J'ai déjà eu l'occasion d'utiliser cette directive sans problème. Notez que sa documentation ne parle pas de cet usage, pourtant indispensable.

Si quelqu'un a une idée, merci d'avance, sinon, je ferai péter, mais avec regrets, le while.
Cordialement

JJE

C'est pas parcequ'on n'a rien à dire qu'il faut fermer sa G....e

satinas
Expert
Expert
Messages : 1225
Enregistré en : novembre 2015

encore un soucis avec MPASM

Messagepar satinas » dim. 12 avr. 2020 20:41

Bonjour JJE
L'adresse de l'étiquette TMR0_IT_1, bien que locale, varie au cours de l'incrémentation de i dans une même expansion de la macro, ce qui expliquerait les messages d'erreur.
Tu n'aurais pas oublié d'ajouter des suffixes, du genre TMR0_IT_#v(i)
C'est en te lisant que j'ai d'ailleurs appris ces possibilités de l'assembleur.

JJE
Passioné
Passioné
Messages : 399
Enregistré en : novembre 2017
Localisation : Picardie

encore un soucis avec MPASM

Messagepar JJE » lun. 13 avr. 2020 10:32

salut satinas,
je ne connaissait pas ces histoires de suffixes, je pensais pourtant commencer à maîtriser MPASM, j'essaye tout de suite
Merci pour cette idée qui me semble très bonne :-)
Cordialement

JJE

C'est pas parcequ'on n'a rien à dire qu'il faut fermer sa G....e

JJE
Passioné
Passioné
Messages : 399
Enregistré en : novembre 2017
Localisation : Picardie

encore un soucis avec MPASM

Messagepar JJE » lun. 13 avr. 2020 10:45

satinas a écrit :Source du message Tu n'aurais pas oublié d'ajouter des suffixes, du genre TMR0_IT_#v(i)

essais fait, ça marche très bien :-) mais je ne connaissais pas
satinas a écrit :Source du message C'est en te lisant que j'ai d'ailleurs appris ces possibilités de l'assembleur.

et moi, je n'ai même pas trouvé en cherchant dans l'aide. C'est un truc qui m'a manqué bien souvent et dont je regrettais que MPASM ne fournisse pas une telle possibilité :mur:
Je crois que je n'arriverai pas à percer tous les secrets de cet assembleur
Merci encore
Cordialement

JJE

C'est pas parcequ'on n'a rien à dire qu'il faut fermer sa G....e

satinas
Expert
Expert
Messages : 1225
Enregistré en : novembre 2015

encore un soucis avec MPASM

Messagepar satinas » lun. 13 avr. 2020 11:06

Si toi tu connais pas, alors qui va connaître, tu es celui qui utilise le plus en détail les capacités de l'assembleur. C'est vrai que mettre des suffixes variables dans une étiquette de macro, c'est un peu audacieux, mais tant que ça marche.
Dans la doc il y a tout de même cela :
#v(expr)
Return the integer value of expr. Typically used to create unique variable names with common prefixes or suffixes. Cannot be used in conditional assembly directives (e.g. ifdef, while).


Tu es sûr que ça marche ? :-)

viewtopic.php?p=12846

JJE
Passioné
Passioné
Messages : 399
Enregistré en : novembre 2017
Localisation : Picardie

encore un soucis avec MPASM

Messagepar JJE » lun. 13 avr. 2020 15:09

Salut satinas,
satinas a écrit :Source du message Typically used to create unique variable names

Remarquer qu'ici, il ne s'agit pas de noms de variables, mais d'adresse d'instruction.
Je vais montrer ci-dessous un peu plus bizarre. Fort de tes suggestions, j'ai tenté ça :

Code : Tout sélectionner

    #DEFINE TMR0_RESTE_BCL0  TMR0_Nb_Cycles
    variable i = 1
    while i
<=8
        
#DEFINE TMR0_NB_PASSAGES_BCL#v(i)  TMR0_RESTE_BCL#v(i-1)/((256*256)+TMR0_NB_Cycles_Perdus_Bcl#v(i))
        #DEFINE TMR0_DERNIER_BCL#v(i)  (TMR0_RESTE_BCL#v(i-1)-TMR0_NB_PASSAGES_BCL#v(i)*((256*256)+ TMR0_NB_Cycles_Perdus_Bcl#v(i)))/(256+TMR0_NB_Cycles_Perdus_Bcl#v(i))
        #DEFINE TMR0_RESTE_BCL#v(i)  TMR0_RESTE_BCL#v(i-1)-TMR0_NB_PASSAGES_BCL#v(i)*((256*256)+ TMR0_NB_Cycles_Perdus_Bcl#v(i))-TMR0_NB_PASSAGES_BCL#v(i)*(256+TMR0_NB_Cycles_Perdus_Bcl#v(i))
i set i+1
    endw    

Je trouvais ça assez joli, mais MPASM n'aime pas :
Error[115] ./TMR0.INC 375 : Duplicate label ("TMR0_NB_PASSAGES_BCL#v" or redefining symbol that cannot be redefined)
Error[115] ./TMR0.INC 376 : Duplicate label ("TMR0_DERNIER_BCL#v" or redefining symbol that cannot be redefined)
Error[115] ./TMR0.INC 377 : Duplicate label ("TMR0_RESTE_BCL#v" or redefining symbol that cannot be redefined)

Il y a probablement de bonnes raisons, mais je ne comprends pas pourquoi MPASM ne veut pas développer les #v(i) quand ils sont employés pour compléter des noms de symboles introduits par des #DEFINE :mur: . Ce n'est en fait que du traitement de texte préalable à tout assemblage.
Alors j'ai fait une autre tentative :

Code : Tout sélectionner

    variable TMR0_RESTE_BCL0 = TMR0_Nb_Cycles
    variable i 
= 1
    while i
<=8
        variable TMR0_NB_PASSAGES_BCL
#v(i) = TMR0_RESTE_BCL#v(i-1)/((256*256)+TMR0_NB_Cycles_Perdus_Bcl#v(i))
        variable TMR0_DERNIER_BCL#v(i) = (TMR0_RESTE_BCL#v(i-1)-TMR0_NB_PASSAGES_BCL#v(i)*((256*256)+ TMR0_NB_Cycles_Perdus_Bcl#v(i)))/(256+TMR0_NB_Cycles_Perdus_Bcl#v(i))
        variable TMR0_RESTE_BCL#v(i) = TMR0_RESTE_BCL#v(i-1)-TMR0_NB_PASSAGES_BCL#v(i)*((256*256)+ TMR0_NB_Cycles_Perdus_Bcl#v(i))-TMR0_NB_PASSAGES_BCL#v(i)*(256+TMR0_NB_Cycles_Perdus_Bcl#v(i))
i set i+1
    endw    

Et là, bravo, l'assembleur ne rouspète pas. Mais voilà, j'avais déjà oublié un point dont on parlait il y a peu, les variables sont traitées comme des 32 bits signés et les #DEFINE acceptent des 64 bits. Comme MPASM ne râle pas quant on affecte à une variable une valeur trop grande, j'ai encore perdu un grand moment sur ce point.
Finalement, je vais tenter de revenir à la première solution en me payant le while à la main. 24 lignes que l'assembleur aurait pu écrire pour moi :furieux:
Cordialement

JJE

C'est pas parcequ'on n'a rien à dire qu'il faut fermer sa G....e

satinas
Expert
Expert
Messages : 1225
Enregistré en : novembre 2015

encore un soucis avec MPASM

Messagepar satinas » mar. 14 avr. 2020 08:27

Bonjour JJE,
Les parenthèses font partie de la syntaxe du #define, ce qui permet de faire des macros avec arguments, donc il interprète le v() à sa façon.
On a l'impression que MPASM a récupéré une partie du préprocesseur C en plus de son propre préprocesseur, et les deux cohabitent.

JJE
Passioné
Passioné
Messages : 399
Enregistré en : novembre 2017
Localisation : Picardie

encore un soucis avec MPASM

Messagepar JJE » mar. 14 avr. 2020 12:22

bonjour satinas
satinas a écrit :Source du message On a l'impression que MPASM a récupéré une partie du préprocesseur C en plus de son propre préprocesseur, et les deux cohabitent.

je dirais plutôt mal :sifflotte:
Cordialement

JJE

C'est pas parcequ'on n'a rien à dire qu'il faut fermer sa G....e


Retourner vers « Langage ASM »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 43 invités