Saut inter pages pic 16F876

[invite62afc4d2]

J'ai un problème pour effectuer des sauts inter pages. J'ai déjà essayé plusieurs routines et autres macros mais il semble que le problème vienne d'ailleurs.
En effet, en regardant dans la mémoire programme je m'apperçois que la mise à jour des bits 3 et 4 de PCLATH se fait mais que le programme effectue quand même le saut en page0 plutot qu'en page1

CALL MESS_CLR
PAGE1
GOTO MESSAGE_U

PAGE1 MACRO
BCF PCLATH,4
BSF PCLATH,3
ENDM

MESSAGE_U étant le premier label de la zone 0x800(page1), le programme effectue, à la place, un saut vers INIT, premier label de 0x000 (page0)
-----

[invite092cb13c]

Bonjour
Pour moi cela fonctionne:

	;CALL 	MESS_CLR
	PAGE1
	GOTO 	MESSAGE_U

org 0x800
MESSAGE_U
	nop
	nop

	nop

Mais si tu n'es pas sur de toi, utilises les macros GOTOX, CALLX de Bigonoff qui, elles, supprimeront les warnings de saut interpage.
Gilles

[invite62afc4d2]

J'ai justement essayé toutes ces macros mais je n'ai eu que des messages d'erreur. Alors je ne sais pas si dans ma config tout est bon peut-être qu'il y a une option à activer pour pouvoir effectuer des sauts longs....

[RISC]

Salut,

Il faut, je coirs, que les definitions de MACROS se trouvent AVANT leur utilisation.
En general on place les macros avant le programme dans les fichiers sources

a+

[A voir en vidéo sur Futura]

[invite092cb13c]

J'ai justement essayé toutes ces macros mais je n'ai eu que des messages d'erreur.

Bonjour
Il serait bien de donner les messages d'erreurs que tu obtiens.
Tu devrais aussi relire dans le cours part2 de Bigonoff, chapitre 4.3, la partie ou il explique les sauts inter-pages et la justification de ses routines.
Gilles

[invite62afc4d2]

Merci pour vos réponses.
@RISC: mes macros sont bien déclarées et elles fonctionnent pour passer d'une banque à l'autre notamement pour paramétrer TRISx.
D'ailleurs si je regarde dans la "program memory" je peux voir qu'il remplace bien le label de la macro par les opérations bcf PCLATH,4 et BSF PCLATH,3 mais le programme continue de pointer sur la page0.

Sinon pour donner un exemple concret je vous mets une copie de mon code.

DEBUT
CLRWDT
BSF BLANK
BSF LATCH
PAGE1
BTFSC SW1
INCF NOM_BASE_1,F
BTFSC SW1
GOTO TEST_NOM_BASE
BTFSC SW2
DECF NOM_BASE_1,F
BTFSC SW2
GOTO TEST_NOM_BASE
PAGE0
GOTO DEBUT

Donc normalement si je mets TEST_NOM_BASE en org 0x0800, le programme devrait effectuer le saut sans problème. Pourtant, la mise à jour des bits 3 et 4 se fait mais le saut s'effectue toujours en page0 et non en page1.

[invite092cb13c]

Bonjour
J'ai testé ton second programme, il fonctionne tres bien pour moi, il y a certainement autre chose.

DEBUT
	CLRWDT
	;BSF 	BLANK
	;BSF 	LATCH
	PAGE1
	BTFSC 	SW1
	;INCF 	NOM_BASE_1,F
	BTFSC 	SW1
	GOTO 	TEST_NOM_BASE
	BTFSC 	SW1
	;DECF 	NOM_BASE_1,F
	BTFSC 	SW1
	GOTO 	TEST_NOM_BASE
	PAGE0
	GOTO 	DEBUT





org 0x800
MESSAGE_U
	nop
TEST_NOM_BASE
	nop
	nop

Postes en piece jointe ton programme complet.
Gilles

[invite62afc4d2]

Merci de vos réponses. J'envoie les fichiers de mon programme. Donc, pour le moment, tout le programme se passe en page0 sauf le dernier message. J'ai recompilé avec la version 6.3 mais toujous pas concluant donc j'espère que vous saurez m'aider. Merci

[invite092cb13c]

Bonjour
Dans ton programme main.asm, avant la ligne " GOTO TEST_NOM_BASE", il faudrait peut être utiliser une de tes macros, par exemple "PAGE1" car "TEST_NOM_BASE" est à l'adresse 0x82B, on est bien en page 1. C'est à vérifier dans "View", "Program Memory".Il ne faut pas se fier à "GOTO 0x2B" car c'est toi qui doit positionner PCLATH pour completer l'adresse de saut long, 0X2B (ton adresse)+ 0X800 (complement d'adresse).
Et utilises les routines de Bigonoff qui t'eviteraient ces erreurs et t'epargneraient la tripotée de warning "Crossing page boundary" ainsi que certaines erreurs beaucoup plus incidieuses que les tiennes, du genre un test de bit avant ta macro, asses vicieuse à debugger.
Gilles

[invitef86a6203]

ORG 0000H

Start
movlw HIGH MyProc1 ; 08h
movwf PCLATH
call MyProc1
clrf PCLATH      ; 00
goto Start


ORG 0800H
MyProc1
movlw HIGH MyProc2 ; 0x10
movwf PCLATH
call MyProc2

movlw HIGH MyProc1 ; 0x08
movwf PCLATH

; TEMPO
movlw	0xF0 ; boucles
movwf	0x20  ; registre
loop
	decfsz	0x20,f
	goto 	loop
RET

ORG 1000H
MyProc2
RET

[invite62afc4d2]

Merci pour toutes vos réponses. Mon problème est réglé. J'ai mis tous mes fichiers .inc en page1 en appliquant mes petites macros et tout fonctionne sans problème. J'ai juste encore les warnings mais tant que ça fonctionne ça me va. Merci à tous.

[invite29971eb1]

Je ne comprendrai décidément jamais l'acharnement thérapeutique sur ces PIC16.....

[Forhorse]

Tout simplement parce que dans 80% des bidouilles d'amateurs, ils sont largement assez puissant.

[invite29971eb1]

Tout simplement parce que dans 80% des bidouilles d'amateurs, ils sont largement assez puissant.

Si on suit ton raisonnement, on roulerait tous en Lada, mais au prix d'une Renault, puisque les PIC ne se distinguent pas spécialement par le prix.

A quoi bon prendre des micros lents, paginés, avec 3 instructions qui se battent en duel ou pour le même prix on en a avec tous les registres au même endroit, bien plus d'instructions, et une vitesse convenable.

Que la garde prétorienne se calme, car je serais prêt à recommander un PIC18 au lieu de ces trucs

Je vais pas déclencher encore une guéguerre mais bon sang, il faut quand même reconnaitre que c'est vraiment archaïque comme archi

[Forhorse]

Parce que les PIC sont plus facilement disponibles, tous les fournisseurs de composants electronique grand publique en ont, depuis des années. Et même dans les petites boutiques au coin de la rue tu as une chance d'en trouver.
C'est loin d'être le cas pour d'autres marques/gammes.

Après on peut aussi prendre un Core2Quad pour faire clignoter une LED...

[invitee05a3fcc]

Parce que les PIC sont plus facilement disponibles,

Ce n'est pas parce que le distributeur a des UA741 sur les étagères .... qu'il faut les acheter !

[Forhorse]

C'est sûr... mais si tu veux un AOP et qu'il a que ça ?
- Soit tu prend le UA741
- Soit tu va voir ailleur... quand c'est possible.

[inviteeb160de1]

Je vais pas déclencher encore une guéguerre mais bon sang, il faut quand même reconnaitre que c'est vraiment archaïque comme archi

Faudra juste que tu comprennes, un jour peut etre, que l'aspect performance pure n’intéresse que très peu de personnes, que ces micros suffisent pour la majorité des applis amateur, que programmer en assembleur PIC est tellement simple que c'en est un plaisir (hier je me suis fait 100 lignes sur un 12F, c'etait pas désagréable), qu'il y a les cours de bigonoff, qu'ils sont bien plus faciles à approvisionner, etc...

Aurélien

[invite62afc4d2]

En fait, si j'utilise le 16F876 c'est parce qu'il m'a été imposé dans le cadre d'un projet. Y a 3 semaines j'avais jamais fait de pic en assembler. Jusqu'à maintenant j'ai toujours travaillé sur 8051 en assembler un pet et beaucoup en C et c'est vrai que c'est beaucoup plus évident que ce système de pages et de zones de variables communes et non communes etc...

[invite29971eb1]

Faudra juste que tu comprennes, un jour peut etre, que l'aspect performance pure n’intéresse que très peu de personnes, que ces micros suffisent pour la majorité des applis amateur, que programmer en assembleur PIC est tellement simple que c'en est un plaisir (hier je me suis fait 100 lignes sur un 12F, c'etait pas désagréable), qu'il y a les cours de bigonoff, qu'ils sont bien plus faciles à approvisionner, etc...

Aurélien

Programmer en assembleur PIC est simple????? y'a que RISC pour sortir ce genre d’âneries....

T'as essayé d'autres marques avant de sortir de telles énormités?

[inviteeb160de1]

J'ai essayé sur AVR et sur des 8 bits Cypress (et sur des 68000 à l'ecole...). Alors bien sur je maitrisais tres bien celui des PIC avant, et je n'ai pas mis le meme effort, mais j'aime la simplicité, et si bien evidemment les performances en patissent sur un 16F, je n'ai plus besoin de lire l'instruction set plusieurs années apres...

[invite092cb13c]

Je ne comprendrai décidément jamais l'acharnement thérapeutique sur ces PIC16.....

Bonjour
Pour ma part, ce qui me semble incomprehensible, c'est de trouver complexe ces histoires de BANK et page mémoire que denigre systematiquement l'ami ftorama, ce serait un debutant ou un incompétent, on pourrait trouver cela normal, mais franchement je ne doute pas que ftorama soit capable d'aborder des problemes bien plus delicat que ces peccadilles.
Gilles

[invite98765423456]

Bonjour
Pour ma part, ce qui me semble incomprehensible, c'est de trouver complexe ces histoires de BANK et page mémoire que denigre systematiquement l'ami ftorama, ce serait un debutant ou un incompétent, on pourrait trouver cela normal, mais franchement je ne doute pas que ftorama soit capable d'aborder des problemes bien plus delicat que ces peccadilles.
Gilles

Ce n'est pas spécialement complexe, c'est plutôt lamentable et cela n'apporte strictement rien . Cela n'existe d'ailleurs (plus) que sur les pics <=16 et il ne faut pas faire de gros efforts pour trouver sur le net des gens qui n'ont jamais bien maitrisé les mécanismes de changement de page flash/bank ram, et qui sont bien contents d'avoir changé pour autre chose. (on ne trouvera qu'aurelien pour dire que c'est un avantage mais bon, il n'y a pas pire sourd que celui qui ne veut pas entendre) . Pour illustrer, même sur pic 18, on a pu voir une floppéée de posts sur ce site ou sur abc où créer un tableau de plus de 256 octets (même en C) posait des problèmes...(??)
L'assembleur pic <=16 très simple ? Je dirais plutôt très pauvre. Quand il faut 4 ou 5 instructions pour faire ce que fait une autre instruction sur d'autres µC (branchements conditionnels par exemple), sauts inter pages, multiplication, … etc, cela occupe aussi d'autant plus de flash (qui est déjà très limitée sur ces pics) et prend d'autant plus de temps d'exécution.
Ce qui est toujours aussi rigolo, ce sont ces fichiers «maquette» où il y a déjà une centaine d'instructions (dont pas mal pour la gestion des interruptions) qui ne servent strictement à rien avant de pouvoir écrire la première ligne de programme utile.
Bref, l’assembleur pic simple ? Non, c'est bien connu que ce qui est «simple» sur les pics <=16, c'est le hardware, la difficulté est reportée sur la programmation, (beaucoup de débutants ne s'aperçoivent pas de cet aspect , ce qui génère ces erreurs/difficultés de gestion de «pages»/ «banques») et cela, à part des raisons économiques éventuelles, n'a strictement aucune valeur ajoutée, que du contraire.

th

[Forhorse]

En même temps avec les compilateurs de haut niveau (C/Basic/etc...) c'est quasi transparent.
Depuis que je programme en Basic je n'ai jamais eu à me soucier vraiment des changements de bank/page. Donc pour moi c'est un faux probleme.

[invitef26bdcba]

Pour illustrer, même sur pic 18, on a pu voir une floppéée de posts sur ce site ou sur abc où créer un tableau de plus de 256 octets (même en C) posait des problèmes...(??)

Tu as vu çà où que cela pose problème d'utiliser un tableau de plus de 256 octets sur PIC18???

Un tableau de 2Ko ou 10 octets se traite identiquement de la même manière sans devoir gérer quoi que cela tant en lecture qu'en écriture!

Et puis, comme le souligne très bien Forhorse, je trouve assez marrant de lire que les points qui font toujours vos choux gras dans vos interventions sont transparents quand on utilise les langages que vous prônez!

[invite29971eb1]

On va pas encore monter ça en mayonnaise, RaphX306, le premier concerné a très bien résumé la situation:

En fait, si j'utilise le 16F876 c'est parce qu'il m'a été imposé dans le cadre d'un projet. Y a 3 semaines j'avais jamais fait de pic en assembler. Jusqu'à maintenant j'ai toujours travaillé sur 8051 en assembler un pet et beaucoup en C et c'est vrai que c'est beaucoup plus évident que ce système de pages et de zones de variables communes et non communes etc...

Et quant à parler des langages de haut niveau sur les PIC16, ce n'est qu'un cataplasme sur une jambe de bois.

[inviteeb160de1]

on ne trouvera qu'aurelien pour dire que c'est un avantage mais bon, il n'y a pas pire sourd que celui qui ne veut pas entendre

Mr mauvaise foi, je n'ai parlé que de la simplicité des instructions ASM PIC. Je n'ai pas parlé des sauts mémoire liés à l'architecture comme étant des avantages, et honnetemment, parmi tous les programmes ASM que j'ai fait (c'est à dire à chaque fois que je programmais un 16F), ça ne m'est arrivé que deux fois de m'y confronter, et en réflchissant un peu ce n'est pas insurmontable.
Alors relis bien mes propos avant de dénigrer ma personne.

Tu as vu çà où que cela pose problème d'utiliser un tableau de plus de 256 octets sur PIC18???

Heu là je confirme, sous C18 c'est une calamité, faut refaire le fichier de link, faut déclarer de maniere spéciale le tableau, etc....Ca m'a toujours pris du temps, et je n'ai jamais compris pourquoi c'etait tant le bordel.

Et quant à parler des langages de haut niveau sur les PIC16, ce n'est qu'un cataplasme sur une jambe de bois.

Là je suis d'accord, mais pour des applis sans performance c'est un gain de temps considérable.

Aurélien

[Forhorse]

Faut se dire aussi que l'architecture PIC16 à quasi 20 ans.
A l'epoque de leur sortie, c'était "pas trop mal" comparé à la concurence (pas toujours disponible chez les revendeurs accessibles aux particuliers) et avec des outils de dev accessible a monsieur tout le monde.
Du coup, pas mal de monde à gardé l'habitude de les utiliser (certains continuent même d'utiliser le 16F84 archi obsolète et buggé...)

C'est un peu comme de vouloir comparer un Renault 4L et le dernier Kangoo... pourtant tu trouveras encore "pas mal" de gens qui roulent en 4L et qui en sont satisfait...

[invite29971eb1]

Faut se dire aussi que l'architecture PIC16 à quasi 20 ans.
A l'epoque de leur sortie, c'était "pas trop mal" comparé à la concurence (pas toujours disponible chez les revendeurs accessibles aux particuliers) et avec des outils de dev accessible a monsieur tout le monde.

Perso, quand j'ai du faire mon choix de démarrage, j'avais le choix entre des AVR à mémoire Flash et des PIC OTP ou à fenêtre UV. Et c'était en 99-2000.

C'est un peu comme de vouloir comparer un Renault 4L et le dernier Kangoo... pourtant tu trouveras encore "pas mal" de gens qui roulent en 4L et qui en sont satisfait...

On est bien d'accord, mais dans ce cas, à quoi bon défendre encore la 4L et surtout la considérer comme encore dans la course....à part pour les collectionneurs.

[Forhorse]

Quand j'ai fait mon choix en 96/97 y'avait pas vraiment de choix en fait...
C'était soit du 68HC11 soit du PIC16
Et chez Selectronic/Conrad où je me fournissait exclusivement à l'epoque, le choix et les prix en PIC était plus interessant.
Je pense qu'il en a été de même pour beaucoup d'autres personnes et dans pas mal d'autres pays.