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
Attention, bug sur Pic18F46k22 & Pic18F26k22
Bonsoir tout le forum,
J'ai cherché des heures et des heures pourquoi mon écran OLED 128x64 été figé, de plus le microcontrôleur ne fonctionnait plus.
La réponse fut trouvé avec le datasheet du errata de chez Microchip, qui est tout en anglais j'explique pour ceux qui ne saurait pas ce que c'est un errata
C'est un bug ou des bugs qui existe dans le microcontrôleur, l'errata sert à le résoudre ou le signaler.
Microchip a le mérite d’annoncer clairement les bugs trouvés et de donner le cas échéant des méthodes pour le contourner ou éviter son apparition.
Dans le datasheet du errata il parle de plusieurs bug sur le Pic18F46k22 & Pic18F26k22, je vous les laisses les découvrir.
Je tenais à vous le signaler pour que vous ne passer pas des heures à essayer de comprendre pourquoi votre programme ne tourne pas.
A+
J'ai cherché des heures et des heures pourquoi mon écran OLED 128x64 été figé, de plus le microcontrôleur ne fonctionnait plus.
La réponse fut trouvé avec le datasheet du errata de chez Microchip, qui est tout en anglais j'explique pour ceux qui ne saurait pas ce que c'est un errata
C'est un bug ou des bugs qui existe dans le microcontrôleur, l'errata sert à le résoudre ou le signaler.
Microchip a le mérite d’annoncer clairement les bugs trouvés et de donner le cas échéant des méthodes pour le contourner ou éviter son apparition.
Dans le datasheet du errata il parle de plusieurs bug sur le Pic18F46k22 & Pic18F26k22, je vous les laisses les découvrir.
Je tenais à vous le signaler pour que vous ne passer pas des heures à essayer de comprendre pourquoi votre programme ne tourne pas.
A+
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Modifié en dernier par Temps-x le dim. 26 janv. 2020 13:28, modifié 3 fois.
Attention, bug sur Pic18F46k22 & Pic18F26k22
- paulfjujo
Expert- Messages : 2597
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
Bonjour TempsX et à tous ..
merçi pur l'info
j'utilise beaucoup ce PIC à toutes les sauces, et n'ai pas (encore) constaté de bug bloquant .
Dans quel contexte as-tu trouvé ce bug ?
SPI, Timer3 ?
mes 2 horloges basées sur 18F26K22 tournent sans problemes depuis 3 mois
,ainsi que mon appli suivi EDF info 18F46K22 ..depuis plus de 2 ans .
Les seules perturbations ayant été les coupures EDF > à 1seconde=> reset MCU (j'ai pas mis d'accu en sauvegarde)
(15 coupures en Novembre = merci Enedis) mais repart aussitot .. avec liaisonsn BlueTooth OK
et c'est plutot mon EEPC Win XP avec Appli RapidQ , à l'autre bout qui se plante au moins 1 fois par mois.
Windows n'aime pas les liaisons series permanentes 24H/24 sur un port COM carte mére...
merçi pur l'info
Temps-x a écrit :... un errata
C'est un bug ou des bugs qui existe dans le microcontrôleur, l'errata sert à le résoudre ou le signaler.
j'utilise beaucoup ce PIC à toutes les sauces, et n'ai pas (encore) constaté de bug bloquant .
Dans quel contexte as-tu trouvé ce bug ?
SPI, Timer3 ?
mes 2 horloges basées sur 18F26K22 tournent sans problemes depuis 3 mois
,ainsi que mon appli suivi EDF info 18F46K22 ..depuis plus de 2 ans .
Les seules perturbations ayant été les coupures EDF > à 1seconde=> reset MCU (j'ai pas mis d'accu en sauvegarde)
(15 coupures en Novembre = merci Enedis) mais repart aussitot .. avec liaisonsn BlueTooth OK
et c'est plutot mon EEPC Win XP avec Appli RapidQ , à l'autre bout qui se plante au moins 1 fois par mois.
Windows n'aime pas les liaisons series permanentes 24H/24 sur un port COM carte mére...
Attention, bug sur Pic18F46k22 & Pic18F26k22
Bonjour paulfjujo, tout le forum,
En mode SPI maître, le programme bloqué et ne voulais plus sortir de la boucle, et quand ça fonctionnait, les données étaient erronées.
C'est seulement en m’étant les interruptions en fonction que ce bug est apparu, voici le code qui ma fait passé mon samedi devant mon écran
D'après l'errata : Bit tampon plein (BF) ou interruption MSSP, le bit indicateur (SSPIF) devient la moitié définie, cycle SCK trop tôt
C'est traduit par Google traduction, alors excusé si ça reflète pas ce qu'il veule dire.
J'ai laissé tombé le mode SPI automatique, j'ai pris le mode SPI bit bang, plus aucun problème. je vous joins le code pour mode spi bit bang
Mode SPI bit bang pour écran OLED 128x64
A+
paulfjujo a écrit :Source du message Dans quel contexte as-tu trouvé ce bug ?
En mode SPI maître, le programme bloqué et ne voulais plus sortir de la boucle, et quand ça fonctionnait, les données étaient erronées.
C'est seulement en m’étant les interruptions en fonction que ce bug est apparu, voici le code qui ma fait passé mon samedi devant mon écran
Code : Tout sélectionner
;********************** Configuration des registres lié à l'envoi des données **********************
movlw B'01010000'
movwf TRISC
movlw B'01000000'
movwf SSP1STAT
movlw B'00100001'
movwf SSP1CON1
spi
btfss INTCON,RBIF
bcf INTCON,GIE
bcf cs ; marche
movwf SSP1BUF
attends
btfss SSP1STAT,BF ; <<=== ici, ça devait surement bloqué, pas possible de contrôler avec MPLAB
bra attends
bsf cs
movf SSP1BUF,W ;
btfss INTCON,RBIF
bsf INTCON,GIE
D'après l'errata : Bit tampon plein (BF) ou interruption MSSP, le bit indicateur (SSPIF) devient la moitié définie, cycle SCK trop tôt
C'est traduit par Google traduction, alors excusé si ça reflète pas ce qu'il veule dire.
J'ai laissé tombé le mode SPI automatique, j'ai pris le mode SPI bit bang, plus aucun problème. je vous joins le code pour mode spi bit bang
Mode SPI bit bang pour écran OLED 128x64
Code : Tout sélectionner
spi
btfss INTCON,RBIF
bcf INTCON,GIE
movwf envoyer
bcf cs ; marche
movlw D'8' ; envoie de 8 bits
movwf bits
ev1_ssd1306
btfss envoyer,7 ; lecture sur le bit 7
bra ev2_ssd1306
bsf mosi ; envoie 1
bsf sck ;
bcf sck ;
bra ev3_ssd1306
ev2_ssd1306
bcf mosi ; envoie 0
bsf sck ;
bcf sck ;
ev3_ssd1306
rlncf envoyer,F ; rotation des bits à gauche sans carry
decfsz bits,F
bra ev1_ssd1306
bsf cs
btfss INTCON,RBIF
bsf INTCON,GIE
return
A+
Attention, bug sur Pic18F46k22 & Pic18F26k22
- paulfjujo
Expert- Messages : 2597
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
bonjour TempsX et à tous,
je n'ai pas une vue d'ensemble de ton code pour bien comprendre , mais
pourquoi manipuler GIE bit dans cette routine ?
avec GIE bit=1 avant d'entrer dans la subroutine
si INTCON.RBIF passe à 1 , il y a un saut au vecteur interruption
si il n'y a pas de traitement lié à INTCON.RBIF , celle ci ne pourra pas se desamorcer
puisqu'on ne remet pas INTCON.RBIF à zero
et on ne peut plus revenir au main programme => blocage
soit on traite INTCON.RBIF en mode pooling ( GIE_bit toujours à 0)
soit via interruption et le traitement se fait dans l'interruption (si sa duree n'est pas critique)
ou via un flag dans le main si duree de traitement longue.
mais un mixte des deux , me parait tres aléatoire
je n'ai pas une vue d'ensemble de ton code pour bien comprendre , mais
pourquoi manipuler GIE bit dans cette routine ?
avec GIE bit=1 avant d'entrer dans la subroutine
si INTCON.RBIF passe à 1 , il y a un saut au vecteur interruption
si il n'y a pas de traitement lié à INTCON.RBIF , celle ci ne pourra pas se desamorcer
puisqu'on ne remet pas INTCON.RBIF à zero
et on ne peut plus revenir au main programme => blocage
soit on traite INTCON.RBIF en mode pooling ( GIE_bit toujours à 0)
soit via interruption et le traitement se fait dans l'interruption (si sa duree n'est pas critique)
ou via un flag dans le main si duree de traitement longue.
mais un mixte des deux , me parait tres aléatoire
Code : Tout sélectionner
spi
btfss INTCON,RBIF <----- si GIE est déja à 1 et si le bit RBIF est à 1 , on a déja saute au vecteur interrupt
<----- et blocage
bcf INTCON,GIE
movwf envoyer
bcf cs ; marche
movlw D'8' ; envoie de 8 bits
movwf bits
ev1_ssd1306
btfss envoyer,7 ; lecture sur le bit 7
bra ev2_ssd1306
bsf mosi ; envoie 1
bsf sck ;
bcf sck ;
bra ev3_ssd1306
ev2_ssd1306
bcf mosi ; envoie 0
bsf sck ;
bcf sck ;
ev3_ssd1306
rlncf envoyer,F ; rotation des bits à gauche sans carry
decfsz bits,F
bra ev1_ssd1306
bsf cs
btfss INTCON,RBIF
bsf INTCON,GIE
return
Attention, bug sur Pic18F46k22 & Pic18F26k22
Bonsoir paulfjujo, et tout le forum,
Quand tu envois des commandes ou des données à un écran il faut absolument pas de coupure, sinon les informations qui arriveront à l'écran serons erronés, ça, je pense que tu le sais.
J'aurais jamais dû mettre ceci dans la routine présenté comme t'elle en mode SPI bit bang, je savais que j'aurais des ennuies
En réalité, c'est bien plus compliqué,
Quand je suis en mode interruption, il faut que j'envoie des données ou commande à l'écran, donc, pas besoin de couper les interruptions, car je suis déjà en mode interruption.
Pour les curieux et les passionnés, la routine d'interruption
J'ai pas besoin de vitesse, donc je traite comme ça, mais je vais surement modifier le programme de mon oscilloscope, car ça me plait pas
pour l'intérêt que tu apporte à ce modeste code
A+
paulfjujo a écrit :Source du message je n'ai pas une vue d'ensemble de ton code pour bien comprendre , mais
pourquoi manipuler GIE bit dans cette routine ?
Quand tu envois des commandes ou des données à un écran il faut absolument pas de coupure, sinon les informations qui arriveront à l'écran serons erronés, ça, je pense que tu le sais.
J'aurais jamais dû mettre ceci dans la routine présenté comme t'elle en mode SPI bit bang, je savais que j'aurais des ennuies
En réalité, c'est bien plus compliqué,
Quand je suis en mode interruption, il faut que j'envoie des données ou commande à l'écran, donc, pas besoin de couper les interruptions, car je suis déjà en mode interruption.
Pour les curieux et les passionnés, la routine d'interruption
Code : Tout sélectionner
ORG H'8' ; interruption haute priorité
btfss INTCON,RBIF ; tester si interruption RB4, RB5, RB6, RB7 en cours
retfie FAST ; non, sortir
bra toucher ; oui, traiter
ORG H'18' ; interruption base priorité
retfie FAST
toucher
movf FSR0H,W
movwf fsr0_temps+1
movf FSR0L,W
movwf fsr0_temps+0
movf FSR1H,W
movwf fsr1_temps+1
movf FSR1L,W
movwf fsr1_temps+0
movf FSR2H,W
movwf fsr2_temps+1
movf FSR2L,W
movwf fsr1_temps+0
movf posy,W
movwf posy_temps
movf posx,W
movwf posx_temps
rcall gestion_bt0 ; <-- ici gestion des poussoir, avec modification de l'écran, (traiter interruption)
bcf INTCON,RBIF ; effacer flag interruption
movf fsr0_temps+1,W
movwf FSR0H
movf fsr0_temps+0,W
movwf FSR0L
movf fsr1_temps+1,W
movwf FSR1H
movf fsr1_temps+0,W
movwf FSR1L
movf fsr2_temps+1,W
movwf FSR2H
movf fsr2_temps+0,W
movwf FSR2L
movf posy_temps,W
movwf posy
movf posx_temps,W
movwf posx
retfie FAST
paulfjujo a écrit :Source du message (si sa duree n'est pas critique)
J'ai pas besoin de vitesse, donc je traite comme ça, mais je vais surement modifier le programme de mon oscilloscope, car ça me plait pas
pour l'intérêt que tu apporte à ce modeste code
A+
Retourner vers « Langage ASM »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 21 invités