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 ---
Se débarrasser de la gestion des banques de RAM sur des PIC mid-range
L'usage usuel de la RAM mémoire consiste
1. à désigner un ou plusieurs octets par une directive CBLOCK.
2. à utiliser l'étiquette ainsi définie pour définir modifier ou exploiter la valeur de cet (ces) octet(s).
Ceci permet à l'assembleur d'interdire le réemploi du même espace mémoire.
Il est attribué par l'assembleur à cette étiquette une valeur codée sur 9 bits. Cependant, dans le code généré, seuls les 7 bits de bas poids sont utilisés, les bits 8 et 7 devant être les valeurs des bits RP1 et RP0 de STATUS. Ces bits n'étant connus qu'à l'exécution, l'assembleur n'a pas la possibilité de savoir s'ils seront corrects, d'où le fâmeux message d'avertissement 302. Remarquons qu'il est très partial car il ne signale que l'usage d'une étiquette définie dans une banque différente de la banque 0. En fait, à chaque fois que l'on utilise une étiquette désignant un octet de la RAM, il faut se poser la question "suis-je dans la bonne banque ?"
Comme l'assembleur ne s'intéresse pas (ou peu) aux bits 8 et 7 de cette étiquette, on peut essayer de s'en passer. Notre maître BigonOFF en donne d'ailleurs le principe pour les adresses en mémoire programme dans la partie 2 de son cours que l'on peut trouver ici.
pour faire simple, prenons l'exemple d'un programme qui calcule l'opposé d'un nombre codé en 8 bits signés (en complément à 1) qui serait l'équivalent d'une instruction B = -A d'un langage évolué (sans se préoccuper du cas de débordement -128).
Si le programme a défini V comme une constante <=0x7F (par un EQU ou un define), le sous-programme va travailler sur l'octet mémoire de cette adresse située dans la banque contenant A et B, quelle qu'elle soit. Il suffit que le programmeur le sache et n'utilise pas l'octet de cette adresse de chacune des banques du processeur pour lequel il écrit son programme. Il n'est probablement pas inutile de l'y aider.
réservera le dernier octet de chaque banque d'un processeur 16F876 (hors zone commune) par exemple.
Remarquons que la directive CBLOCK est très souple puisqu'elle peut être employée à peu près n'importe où dans le fichier source (avant tout utilisation des étiquettes qu'elle définit) bien que l'usage veut qu'on s'en serve au début du fichier source. Remarquons aussi que la présence d'une étiquette est imposée par MPASM ce qui est un peu dommage car dans l'exemple, on n'en a pas besoin.
Une dernière observation doit être faite : L'octet désigné par V est libre pour tout usage entre deux appels à ce sous-programme. En particulier il peut être utilisé par tout sous-programme utilisant la même technique et n'appelant pas (directement ou indirectement) opp_8bs_code, ce qui minimise le "gâchi".
Il n'est pas non plus inutile d'observer que les 5 lignes du code d'appel peuvent être encapsulées dans une macro :
ce qui limitera, dans le source, à une seule ligne
le code qui transfère l'opposé de A dans B quelle que soit la banque mémoire contenant A ET B.
Le programmeur doit toujours cependant
Dans un prochain papier, je donnerai quelques indications pour simplifier cela pour un réemploi par soi même ou un autre.
1. à désigner un ou plusieurs octets par une directive CBLOCK.
2. à utiliser l'étiquette ainsi définie pour définir modifier ou exploiter la valeur de cet (ces) octet(s).
Ceci permet à l'assembleur d'interdire le réemploi du même espace mémoire.
Il est attribué par l'assembleur à cette étiquette une valeur codée sur 9 bits. Cependant, dans le code généré, seuls les 7 bits de bas poids sont utilisés, les bits 8 et 7 devant être les valeurs des bits RP1 et RP0 de STATUS. Ces bits n'étant connus qu'à l'exécution, l'assembleur n'a pas la possibilité de savoir s'ils seront corrects, d'où le fâmeux message d'avertissement 302. Remarquons qu'il est très partial car il ne signale que l'usage d'une étiquette définie dans une banque différente de la banque 0. En fait, à chaque fois que l'on utilise une étiquette désignant un octet de la RAM, il faut se poser la question "suis-je dans la bonne banque ?"
Comme l'assembleur ne s'intéresse pas (ou peu) aux bits 8 et 7 de cette étiquette, on peut essayer de s'en passer. Notre maître BigonOFF en donne d'ailleurs le principe pour les adresses en mémoire programme dans la partie 2 de son cours que l'on peut trouver ici.
pour faire simple, prenons l'exemple d'un programme qui calcule l'opposé d'un nombre codé en 8 bits signés (en complément à 1) qui serait l'équivalent d'une instruction B = -A d'un langage évolué (sans se préoccuper du cas de débordement -128).
Code : Tout sélectionner
; on suppose que les étiquettes A et B sont dans la banque active
movf A,W
movwf V
call opp_8bs_code
movf V,W
movwf B
.../...
opp_8bs_code
comf V, f
incf V, f
return
Si le programme a défini V comme une constante <=0x7F (par un EQU ou un define), le sous-programme va travailler sur l'octet mémoire de cette adresse située dans la banque contenant A et B, quelle qu'elle soit. Il suffit que le programmeur le sache et n'utilise pas l'octet de cette adresse de chacune des banques du processeur pour lequel il écrit son programme. Il n'est probablement pas inutile de l'y aider.
Code : Tout sélectionner
define V 0x6F ; ou V EQU 0x6F
CBLOCK V
opp_8bs_code_B0 res : 1
endc
CBLOCK V + 0x80
opp_8bs_code_B1 res : 1
endc
CBLOCK V + 0x100
opp_8bs_code_B1 res : 1
endc
CBLOCK V + 0x180
opp_8bs_code_B1 res : 1
endc
réservera le dernier octet de chaque banque d'un processeur 16F876 (hors zone commune) par exemple.
Remarquons que la directive CBLOCK est très souple puisqu'elle peut être employée à peu près n'importe où dans le fichier source (avant tout utilisation des étiquettes qu'elle définit) bien que l'usage veut qu'on s'en serve au début du fichier source. Remarquons aussi que la présence d'une étiquette est imposée par MPASM ce qui est un peu dommage car dans l'exemple, on n'en a pas besoin.
Une dernière observation doit être faite : L'octet désigné par V est libre pour tout usage entre deux appels à ce sous-programme. En particulier il peut être utilisé par tout sous-programme utilisant la même technique et n'appelant pas (directement ou indirectement) opp_8bs_code, ce qui minimise le "gâchi".
Il n'est pas non plus inutile d'observer que les 5 lignes du code d'appel peuvent être encapsulées dans une macro :
Code : Tout sélectionner
opp_8bs macro X, Y
movf X,W
movwf V
call opp_8bs_code
movf V,W
movwf Y
endm
ce qui limitera, dans le source, à une seule ligne
Code : Tout sélectionner
opp_8bs A, B
le code qui transfère l'opposé de A dans B quelle que soit la banque mémoire contenant A ET B.
Le programmeur doit toujours cependant
- réserver la mémoire nécessaire et définir l'étiquette V
- coder le sous-programme
- écrire la macro qui appelle le sous-programme
Dans un prochain papier, je donnerai quelques indications pour simplifier cela pour un réemploi par soi même ou un autre.
Retourner vers « Langage ASM »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 88 invités