comment ne pas rester bloqué en attente sur SERIN ?

[zylix]

Bonsoir

j'ai developpé un petit programme en vb.net qui communique avec un picaxe 28x1.
les grandes lignes sont les suivantes :

depuis le pc j'envoie 2 actions vers le picaxe : un ordre de rotation d'un moteur vers la gauche ou un ordre de rotation de ce meme moteur vers la droite.

ça marche très bien.

le problème est que j'ai ajouté sur mon circuit 2 poussoirs pour faire le meme travail mais directement sans passer par le pc.
or je ne parvient pas a réaliser un code correct sur le picaxe car j'utilise la fonction serin pour lire les infos qui arrivent du pc par le port serie et le picaxe est en mode blocage sur ce serin et il ne detecte pas les action de mes poussoirs et attend un ordre du pc...

voila le programme que j'utilise

main:
      setint 3,3
      pause 1000
      low 0
      low 1
      low 2
      serout b.7,N2400,("TNT MOTOR CONNECTED",cr)
      pause 500
label_14:   
      
      serout b.7,N2400,("Choose Direction :",cr)
      pause 500
      dirsc=%00000000      
      serin 4,N2400,b0 
      if b0 = "l" then left
      if b0 = "r" then right
      goto moteurstop:
         
   
left:      
      high 0
      pause 100
      high 1
      low 2   
      serout b.7,N2400,("vers gauche <--",cr)
      pause 1000   
      goto label_14

right:
      high 0
      pause 100
      high 2
      low 1
      serout b.7,N2400,("vers droiter -->",cr)
      pause 1000
      goto label_14
      
moteurstop:

      low 0
      low 1
      low 2
      serout b.7,N2400,("Motor stopped <-->",cr)
      pause 1000
      goto label_14


interrupt:
      if pin0=1 then left      
      if pin1=1 then right
      setint 3,3
         return

vous l'aurez compris j'ai besoin de tester ce qui arrive sur mon serin mais ne pas y rester bloquer et verifier en meme temps l'etat de mes poussoirs

merci de votre aide

 

[BESQUEUT]

En principe le "Background receive" = "réception en tâche de fond" devrait répondre à votre besoin. Toutefois il y a différentes limitations qui font que le résultat reste un peu aléatoire. En particulier la réception en tâche de fond est incompatible avec l'instruction serout. Il serait donc judicieux soit de retirer les messages à destination du PC , soit de les limiter au minimum (un seul octet est suffisant pour dire ce qui se passe, le programme pouvant traduire ce code en langage naturel) ou de considérer que le PC ne peut envoyer de message tant qu'il en reçoit. Dans ce dernier cas, il faut établir un protocole du genre XON XOFF, ce qui semble possible puisque vous maîtrisez le programme coté PC.

Elle fonctionne par contre très bien pendant les pauses dont vous avez émaillé votre programme (mais, bon, faire autre chose pendant qu'on ne fait rien, ça n'est pas un exploit...)

 

[MGU]

Bonjour,

Je ne sais pas si je réponds exactement à la question, mais dans la syntaxe de serin il y a (pour les M2,X1,X2) un "timeout", et même un "timeout, address"

Additional optional timeout syntax options for M2, X1 and X2 parts:
SERIN [timeout], pin,baudmode,(qualifier...)
SERIN [timeout], pin,baudmode,(qualifier...),{#}variable,{#}variable
SERIN [timeout], pin,baudmode,{#}variable,{#}variable
SERIN [timeout,address], pin,baudmode,(qualifier...)
SERIN [timeout,address], pin,baudmode,(qualifier...),{#}variable,{#}variable
SERIN [timeout,address], pin,baudmode,{#}variable,{#}variable

MM

 

[PieM]

Bonjour,

et bienvenue voisin.

Pour éviter de rester bloqué sur un serin, utiliser le timeout : SERIN [timeout en ms], 4,N2400,b0

D'autre part, pour rendre votre programme plus réactif, évitez de mettre trop de pauses...
Votre programme principal est en fait le Label_14:

vous affichez "Choose Direction :" et si il n'y a pas de réponse l ou r , vous allez sur moteurstop où vous affichez "Motor stopped <-->" pour lequel vous êtes obligé de remettre une pause pour avoir le temps de lire, avant de revenir à "Choose Direction :"

Si vous êtes dans l'attente d'un ordre, c'est que votre moteur est obligatoirement à l'arrêt compte tenu de votre programme.
Donc ne mettez qu'un seul message "Arret moteur - Choisir L ou R" par exemple, en supprimant la pause dans motor stop.

Vu votre programme, votre moteur ne tourne que 1 seconde à chaque ordre transmis ? C'est bien ce que vous voulez ?

dirsc=%00000000 ne doit pas être dans le programme principal, mais dans l'initialisation (que vous appelez en fait "main:" )


GRILLED par MGU dirait Besqueut

 

[zylix]

content d'avoir un voisin proche aussi.

merci de votre aide. je vais apporter les quelques améliorations sur les pauses.

cependant j'ai creusé le sujet du timeout mais j'ai beau le tourner dans tous les sens chaque fois que remplace mon serin par le serin avec timeout, j'obtiens sur le simulateur de programming editor le message suivant :

serin [100,poussoirs],4,N2400,b0 
            ^

Erreur: Caractère illégal - ('[' (0x5B))

???

quelles solutions pour eviter cela ?

merci de votre aide.

 

[BESQUEUT]

et en enlevant les crochets ?

 

[PapyJP]

Précisions svp.
Cettte discussion m' interesse dans le cadre de mon projet ( cf ' serin, serout inapropriés ' ).
En effet je cherche le moyen de surveiller des entrées et d' afficher leurs états à l' écran.

The inputs port is checked between execution of each command line in the program, ...

Je comprends donc que ' serin' bloque en quelque sorte le polling des entrées pendant l' attente d' un overflow de ' timeout '.
Cas d' école :
1/ Supposons que pendant le temps d' attente définit par ' time out ', la configuration des entrées change.
Lorsque le ' timeout ' overflow, le retour au programme exécute ' setint ' ????
La subroutine d' IT est-elle exécutée ( avec retard bien sûr ) ?
2/ Supposons que pendant le temps d' attente définit par ' time out ', la configuration des entrées change puis revient à l' état initial.
Lorsque le ' timeout ' overflow, il n' est pas possible de savoir que les entrées ont changé momentanément.

Si j' ai bien compris 1/ et 2/ cela veut dire que l' on ne peut avoir un vrai fonctionnement sous IT ( Appel instantané à une routine de traitement d' IT ) que si le programme ne contient aucune instruction ' blocante ' du genre "serin", "pause",...
Me trompe-je ?
Faut-il placer l' instruction " setint " dans l' en tête de programme, avant le 'main' ?

 

[zylix]

moi j'ai fait l'essai sur le montage que j'ai presenté au debut de ce post.

j'ai mis finalement le setint avant le main: est j'ai enlevé le serin. j'ai simplement fait clignoter une led et je voulais tester l'interruption avec mes 2 poussoirs.
dans ce cas la ça marche bien.

j'ai enlevé ma led, j'ai remis mon cable serie pour me connecter au pc et attendre les ordres. mais la le programme se bloque sur serin et les interruptions sur l'un ou l'autre des poussoirs ne fonctionne plus.

j'ai essayé de suivre les conseil de piem concernant le timeout mais ça ne fonctionne pas il me dit que la syntaxe des crochet pour le timeout apres le serin ne sont pas acceptable...????

j'attends qu'une ame généreuse rebondisse sur le problème et me propose une solution sur ce probleme de syntaxe.

ensuite je referai l'essai et je vous tiendrai au courant pour vous dire si un serin timeout est compatible avec une interruption.

 

[PieM]

il me dit que la syntaxe des crochet pour le timeout apres le serin ne sont pas acceptable...????

Non, pas dit ça moi !

#picaxe 28X1

serin [100,poussoirs],4,N2400,b0

poussoirs:
' xxxxxxxx
return

Fonctionne sans erreur de syntaxe ni caractère illégal.

Les interruptions ne peuvent fonctionner que si le picaxe n'est pas en attente du serin. donc il faut utiliser le timeout.
D'autre part, si vos poussoirs sont sur interruption, il est inutile de renvoyer sur un sous-programme poussoirs puisqu'il sont, par principe, testés en permanence !

Essayez de remettre la totalité de votre programme quand vous faites une modif ...

 

[BESQUEUT]

et en enlevant les crochets ?

J'ai cru à une typographie pour des paramètres optionnels, ce qui nest pas le cas.
==> ne pas tenir compte de cette remarque.

 

[zylix]

je ne parlais pas de vous piem quand j'ai ecrit "il me dit", mais de programming editor. je me suis mal exprimé, désolé

je vais réécrire comme il faut le programme ce soir et je vous tien au courant.

 

[PapyJP]

Je me fais tout petit devant PieM mais pour que son code en #9 tourne en simulation sur PE il faut
1/ déclarer " main: "
2/ remplacer " return " par " goto main "
......................??????????

Quelqu' un peut-il infirmer ou confirmer mes délires en #7 ?
§
Merci

 

[zylix]

j'ai modifié mon programme en essayant de tenir compte de vos remarques. j'ai pu faire fonctionner aussi le serin avec timeout.

le code qui se rapproche le plus de ce que j'ai besoin est celui-ci

init:
      dirsc=%00000000
      'setint 3,3
      pause 1000
      low 0
      low 1
      low 2
      serout b.7,N2400,("TNT MOTOR CONNECTED",cr)
      serout b.7,N2400,("Choose Direction :",cr)
      pause 500
      
main:   
                      
      serin [1000,interrupt],4,N2400,b0 
      if b0 = "l" then left
      if b0 = "r" then right
      goto moteurstop:
      
      
   
left:      
      high 0
      pause 100
      high 1
      low 2   
      serout b.7,N2400,("To the left 1sec <--",cr)
      pause 500        
      goto moteurstop

right:
      high 0
      pause 100
      high 2
      low 1
      serout b.7,N2400,("To the right 1sec  -->",cr)
      pause 500
      goto moteurstop
      
moteurstop:

      low 0
      low 1
      low 2
      serout b.7,N2400,("Motor stopped <-->",cr)
      serout b.7,N2400,("Choose Direction :",cr)
      pause 500
      goto main


interrupt:
      if pin0=1 then left      
      if pin1=1 then right
      'setint 3,3
      goto moteurstop

cependant j'ai essayé de faire fonctionner mes 2 poussoirs en mode interruption mais je n'y parvient pas.
je me suis donc contenter d'allonger un peu la durée du timeout (1 sec) afin que le temps soit asser long pour prendre en compte l'appui sur un des poussoirs.
malgré tout cette solution qui marche correctement n'est pas parfaite car la prise en compte des boutons poussoirs n'est pas instantané et du coté pc, a cause du timeout j'ai toute les secondes un message qui arrive sur le pc : "moteur stopped choose direction) ça ne me gène pas plus que cela mais le picaxe travaille en permanence ...

ceci dit c'est quand même un progrès.

 

[PieM]

je me suis donc contenter d'allonger un peu la durée du timeout (1 sec) afin que le temps soit asser long pour prendre en compte l'appui sur un des poussoirs.
malgré tout cette solution qui marche correctement n'est pas parfaite car la prise en compte des boutons poussoirs n'est pas instantané et du coté pc, a cause du timeout j'ai toute les secondes un message qui arrive sur le pc : "moteur stopped choose direction) ça ne me gène pas plus que cela mais le picaxe travaille en permanence ...

Bonjour,

pendant le timeout du serin, l'interruption n'est pas prise en compte. Donc allonger le temps du timeout ne va rien apporter;
Comme je l'ai dit, il ne sert à rien de renvoyer sur la procédure interrupt par le time out, puisque cette procédure est appelée automatiquement par les interruptions.
donc serin [1000],4,N2400,b0 est suffisant

Compte tenu du programme, il attends 1 seconde un serin, sans interruption possible, dons sans détection d'un appui sur un BP, puis va sur moteur stop pendant 500 ms avant de revenir au pg principal. Donc en fait , la détection des BP n'est possible que pendant 1/3 du temps toutes les 1.5 secondes!

Essayez un timeout de 200 ms et une pause de moteurstop de 200 ms. La fréquence de détection passera à 50% du temps toutes les 400 ms

sinon

mais le picaxe travaille en permanence

... pas d'inquiétude, il est fait pour ça même quand il donne l'impression de ne rien faire !

 

[PieM]

Je me fais tout petit devant PieM mais pour que son code en #9 tourne en simulation sur PE il faut
1/ déclarer " main: "
2/ remplacer " return " par " goto main "

Bien sûr ! mais ce n'était pas un programme, juste un test de validité de la syntaxe pour les problèmes du "[".

Quelqu' un peut-il infirmer ou confirmer mes délires en #7

Quels délires ?

1/ Supposons que pendant le temps d' attente définit par ' time out ', la configuration des entrées change.
Lorsque le ' timeout ' overflow, le retour au programme exécute ' setint ' ????
En fait le programme exécute la routine interrupt: en fonction des paramètres définis dans SETINT et à condition que les conditions d'interruption soient toujours présentes !

La subroutine d' IT est-elle exécutée ( avec retard bien sûr ) ?
2/ Supposons que pendant le temps d' attente définit par ' time out ', la configuration des entrées change puis revient à l' état initial.
Lorsque le ' timeout ' overflow, il n' est pas possible de savoir que les entrées ont changé momentanément. NON

Si j' ai bien compris 1/ et 2/ cela veut dire que l' on ne peut avoir un vrai fonctionnement sous IT ( Appel instantané à une routine de traitement d' IT ) que si le programme ne contient aucune instruction ' blocante ' du genre "serin", "pause",... Exact, sauf que PAUSE n'est pas une instruction bloquante vis à vis des interruptions.
Me trompe-je ?
Faut-il placer l' instruction " setint " dans l' en tête de programme, avant le 'main' ? Oui puisqu'il s'agit d'une instruction de configuration pour les interruptions. Mais également à la fin de la routine Interrupt: pour réarmer les interruptions lors du return.

Précision: ceci concerne les Picaxes non équipés d'interruptions hardware comme les 20X2, 28X2 et 40X2. Voir l'instruction HINTSETUP à ce sujet.

 

[PapyJP]

Ok, grand merci
1/

à condition que les conditions d'interruption soient toujours présentes !

C' est à dire que " setint " ait été réarmé aprés une IT ?
Pour cela la sous-routine " interrupt " doit elle se terminer par " setint " ? Faut-il repréciser le masque ?

2/ Cest bien :

OUI en effet il n' est pas possible de savoir que les entrées ont changé momentanément

?

 

[PieM]

C'est bien ça ...

 

[PapyJP]

à condition que les conditions d'interruption soient toujours présentes !

C' est à dire que " setint " ait été réarmé aprés une IT ?
Pour cela la sous-routine " interrupt " doit elle se terminer par " setint " ? Faut-il repréciser le masque ?

 

[PieM]

C' est à dire que " setint " ait été réarmé aprés une IT ?

Ce que je veux dire, dans le cas d'une instruction bloquante par exemple le serin [timeout], c'est que si l'on veut déclencher une interruption par l'appui sur un BP, il faut que cet appui existe encore à la sortie du timeout puisqu'on ne prends pas en compte l'état pendant l'instruction bloquante.

Pour cela la sous-routine " interrupt " doit elle se terminer par " setint " ? Faut-il repréciser le masque ?

Oui bien sûr:

on doit avoir :

Interrupt:
..............
blablablablablabla
...................
setint [condition logique éventuelle] input, mask
return

Attention au fait que seules certaines broches peuvent bénéficier du mode interruption. Voir la doc !!

 

[jerome06060]

affaire de priorité d'interruption...

au risque de dire une bourde, je lance quand même l'idée:

Ne serait il pas plus efficace, au lieu de définir l'interruption sur les entrées qui captures l'appui des touches, de la définir sur l'arrivée d'une réception séries (et donc de traiter l'ordi comme une gestion d'interruption avec tout ce qui concerne la com avec celui ci).
et l'affichage sur l'ordi des premiers messages dans la partie initiale.

avec donc, une boucle principale sur le scan des entrées de touches (elles mêmes filtrées en hard pour éviter un rebond).

 

[BESQUEUT]

Tiens, le "Background receive" repointe le bout de son nez, et dans ce cas, c'est bien possible que ça marche !