problème MPLAB SIM v8.92

[Nadril]

Bonjour à tout le forum.
J'ai installé MPLAB IDE v8.92 comme vous me l'avez conseillé et vous en remercie. J'ai cependant un soucis avec MPLAB SIM.
Il fonctionne correctement temps que je ne rentre pas en interruption. En reprenant le programme principal à la sortie d'interruption, si
celui-ci rencontre un saut,(goto ou call) il retourne à l'origine (0x000) et passe en run, le pointeur de ligne vert disparait. Il ne faut alors quitter MPLAB IDE pour reprendre la main sur le programme. J'utilise Windows 10 home 64 bits. L'un de vous a-t-il une solution ?

[francois77]

Bonjour

Le plus simple c'est de mettre votre programme sur le site pour que nous puissions regarder votre codage

Cdt,

Francois

[Nadril]

Voilà, voilà.....François!

Fichierasm.odt

[francois77]

Bonsoir,
Pas le courage pour ce soir
Regarde les cours de Maitre BIGONOFF, j’ai démarré par lui
A+
Francois

[satinas]

Bonjour à tous,

Il en faut pas beaucoup pour que le programme perde la boule :)

Code : Tout sélectionner

; restaurer les registres
      MOVLW      PCLATH_temp      ; recharger ancien PCLATH
      MOVWF      PCLATH           ; le restaurer
      MOVLW      FSR_temp         ; charger FSR sauvé
      MOVWF      FSR              ; restaurer FSR


Le simulateur permet de détecter ce problème grâce au mode pas à pas. J'ai dû au préalable modifier le registre OPTION_REG pour sélectionner l'horloge système comme source du timer0, pour qu'une interruption se déclenche.

Avec un programme aussi long, il est conseillé de faire des macros et pseudo-instructions pour éviter ce genre d'erreur, souvent d'inattention.
Il semble qu'il manque en début de programme la directive "radix dec" permettant d'activer le mode décimal par défaut (voir les warnings à l'assemblage).
Est-il vraiment nécessaire de toucher à GIE en cours d'exécution du programme ?

[Temps-x]

Bonsoir Nadril, francois77, satinas, et tout le forum,

Source du message celui-ci rencontre un saut,(goto ou call) il retourne à l'origine (0x000) et passe en run, le pointeur de ligne vert disparait.

Il y a plusieurs raison à ce problème, mais avant d'aller plus loin corrige ses lignes

T4.1ms MOVLW 175 ; boucle de 4,102ms

Warning[202] D:\DATAPIC\PICSOUR\16F877\DIVERS\MICROCONS.ASM 784 : Argument out of range. Least significant bits used.

T40 MOVLW 165 ; boucle de 40µs

Warning[202] D:\DATAPIC\PICSOUR\16F877\DIVERS\MICROCONS.ASM 813 : Argument out of range. Least significant bits used.

Source du message Il semble qu'il manque en début de programme la directive "radix dec"

Exact, d’où l’avertissement du compilateur qui ne sait pas si c'est exprimé en hexadécimal ou décimal

Pour info

Code : Tout sélectionner


    Errorlevel-302                        ; Supprime le message "Ensure that bank bits are correct" 

    radix dec                             ; par defaut en mode décimal

    list p=16F877A                        ; processeur utilisé 

    #include <p16F877A.inc>               ; Définitions des constantes

    __CONFIG   _CP_OFF & _DEBUG_OFF & _WRT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _PWRTE_ON & _WDT_OFF & _HS_OSC 



A par cela le programme se compile correctement, je regarderais le reste demain, car vu l'heure je vais dormir

A+

[Nadril]

Bonjour à francois77, satinas, Temps-x et tout le forum
Je vous remercie pour vos retours rapide.
Je vais essayer de réponse et d'y voir un peut plus claire dans mon embrouille !

Je ne connais pas cette commande « radix dec », avec MPLAB je fais :
project > build options > project > MPASM assembler > général > défaut radix > je coche décimal c'est pas la même chose ?
Pour moi quand j'écris le nombre 21 > 0x15 c'est de l'hexadécimal et quand j'écris le nombre 21 c'est du décimal .

Pour les Warning[202] je suis plus préoccupé !
Quand j’appuie sur la touche F10 du clavier, j’obtiens dans la fenêtre "output" > "build" :
BUILD SUCCEEDED construction réussie (sans avertissement)
Dommage MPLAB ne veux pas que je fasse copier/coller, Je l'aurai publié.
Cela voudrait dire, puisque Temps-x a trouvé des Warning[202], que j'ai un mauvais réglage ? Non !
Voila ! Merci à tous de votre aide !

[satinas]

Bonjour
Quelques explications complémentaires, quand tu ne comprends pas ce que j'écris, dis le on gagnera du temps :)

Lorsque tu écris "MOVLW PCLATH_temp" en fin de routine d'interruption, tu charges dans W l'adresse PCLATH_temp, c'est à dire 0x73, et ensuite tu mets cela dans PCLATH. Il ne faut pas t'étonner si après l'interruption le programme saute lors d'un GOTO/CALL à une adresse incorrecte. Il faut faire "MOVF PCLATH_temp,W", là tu charges bien dans W la valeur stockée à l'adresse PCLATH_temp, et pas l'adresse elle-même.
Idem pour "MOVLW FSR_temp".

Pour le radix si tu n'as pas de warning à l'assemblage, c'est bon. Tu l'as bien bien déclaré dans build options mais c'est mieux de le faire directement en début de programme sous forme d'une directive "radix dec", ainsi on met tout dans le fichier source. Avec cette directive, Temps-x et moi on aurait pas eu les warnings, comme quoi c'est plus mieux :)

[Nadril]

Ah !........purée ! movlw et movfw
J'ai pas fait gaffe, ni dans mon programme, ni sur tes écris sanitas, tu n'en vois désolé.
Bon du coup movfw, à l'avenir c'est fini, ce sera movf registre, w
En espérant que j'y fasse plus attention.
Autrement j'ai fais les correctifs et testé c'est OK !
Grands merci à vous et désolé de vous avoir fait perdre votre temps.
nadril

[satinas]

C'est quoi movfw une macro ? c'est vrai que la confusion avec movlw est possible, bien que instructions et macros sont affichées avec 2 couleurs distinctes. Sauf que ce n'est pas le cas pour movfw qui est une pseudo-instruction codée en dur dans masm.exe
Pourquoi dévalider les interruptions lors de l'affichage lcd ?