PIC 16F876-Fonction test

[invitef26bdcba]

Salut,

La temporisation ne résoudra pas le problème entre deux tests de détermination de l'action à accomplir :

       movf PORTC,W
	andlw b'00001100'
	sublw b'00001100'
	btfsc STATUS,Z
	goto action2

	movf PORTC,W
	andlw b'00001100'
	sublw b'00001000'
	btfsc STATUS,Z
	goto action1

Car si entre le test capteur1 et capteur2 l'état du port change, il est presque certain que le saut ne se fera pas vers la bonne action.

Par contre, je n'avais pas vu que le troisième test renvoyait vers le premier test si le troisième n'est pas concluant.
En principe, il vaut mieux gérer cela comme une erreur (en renvoyant sur une nouvelle tempo pour stabiliser le port par exemple) et non recommencer les tests...

La sécurité de fonctionnement demanderait de contrôler la variable "copie du port" avec la valeur réelle du port juste avant le saut (ou a l'entrée) vers "l'action" afin de se prémunir d'un changement de la valeur du port entre les trois tests.


David.
-----

[invitef1f90160]

Salut,

Travailler directement sur le port du µC, n'est pas recommandé dans ce cas précis.
Car entre chacun des tests, tu recharges le port dans le registre de travail, et si entre deux tests la valeur du port change c'est le bug assuré pour les tests conditionnels...

Donc, il faut sauvegarder dans une varaible la valeur du port avant de faire les trois tests, et faire ces tests sur la variable et non directement sur le port du µC.

Sans oublier la remarque sur la tempo (ou remplacer la tempo par un test périodique du port, genre un test toutes les 10ms par exemple)

David.

Effectivement, dès le départ, si on remonte sur mes posts j’ai parlé de mémorisé ce qui est dans le port dans une variable. Donc je penche moi aussi dans ce cas la.

Pour ce qui est de la temporisation, il en existe dans mon programme et pas question de tester toute les 10ms le port !

J’ai une boucle principale qui réagit de la façon suivante :

haut
	call	Avance
	
	;Regarde ce qui est sur le PORTC
	;Stoque ce qui est dans le PORTC dans la variable VISU

	;Selon ce que vaudra VISU,
		;Cas 1 on a le capteur droit
		;Saut vers le taritement 1

		;Cas 2 on a le capteur gauche
		;Saut vers le taritement 2

		;Cas 1 on a le capteur droit et le capteur gauche
		;Saut vers le taritement 3

	;Autre traitement
	goto haut

;traitement 1
goto haut

;traitement 2
goto haut

;traitement 3
goto haut

	end

Donc, le PORTC est lue assez souvent dans mon cas. Enfin comme je tourne en 20Mhz il l’est !

D’où le fait que la plus on parlote plus on s’étend et je ne crois pas que l’on ai trouvé la bonne réponse ! Mais on n’est pas loin
Personnellement je continue à tester des bouts de code en espérant trouver

Cordialement.

[invitef26bdcba]

Pour ce qui est de la temporisation, il en existe dans mon programme et pas question de tester toute les 10ms le port !
Donc, le PORTC est lue assez souvent dans mon cas. Enfin comme je tourne en 20Mhz il l’est !

A quelle fréquence exactement tu lis le portC???

10ms est un grand minimum pour un capteur TOR!

David.

[invitef26bdcba]

Encore une question :

Peux-tu donner en annexe dans un post les datasheet de tes capteurs TOR et des moteurs afin de vérifier la fréquence minimal de lecture des capteurs?

P.S. : Si tu fais ce qui est décrit dans le post#32, c'est entièrement logique que le comportement des moteurs semble fou ou anesthésié vu la fréquence de lecture des capteurs...

David.

[invite_P89]

Le problème de la variable n'apportera pas grand chose, pourquoi :
-Une fois dans w le port peut bien changer.
-Une fois sur une action le port peut bien changer.
Cela n’intéresse plus personne la donnée est acquise, l'action lancé.

Dans ton bout de code toujours pas de tempo, mais comme tu dis si bien .

D’où le fait que la plus on parlote plus on s’étend et je ne crois pas que l’on ai trouvé la bonne réponse ! Mais on n’est pas loin
Personnellement je continue à tester des bouts de code en espérant trouver

donc bonne bidouille

[invitef26bdcba]

Le problème de la variable n'apportera pas grand chose, pourquoi :
-Une fois dans w le port peut bien changer.
-Une fois sur une action le port peut bien changer.

Et que se passe t'il si au premier test d'état1 on à l'état2 et qu'au test d'état2 l'état a changé pour l'état3(ou 1)???

Bien tu sautes les actions et c'est un bug (voir pire si son capteur tor fait des rebonds et détourne vers une mauvaise action)...

David.

[invite_P89]

Bien tu sautes les actions et c'est un bug (voir pire si son capteur tor fait des rebonds et détourne vers une mauvaise action)...

Bien non, puisque on est dans une boucle infernale, C'est pas un µP quantique avec une dose de, peut-être bien que oui,peut-être bien que non.
Quand la donnée est dans W elle ne va pas s'envoler.

Et une fois dans w on effectue le test.

On ne fait pas:

movlw b'00000011'    ; valeur litérale dans w
andwf PORTC,w        ;on fait un and avec le port

la cela peut planter et encore.

Tu vois je te donnes encore du code.

Pour les rebonds,comment tu les traites, sinon avec une tempo,je pense que dans son programme c'est fait.

mais la on parlote,on parlote.
Il pose ou il ne pose pas sa tempo, moi je ne post plus cela ne sert à rien.

[invitef26bdcba]

Bien non, puisque on est dans une boucle infernale, C'est pas un µP quantique avec une dose de, peut-être bien que oui,peut-être bien que non.
Quand la donnée est dans W elle ne va pas s'envoler.

Et une fois dans w on effectue le test.

On ne fait pas:

movlw b'00000011'    ; valeur litérale dans w
andwf PORTC,w        ;on fait un and avec le port

la cela peut planter et encore.

Tu vois je te donnes encore du code.

Pour les rebonds,comment tu les traites, sinon avec une tempo,je pense que dans son programme c'est fait.

mais la on parlote,on parlote.
Il pose ou il ne pose pas sa tempo, moi je ne post plus cela ne sert à rien.

Si cette méthode te convient...

Le problème que tu ne sembles pas voir, c'est que tu recharges trois fois le PORT dans W à intervalles réguliers et donc tu peux avoir trois résultats différents, et c'est cette ambiguïté qu'il faut lever. Pour lever cette ambiguïté, il faut passer par une variable et avant de lancer l'action vérifier que la variable est toujours identique à la valeur du PORT et c'est impossible à faire sans sauvegarder la valeur du port!

Mais bon, comme cette routine semble te convenir, je laisse tomber...

David.

[invitef1f90160]

Bon je croi qu'on va en arreter la!

On aura 2 carteur, 2 cas point final !
Juste espéré ne jamais tomber dans le cas 3 qui n'existera dorénavant plus!

Merci encore pour vos indications.
Je me retourne maintenant vers le C (mal compilé) pour enretiré un élement de code afin de résoudre ce cas... peut être un jour ! Qui sait ?

Cordialement.

[invitef86a6203]

Je me retourne maintenant vers le C (mal compilé) pour en retiré un élément de code afin de résoudre ce cas... peut être un jour ! Qui sait ?

Pas satisfaisant comme attitude.

Je relance donc avec ce code;

 
MyLoop
; si besoin voir explication plus bas
; movlw 50
; call DelayMs
        movf PORTC,W
	andlw b'00001100'
        movwf Memory
	sublw b'00001100'
	btfsc STATUS,Z
	goto action2

	movf memory,W
	sublw b'00001000'
	btfsc STATUS,Z
	goto action1

	movf memory,W
	sublw b'00000100'
	btfsc STATUS,Z
	goto action3
goto Myloop

; zone de procédure
; ici c'est de la procédure spaghetti avec du goto ...
; mais bon si on revient toujours à MyLoop ça va
action1
   ...
  goto myloop

action2
   ...
  goto myloop

action3
   ...
  goto myloop

mais la on parlote,on parlote.
Il pose ou il ne pose pas sa tempo, moi je ne post plus cela ne sert à rien.

J'ai eu un peu aussi le sentiment de ne pas être entendu.
Mais apparemment la raison est autre, sans doute un problème technique hard ou soft.

Bien tu sautes les actions et c'est un bug (voir pire si son capteur tor fait des rebonds et détourne vers une mauvaise action)...

Ok 100% pour ça.

Peut être la source du problème!
ICO Tu nous dis , "mon capteur ne fait pas de rebond !"
Comment le sais tu ?
Un rebond , c'est des ms ou des µs alors pour le savoir il faut un oscilloscope à mémoire ou équivalent.
Alors je met un call delayms facultatif qui devrait supprimer les rebonds si le signal qui sort du capteur "bégaille" au début.