Pic 16f887 recalcitrant....!?

[inviteb1cc1e07]

Bonjour à tous, (je suis nouvelement inscrit de ce matin)

Je suis en train de programmer un 16F887 en assembleur. ce programme est environ mon 10em. je suis certainement pas encore bien aguéri,
mais là... ???. J' électrifie mon portail, mes sorties sont sur le port b ( bien configurées, car la partie du programme "marche manuelle" fonctionne parfaitement bien, tout en utilisant les mêmes sorties...et les mêmes commandes "bsf"). Cependant dans la partie du programme en "marche automatique" celles-ci soit ne ce mettent pas à 1 soit s'annulent les unes au autres (cligotent), bref c'est du n'importe quoi.... Alors que je suis sûre du déroulement (car je met des messages sur mon afficheur à chaques étapes de fonctionnement en même temps que je traite lesdites sorties.) Hors actuellement le programme marche correctement avec des "nop" et autres stratagèmes du même type mais c'est moche... Du coup je n'ai plus trop confiance. , aussi par exemple dans "ouverture petite vitesse".
j'écris:
; ici on vient d'écrire sur l'afficheur "ouv pv"
call LCDchar ;l'afficheur est sur un autre port
nop
bsf MOTEUR ;moteur en marche
nop
bcf GV ;éteind grande vitesse
goto looportail ;retour au debut de la boucle portail pour recalculer sa position

Cette solution marche....Alors que:

nop
bcf GV ;éteind grande vitesse
nop
bsf MOTEUR ;moteur en marche

Cette solution met le moteur en marche mais n'éteind pas la grande vitesse....?
J'ai été voir sur la toile si des fois, quelqu'un sait ce qu'il ce passe mais rien, sur un autre forum étranger une personne avec un probleme similaire les internautes lui ont conseillé des "nop"....
Ma question: quelqu'un pourrait-il m'expliquer ce qui gène le bon déroulement du programme? bug, programme mal construit,plusieurs mise à 1consécutives (je sais pas j'énumère des idées....) autrement le programme fonctionne, mais j'aimerai savoir pour ne plus avoir ce genre de déboire et être sur de ma programmation (pour ne pas que ma femme reste planté devant la porte avec deux gamins qui braillent..).
-----

[RISC]

Salut,

Pour faire court : les "nop" ne sont nécessaires qu'entre 2 instructions de type bsf PORTx,y qui se suivent sur le même PORT.

Mettre un nop entre un bcf et un bsf ou inversément ne change rien et n'est pas nécessaire.

Ta description est beaucoup trop approximative pour tenter une explication.
Ton schéma ?
Ton programme ?

Après on pourra peut -être commencer à avoir des idées...

a+

[inviteb1cc1e07]

Bonjour à tous,

Merci RISC, c'est exactement ce type de choses bizarre que j'aimerai savoir.

En effet a ma connaissance je n'ai jamais vu notifié dans le datasheet ou sur
les très fameux cours de Bigonoff de tels comportements erratiques.

peut-être qu'un document existe? (si c'est dans le datasheet je mange ma sourie !....)
Sinon, si les plus aguéris pourraient énuméré des comportements de ce type (interaction
entre deux instructions ) au cours de ce fil, je pense que ça serai instructif pour ceux qui
comme moi débute et ce trouve bloqué a chercher des problêmes qui ne sont décelable
que si on connait ce genre de suptilitées.

RISC, c'est pas que je veux pas mais je suis juste insrit, mes connaissances en informatiques sont au niveau des océans,
mon niveau d'étude frise le ridicule, mais bon... J'ai besoin de prendre mes marques sur ce forum apparament assez vaste
que je ne connaissais qu'en non-inscris, parachuté par google via une recherche quelconque.

je peux évidement tenter d'envoyer ce programme mais j'ai peur que les futures discutions tournent sur
du hors sujet à propos du programme lui même, alors que malgré mes explications tordues vous êtes tombé pile
sur le type de problêmes que je voulais partager.

[RISC]

Salut,

Pour résumer une discussion qui a déjà eu lieu des centaines de fois :
* pour les PICs qui ont des registres LATx et PORTx, il FAUT utiliser LATx pour les sorties et PORTx pour les entrées.
* pour les PICs qui n'ont PAS de registre LATx mais uniquement PORTx, il FAUT mettre un nop entre 2 instructions BSF PORTx,y pour les sorties lorsqu'elles se suivent.
Ces règles sont applicables quelquesoit le langage utilisé (ASM ou C).
La raison de cela est dans les datasheets...

a+

[A voir en vidéo sur Futura]

[inviteb1cc1e07]

bonjour
Je n'ai pas connaissance des registres "LATx, je vais chercher...!
et la raison est dans le datasheet... sur les versos alors!
je re re re regarde....( et après, je mange ma sourie !)

[inviteb1cc1e07]

bon ben, en effet, c'est dans le datasheet;I/O, read modify write (flûte j'ai pômer ma sourie !)
par contre il ne parle pas de "LATx" dans le datasheet mais sur la toile si j'y retourne

[invitee5da1686]

saluton a tous chercher en tant sur a 1000% que ce genre de ligne etait bon


nop
bcf GV ;éteind grande vitesse
nop
bsf MOTEUR ;moteur en marche



sans regarder le reste....


par ex


nop
bcf GV ;éteind grande vitesse
nop
bsf MOTEUR ;moteur en marche
....
...
...
..
....
...
...
....
....
....
...
....
...
...
...
...
...
...
....
...
..
bsf GV ;marche grande vitesse
...
...

deja pour etre sur que le prog ci dessous marche met une grande pause en dessous

nop
bcf GV ;éteind grande vitesse
nop
bsf MOTEUR ;moteur en marche
(pause de quelque secondes pour être sur qu'a cette étape on a bien le fonctionnement voulu.)

[inviteb1cc1e07]

Bonjour morpheus pic,

pour l'exemple avec l'inversion que tu sites, je t'assure que c'est vrai, c'est ce que je faisais voir à ma femme.
c'est d'ailleur ce qui m'a pousser a m'inscrire sur ce forum. N'arrivant plus à avancer seul, et ayant déjà eu des déboires similaires
en chargant une variable par le même principe.
j'ai commencé à commentarisé mon programme pour vous le donner en pâture je pense que vous aller rire un peu.
j'ai essayé quelque chose de similaire à ce que tu dis avec moins de "quelque seconde", en effet par exemple
lors de la partie "ouverture grande vitesse" j'ai l'afficheur a réécrire, je fais une action, "bsf GV"je me remet au début de la ligne 2,
et j'écris " ", "o", "u", "v", " ","g", ".", "v" , puis une autre action,"bsf MOTEUR". je pense que j'ai laissé assez de temps au pic pour que l'état
des sorties soit validé...? les afficheurs ne sont pas très rapide, au regard du pic. Alors avec ma façon d'écrire sur l'afficheur qui doit pas être trop optimisé
j'imagine que le pic a le temps
m'enfin à ce soir faut encore allez bosser.....

[invitee5da1686]

ou alors ton pic 'plante' quand le moteur démarre, essai d’écrire sur l'afficheur juste après avoir mi le moteur en route, vois si tu a pas des choses étranges qui apparaisse sur l'afficheur ..

[inviteb1cc1e07]

Désolé, Morpheus.
il plante pas: l'affichage ce déroule mormalement, à chaque étape d'ouverture ou de fermeture j'écris un nouveau message. et de plus j'affiche aussi les pas moteur (roue codeuse) et je les vois défiler correctement,dans le bon sens et en correlation avec le comptage des pas.
mais bon depuis j'ai changé la configuration des pins en vue de préparer la mise sur plaque, depuis moins de problême sur les sorties (quoi que) mais d'autres du même style que j'annoncerai quand je vais vous joindre mon "prog" pour l'instant je vous met un max de commentaire pour que vous puissiez
avoir une idée concrête de mon projet. ( qui doit faire d'autres choses en plus (temperature, minima, maximat mais cette partie me semble plus simple)on verra)

[invitefaaca50b]

Ca sent un probleme plus hard que soft... en remplacant le moteur par une lampe, ca fait quoi?

[invitef86a6203]

essai d'utiliser des AND ou des OR pour modifier les bits , c est plus long que le bcf ou bsf , mais ça peut parfois résoudre des problèmes , plutôt que se prendre la tête pendant des heures

exemple;

; reset le bit 0
movf PORTB,w
ANDLW 0xFE
movwf PORTB

; set le bit 0
movf PORTB,w
IORLW 0x01
movwf PORTB

[inviteb1cc1e07]

Bonjour à tous
voilà mon programme, a force de tripatouiller j'espère qu'il n'est pas trop en soupe

[RISC]

Salut,

Ton programme est bien documenté mais je te recommande une chose qui simplifie énormément la gestion des banques :
utilise la macro : BANKSEL variable (voir manuel ou internet)
Cela évite les PB de changement de banque. L'assembleur choisit automatiquement la banque ou se trouve la variable. Tu mets cela devant chaque variable ou chaque registre du micro et tu n'as plus à y penser...

Cela dit...passe au langage C dès que possible. Tu développeras beaucoup plus vite et au vu de ton bon niveau en ASM je ne pense pas que l'apprentissage du C sera un PB ;=)

a+

[inviteb1cc1e07]

bonjour à tous,
voilà après correction du programme ce que ça donne. Hier je vous ai envoyé un prog erroné car j'ai vite suprimé des petites fonctions supplémentaires ce qui perturbait légerement le fonctionnement (ex marche manu: ouvrir n'ouvrait pas...)
comparé au début de ce fil le programme a évolué et évidement ce qui était dit au début ne c'est pas refletter dans la version envoyée
au début, mon erreur était de gerer toutes mes sorties dans les blocs (ouv pv, ouvgv, ...) ce qui donnait des mises à 1 concecutives sur
les mêmes sorties déjà à 1, des "bsf" concecutif qui agissant sur le même port, en effet le datasheet en parle (toujours pas retrouvé cette
put... de sourie, moi...), de ce faite une optimisation de tout ça a mis de l'ordre. J'ai remarqué que lire des valeurs en eeprom trop souvent
pour un test par exemple pertubait beaucoup le pic (je pense que c'était là le plus dure pour le pic, car dès les préchargements ont été inseré
le fonctionnement c'est nettement amélioré) vaut mieux précharger dans une variable et en suite lire cette variable.

bref voici le programme, il est à jour pour ce qui est du portail. il ne comprend pas encore "la température, minima, maxima" j'y bricole...
je remercie tout le monde.

pour résumer j'ai appris que:
-des "bsf" à la suite sur le même port ne fonctionne pas
-PORTX,y sert à lire un bit d'un port
-LATX,y sert à écrire un bit sur un port
-l'utilisation de "banksel" et la façon de traiter de l'assembleur, vis à vis des variables et des banques.(là je découvre, alors on va essayé...)
Je n'avais jamais eu l'idée de lire une sortie! je pensais que le faîte de la lire risquait de la modifier. c'est avantageux.
merci et à +

[invitefaaca50b]

je ne saurai que conseiller les maquettes de Bigonoff adaptées chacune a un µC specifique et où tout est bien cadré et bien explicité, de meme pour les variables, les differentes banques ou stocker les variables... ces maquettes sont dispo sur son site.
Ces maquettes de depart sont ideales pour la creation de tout nouveau projet pour des raisons evidentes de lisibilité.

[inviteb1cc1e07]

bonjour,

Je suis dedans, et je nage, je nage...... Ces cours sont super-grand (ayant imprimé le cour 1, il a encore falu acheter un classeur plus grand... pour le mettre)
Si aujourd'hui j'arrive a programmer des pics, c'est déjà grace à cette homme, extraordinaire qui a décidé de partager son savoir de le donner sans rien en retour.....(quand je pense au boulot qu'il a fait, moi qu'aime pas ça ! ...... )

Treve de plaisanterie, je suis entrain de faire le cours II, pas forcément les maquettes, pour apprendre je me fait un résumé de son cour ce qui me facilite la tache lorsque j'utilise un périphérique non maitrisé, une sorte de "hand book" avec des récapitulatifs et des tableaux pour la convertion hexa /binnaire/dec..
Pour moi le résumer pour m'en servir, m'oblige à l'avoir compris. j'en suis à l'I2C ..... je sait pas mais je sent que j'aurais des questions...

j'en profite pour répondre à "risc", j'avais éssayé le "C" mais le faite de ne pas avoir de compilateur gratuit, alors que j'avais acheter un mini logiciel nul d'un c.. de prof .... Chui encore vert cher et qui marche peu, des fois et si c'est pas compliqué.
Puis, un autre logiciel gratuit "ldmicro" pour programmer en ladder j'avais traduit toute l'aide... gratuit et qui marche...avec un simulateur......
merci à l'auteur américain.
il m'a permis de faire des aplications de suite et de commencer a raisonner "pic"
là j'ai découvert "BIGONOFF" and the wailer, sur le coup je comprenais rien après la logique booléenne, il parlait de flag ?..
de directives et autres nom tordues et pour moi tous ce ressemblaient.... il parlais d'un truc revenait en arriere...(depuis je l'ai relu c'était moi qui butais sur des détails et ne comprennais pas) je l'ai résumé et ça c'est éclaircie.
Je sait que certain jure que par tel ou tel langage ou logiciel pour ma part je ne suis pas obtu, c'est vrai que l'assembleur est parfois déroutant, mais en même temps j'ai l'impression d'être plus près de mon aplication et ça me rassure de tout voir. J'avais commencer plusieurs tutoriels en "C" mais malgré les éfforts des auteurs je restais toujours planté suite à des compilateurs de démos.. sans compter sur icprog qui marche chez certain mais pas chez d'autres...
un vrai chemin de croix pour arriver à .... la led clignote! ....
Alors "Bigonoff" + mplab et là j'avais tout...même le boulot.... et après Hue coco, c'est ce que disait Robert HUE !....
voilà à +