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 ---
- 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 ---
Modérateur : mazertoc
encore un soucis avec MPASM
Bonjour à tous,
La macro suivante :
me pose des problèmes d'assemblage que je ne comprends pas:
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.
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.
encore un soucis avec MPASM
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.
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.
encore un soucis avec MPASM
encore un soucis avec MPASM
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é
Je crois que je n'arriverai pas à percer tous les secrets de cet assembleur
Merci encore
encore un soucis avec MPASM
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
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
encore un soucis avec MPASM
Salut satinas,
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 :
Je trouvais ça assez joli, mais MPASM n'aime pas :
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 . Ce n'est en fait que du traitement de texte préalable à tout assemblage.
Alors j'ai fait une autre tentative :
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
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 . 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
encore un soucis avec MPASM
encore un soucis avec MPASM
bonjour satinas
je dirais plutôt mal
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
Retourner vers « Langage ASM »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 129 invités