Dans le cas du communiquant, vous la remplaceriez par quoi ? Un if ?
PieM ne dit pas qu'il ne faut pas le faire... mais n'en voit pas l'intérêt....
Pour moi l'intérêt est d'avoir deux Picaxes quasiment identiques et qui donc réagissent de la même façon puisqu'ils ont les mêmes entrées.
La maintenance en sera d'autant plus facile.
Accessoirement, vu vos tests, je ne serais pas surpris que le Communiquant programmé de cette façon, donne des résultats finalement pas si mauvais que ça. (Impossible à prouver pour le moment, ce sera la surprise)
Certes les interruptions ne sont prises en compte qu'entre deux instructions. Il faut donc éviter les instructions les plus longues.
Un sertxd est long si le texte envoyé est lui même long. Mais on peut faire la même chose en deux fois, ce qui prends plus de code et plus de temps, mais permet de prendre en compte plus vite l'interruption.
Il faudrait aussi tester (et au besoin remplacer) certains GOSUB, réputés longs sur un Picaxe...
J'avais pris par habitude d'allumer systématiquement la led défaut quant le communiquant n'était pas prêt pour le chronométrage ou dans une phase de contrôle : c'est de cela que je parlais comme référence pour l'horloge -> allumée, rien doit se passer côté interruption de l'horloge.
Comme déjà dit, l'interruption ne fait que mettre à jour la variable Temps.
Ainsi il y a très peu de décalage entre le front descendant et sa prise en compte :
- fin de l'instruction en cours dans le programme principal (donc éviter les instructions trop longues),
- temps de copie de la variable Timer vers la variable Temps
Toutes les instructions qui suivent pour copier vers T1 ou T2, puis pour test et affichage n'ont aucune influence sur la qualité du chronométrage.
Si on n'est pas dans une boucle qui prends en charge la variable Temps, alors elle n'est pas prise en compte et pis c'est tout...
Autrement dit, Chaque Picaxe peut continuer tranquillement à mettre à jour la variable Temps à chaque front descendant, peu importe que ça serve à quelque chose ou pas.
Autrement dit, il n'y a aucun intérêt à désactiver les interruptions.
Je comprends votre frustration parce que je sais que les débutants veulent avant tout écrire du code.
C'est pourtant une perte de temps considérable.
Une fois le POC réalisé, la prise en compte des différents cas de figure est une formalité, à conditions que ces cas soient exhaustivement listés.
Par exemple, au final, y a-t-il une LED et/ou un bouton dédiés au PARAMETRAGE ? J'ai cru comprendre qu'il reste quelques pins libres.
Sinon, comment signaler que l'on est en mode paramétrage ? Comment met-on fin au paramétrage ?
A ma connaissance ça n'a pas été précisé.
Durant la phase de "Mise en ordre de marche" on attends que la ou les barrières concernées soient libres.
Donc quand on commence à attendre le START, on n'a aucune raison de tester à nouveau si tout va bien :
- soit la barrière de départ est occultée et justement c'est un START valable,
- soit il y a une seule barrière et elle est occultée, et donc on a aussi un START valable,
- soit la seconde barrière est occultée et il me semble qu'on se laisse la possibilité de relever la barrière (test toutes les 5 secondes) ou de passer en mode manuel.
Donc, il n'y a aucune raison d'abandonner cette phase. On attends tranquillement le START (ou le retour en mode PARAMETRAGE) et on passe à la phase suivante qui va gérer les éventuels problèmes.