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
piège de MPASM ou inattention de l'utilisateur modifié le 19/05
Bonsoir à tous,
La modification consiste en l'ajout d'un point (".") devant le 16 de la boucle while (2fois) pour dire à l'assembleur que le nombre qui suit est écrit en base dix.
Message initial corrigé :
Dans mon post relatif à la mise en oeuvre d'un afficheur 7 segments, je définis une routine de conversion d'un chiffre hexa en ce qu'il faut envoyer à l'afficheur pour voir ce chiffre. Ce post se termine par
Je la rappelle ci-dessous :
Elle se termine par
C'était sans tenir compte des priorités des opérateurs mis en oeuvre, ce que j'ai découvert à mes dépends.
L'opérateur != étant plus prioritaire que l'opérateur & (voir documentation de MPASM), il est effectué en premier, donc, l'expression de test est calculée comme :
ce que je ne voulais pas du tout écrire
il faut donc forcer la priorité du & et écrire
Acceptez toutes mes excuses pour ce défaut qui n'est probablement pas le seul
Une bonne méthode pour se prémunir de ce risque est de forcer des parenthèses même inutiles.
à la réflexion, cette méthode qui laisse le soin à l'utilisateur de déplacer le code pour faire disparaître le défaut, ne me satisfait pas totalement, je préfère la suivante consistant à faire faire le travail à l'assembleur en lui demandant d'insérer des nop en quantité satisfaisante :
Ces quelques lignes ajoutées
font le travail.
Le test de fin de table fait un peu "ceinture et bretelles" mais comme il était écrit, .../... mieux vaut une double sécurité.
Il pourrait être intéressant dans la boucle While d'ajouter un message
pour en informer l'utilisateur qui pourrait alors prendre les choses en main, cette méthode pouvant aller jusqu'à pratiquement doubler la taille de la table
En relisant ce code je m'aperçois d'un deuxième défaut, il manque en début de sous-programme
absence qui pourrait avoir des effets désastreux difficiles à trouver
La modification consiste en l'ajout d'un point (".") devant le 16 de la boucle while (2fois) pour dire à l'assembleur que le nombre qui suit est écrit en base dix.
Message initial corrigé :
Dans mon post relatif à la mise en oeuvre d'un afficheur 7 segments, je définis une routine de conversion d'un chiffre hexa en ce qu'il faut envoyer à l'afficheur pour voir ce chiffre. Ce post se termine par
, j'ai bien fait d'être prudent.JJE a écrit :Source du message On pourra constater que toutes les précautions sont prises (du moins je pense) .../...
Je la rappelle ci-dessous :
► Afficher le texte
Elle se termine par
Code : Tout sélectionner
if TDS_Convertir_1 & 0xff00 != (TDS_FinConvertir-1) & 0xff00
messg " "
error "La table TDS_Convertir franchit une frontière de bloc"
messg " "
endif
C'était sans tenir compte des priorités des opérateurs mis en oeuvre, ce que j'ai découvert à mes dépends.
L'opérateur != étant plus prioritaire que l'opérateur & (voir documentation de MPASM), il est effectué en premier, donc, l'expression de test est calculée comme :
Code : Tout sélectionner
TDS_Convertir_1 & (0xff00 != (TDS_FinConvertir-1)) & 0xff00
il faut donc forcer la priorité du & et écrire
Code : Tout sélectionner
if (TDS_Convertir_1 & 0xff00) != ((TDS_FinConvertir-1) & 0xff00)
messg " "
error "La table TDS_Convertir franchit une frontière de bloc"
messg " "
endif
Acceptez toutes mes excuses pour ce défaut qui n'est probablement pas le seul
Une bonne méthode pour se prémunir de ce risque est de forcer des parenthèses même inutiles.
à la réflexion, cette méthode qui laisse le soin à l'utilisateur de déplacer le code pour faire disparaître le défaut, ne me satisfait pas totalement, je préfère la suivante consistant à faire faire le travail à l'assembleur en lui demandant d'insérer des nop en quantité satisfaisante :
Code : Tout sélectionner
TDS_Convertir
; convertir la valeur présente dans W <0 à 15> en la valeur à envoyer
; au HC4094 pour un affichage de ce TDS_chiffre sur le TDS0316
movwf TDS_Temp1
; PCLATH<4,3> est sûrement OK mais
; PCLATH<2,0> risque de ne pas l'être
; réglons ce problème
movlw high(TDS_Convertir_1)
movwf PCLATH
; et récupérons le paramètre
movf TDS_Temp1, w
andlw 0x0f
variable v = $+1
while high(v) != high(v+.16)
v +=1
nop
endw
addwf PCL,f
TDS_Convertir_1
retlw TDS_chiffre0
retlw TDS_chiffre1
.../...
TDS_FinConvertir
if (TDS_Convertir_1 & 0xff00) != ((TDS_FinConvertir-1) & 0xff00)
messg " "
error "La table TDS_Convertir franchit une frontière de bloc"
messg " "
endif
Ces quelques lignes ajoutées
Code : Tout sélectionner
variable v = $+1
while high(v) != high(v+.16)
v +=1
nop
endw
font le travail.
Le test de fin de table fait un peu "ceinture et bretelles" mais comme il était écrit, .../... mieux vaut une double sécurité.
Il pourrait être intéressant dans la boucle While d'ajouter un message
Code : Tout sélectionner
messg "nop ajouté dans la table TDS_convertir"
pour en informer l'utilisateur qui pourrait alors prendre les choses en main, cette méthode pouvant aller jusqu'à pratiquement doubler la taille de la table
En relisant ce code je m'aperçois d'un deuxième défaut, il manque en début de sous-programme
Code : Tout sélectionner
BANKSELX TDS_Temp1
absence qui pourrait avoir des effets désastreux difficiles à trouver
Retourner vers « Langage ASM »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 55 invités