Chrono Agility : nouveau

ddaweb

New Member
Bonsoir,

C'est la première fois que je poste sur le forum, d'après ce que j'en ai lu, la communauté seule assez active et surtout réactive.
Je l'ai déjà consulté pas mal de fois pour avoir des informations.
Désolé d'avance si je demande quelques chose qui a déjà été répondu, mais je ne l'ai pas trouvé.

Pour vous situer dans mon projet, il est issus de ceci : https://picaxeforum.co.uk/threads/chrono-agility.25290/ - http://electromag1.wifeo.com/chrono-agility.php
J'y ai ajouté pas mal de fonctionnalité :
- Démarrage via un 'interrupt'
- Bouton START/STOP unique, 'interrupt' pour le START
- Choix du sens A > B ou B > A
- Choix de 1 ou 2 barrières : suivant le choix du sens, A > B = A ou B > A = B
- Remise à zéro automatique du chrono
- Mémoire des 8 derniers temps
- Boitier pour les juges avec 2 témoins qui indiquent l'état du chrono
- Etc ...

Venons-en à mes questions :

1. Comme dans la version du modèle ci-dessus, le temps est enregistré en type word : 5 digits (centième de seconde), donc jusque 65535 -> variable 'val_temps'.
J'utilise le port série pour la commande d'un afficheur extérieur en envoyant sur un autre picaxe le code ascii '-val_temps' à chaque afficge sur le LCD .
Je souhaite maintenant faire un 2me port série pour raccorder un PC pour y envoyer le string du style : 'I 9999 c1 00 :mm :ss :zh00 00<CR>'.
Vous constatez que le temps est lui en minutes-secondes ... les centièmes je peux facilement les extraire via b1, b2, b3, b4 et b5, le reste est en secondes.
La question :
Existe-t-il une formule pour convertir les secondes en minutes-secondes ? ... purement mathématiquement c'est facile, mais le picaxe ne permet pas tout.

2. Ce string devrait se faire via le bus I2C avec un picaxe maître et un autre esclave (18M2 est prévu pour cela en esclave, le 28x2 est le maître, et le chrono).
Je sais déjà qu'il faut initialise le maître et l'esclave avec la vitesse ... je vais d'abord essayer en fast vu les 4-5 cm de fil entre les 2.
La question :
Pouvez-vous m'expliquer comment faire cette liaison et envoyer le string du temps (variable 'val_temps') ?

J'espère avoir été assez clair dans mes explications, ce n'est pas facile de l'écrire.
D'autres question pourraient découler de vos réponses.

Je vous remercie d'avance pour vos conseils.

@+
ddaweb
 

MGU

Senior Member
Bonjour,

Je suis heureux de savoir que ce projet a pu être reproduit et amélioré avec succès.

Je peux essayer de répondre à la question 1.
Si on compte le temps en centième de secondes,:
tempscentieme//100 => isole la partie centièmes de secondes
tempscentième/100 => supprime les centièmes de secondes: reste le temps en seconde entières
tempsseconde//60 => isole la partie secondes
tempsseconde/60 => supprime les secondes: reste le temps en minutes entières

Il faut intégrer cela dans le contexte

Pour le reste, je n'ai jamais fait de liaison entre picaxe avec l'i2C.
Si PieM passe par ici, il aura certainement la réponse.

MM
 

ddaweb

New Member
Bah, je cherchais à en construire un et je suis tombé dessus via une recherche sur internet, actuellement, j'ai 552 lignes de code malgré plusieurs sous-routines utilisées à plusieurs endroits, ce qui est nettement plus que l'original.
Une fois que le hardware sera monté définitivement, je vais regarder pour essayer de simplifier le code, mais ce ne sera pas facile.
La partie RF je ne l'utilise pas (encore), mais sera très facilement implémentable via un petit module ... d'autres modules sont prévus.

Voici la platine de test :

DSC_0325_forum.JPG

Concernant ma question 1, haaa ben oui en formule mathématique donc ... loool
J'espérais qu'il existait une ou des fonctions utilisables pour le faire plus facilement, dommage.

Pour les centième, il y a plus simple avec bintoascii , j'explose le chiffre (b1 -> b5) et ne prend que les seconde que je converti ensuite en minutes secondes, en gardant les centièmes tel-quels.

Voici comment je voulais faire :

- Nombre de centièmes : nbr_cent_aff= b5 +(10*b4)
- Nombre tot sec : nbr_sec=b3+(10*b2)+(100*b1)
- Nombre de minutes : nbr_min_aff=nbr_sec/60 -> j'obtiens le chiffre entier si j'ai bien compris dans un autre topic
- Nombre de secondes : nbr_sec_aff= nbr_sec-(nbr_min_aff*60)

Bref des belles math. classiques.

Pour le I2C ... j'attendrai.
J'avais déjà essayé sans des résultats probant, mais en ayant tout de même une communication ... sans tout comprendre malheureusement.

Edit :
@MGU, j'ai relu attentivement ton code et je viens de comprendre ... pas mal
La variable word 'val_temps' me donne le temps en 1/100 directement, c'est de là que je pars.
 
Last edited:

ddaweb

New Member
J'ai une petite question : existe-t-il un module temps réel au centième synchronisé via les ondes ?

Si oui, je travaillerais probablement autrement :
- Au START : j'enregistre l'heure temps réel dans une 1ère variable
- Au STOP : j'enregistre à nouveau l"heure dans une 2me variable
- La différence du temps STOP et du START est le temps réel

L'enregistrement dans le programme des clasements se fait de la sorte et sera plus facile pour le concepteur : pas d'adaptations, actuellement il regarder pour obtenir une convergence avec ce que je lui ai proposé.
 

MGU

Senior Member
Ok, c'est pas encore fini....
Il n'y a pas de parenthèses dans le calcul picaxe. De gauche à droite, strictement. Sinon, faut prendre un arduino
Je ne connais pas de modules donnant le 1/100 ème, même radio-piloté, mais le timer d'un picaxe X2 le fait très bien. (non homologué pour les jeux olympiques).
Pourquoi des liaisons I2C?
Je n'ai pas encore vu l’intérêt d'un 18M2 par rapport au 20M2 (même prix, moins performant, moins pratique car broches alim différentes).
Je pense que pour ce genre de projet, il faut procéder par étapes et valider progressivement .

Pour info, il me semble que l'on trouve des barrières toutes faites sur le net, mais c'est plus cher.
Il y a aussi ces petits modules à expérimenter: https://www.ebay.fr/itm/VL53L0X-GY-530-IIC-I2C-ToF-Time-of-flight-Ranging-Distance-Sensor-2-8-5V-Module/163608054356?ssPageName=STRK:MEBIDX:IT&_trksid=p2057872.m2749.l2649

bon bricolage
MM
 
Last edited:

ddaweb

New Member
En fait nous avons un chrono complet datant de 1997.
Il arrive en fin de vie et c'est pour cela que je me lance dans ce projet, mais en conservant les barrières, tout en pensant à des évolutions.
Les barrières sont en 12v, je place un booster 5 -> 12v et un petit transistor pour convertir l'entrée dans le picaxe.
J'estime la conso max à +/- 360 mA ... je prévois de pouvoir travailler avec un PowerBank de 10.000 mA (alimentation de secours ou principale), suffisant pour un WE.
Je devrais tester le nouveau chrono en conditions réelles en août ... avec l'ancien en secours.

Il me semblait avoir lu que le X2 permettait les parenthèses :oops:

Oui oui, l'horloge du picaxe donne d'excellent résultats, je l'ai testé sur +/- 600 sec alors que les concours tournent au max. à 1'30 (souvent 25 à 50 sec.).
Je n'ai même pas mit de qwartz pour cette raison ... juste du ajuster un peu la fréquence, à voir maintenant avec les dernières modifications : settimer 64916.

Le bus I2C servira pour les options que j'ajouterai.
Pour le RF, le Xbee (ou équivalent) est également une option que je regarde, mais plus cher que le 433 Mhz, mais fonctionnemant en réseau maillé.

Concernant le 18M2 ou 20M2 ... oui bof, peu importe, c'est juste la taille et l’existence du bus I2C qui m'a fait prendre le 18M2, un 20M2 ou autre n'a que peu d'importance vu le tout petit programme qu'il accueillera : la conversion du temps du chrono en 1/100 sec via I2C en série vers le programme sous le format que j'ai décrit (c'est encore une option supplémentaire pour l'instant).
En fonction du start automatique ou manuel, ou alors stop automatique ou manuel :
- 'I 9999 c0 00 :00:00:0000 00<CR>'.
- 'I 9999 c0M 00 :00:00:0000 00<CR>'.
- 'I 9999 c1 00 :mm :ss :zh00 00<CR>'.
- 'I 9999 c1M 00 :mm :ss :zh00 00<CR>'.
Ce string va être testé pas le développeur du programme sous Access.

Pourquoi ne pas utiliser le série du 28X2 : c'est déjà prévu pour un afficheur externe. L'afficheur LCD prend l'autre série.

Hummmm le fameux module de distance, je me sent un peu moins seul avec ta remarque ... faudra pouvoir l'étalonner car des personnes tournent autour des barrières de Start et Stop : il faudra bien déterminer le seuil de déclenchement (distance) ... sans compter que la couleur des alentour peu l'influencer ... +/- 1.2m.
Faudra tester sa fiabilité, les barrières IR avec catadioptre on démontrés leur fiabilité.
Quand j'en parle au club, on me regarde avec des yeux de merlan frit :p
 

ddaweb

New Member
MGU said:
Si les barrières existent, pas de problème
MM
Oui, mais sont aussi vieillissantes :unsure:
Se débarrasser du réglage du catadioptre sera évidemment un plus.
Donc je penses, dans un immédiat pas trop lointain, de les remplacer, même si j'ai un exemplaire de réserve.

Pour la conversion des secondes, je vais essayer les 2 codes après mes congés, le vôtre me semble très intéressant.

J'espère comprendre le bus I2C afin de pouvoir ajouter d'autre options dans le futur, donc la liaison PC.
 

PieM

Senior Member
Bonjour,
Ce string devrait se faire via le bus I2C avec un picaxe maître et un autre esclave (18M2 est prévu pour cela en esclave, le 28x2 est le maître, et le chrono).
Non, le 18M2 ne peut être un esclave. Il est obligatoirement un maître et il est à l'initiative de la lecture du scratchpad du X2 esclave.
Les infos à partager seront donc écrites par le X2 dans son SPad, et le M2 va lire quand il veut, sans perturber l'esclave.

Nota: aucunes parenthèses possibles dans les calculs avec picaxe!
 
Last edited:

ddaweb

New Member
Bonjour,

Non, le 18M2 ne peut être un esclave. Il est obligatoirement un maître et il est à l'initiative de la lecture du scratchpad du X2 esclave.
Les infos à partager seront donc écrites par le X2 dans son SPad, et le M2 va lire quand il veut, sans perturber l'esclave.

Nota: aucunes parenthèses possibles dans les calculs avec picaxe!
Arf, je vais soit devoir changer de Picaxe si je garde le chrono comme maître et regarder ceux qui peuvent être esclave, soit changer mon fusil d'épaule ... :sneaky:, je regarderai cela après mes vacances, là j’achève le montage hardware du chrono pour ce vendredi (madame en a marre de mon labo improvisé).

Pouvez-vous me donner la bonne procédure pour les initialiser correctement en I2C ?
Je vais ensuite regarder comment envoyer le temps pour envoyer le bon string en série vers un PC.
J'ai déjà réussit à envoyer des choses entre deux 28X2 via I2C, mais pas trop concluant ... surtout pas trop bien compris le principe et la programmation :rolleyes:
 

PieM

Senior Member
Il conviendrait de définir qui fait quoi; peut être un petit schéma de l'architecture générale et de ses liaisons.
Je ne comprends pas. Le chrono peut très bien être dans le X2 esclave, et le M2 qui gère l'affichage va chercher l'info dans le X2.
En I2C, l'esclave est vu comme une mémoire externe. Il n'a pas besoin d'envoyer quelque chose.
Attention aux distances très limitées en I2C !

Concernant la gestion PC, pourquoi ne pas garder plus simplement la donnée transmise sous la forme brute de 100e de s ?
En dehors de l'affichage local, le formatage des données n'a aucune raison d'être traité par un Picaxe. C'est le boulot du PC.
Le développement sous Access gère la liaison série avec un Picaxe ?
Sinon un petit développement sous Processing fait facilement le job en créant un fichier neutre lisible par l'appli que l'on veut, Access ou autres (gratuits) et peut remplacer un LCD local en affichant les temps en gros sur écran.
 

ddaweb

New Member
Le module central est le chrono, autour de cela il y a différents éléments :
- Les 2 entrées des barrières A et B
- Le boitier des juges via 2 sorties qui indique l'état du chrono : cela leur permet d'attendre que le chrono soit prêt avant de siffler le départ du chien
- L'afficheur série LCD Y133 dans le chrono pour le secrétaire (indique le temps et les fautes sur un papier en cas de contestation ultérieure)
- L'afficheur externe, pour les concurrents, via la communication série (la même que pour la programmation du picaxe) : uniquement le TX et à chaque lecture du temps du chrono, mais j'ai constaté un retard de 5/100 par rapport au temps réel -> au stop je renvoie 3x le temps final '-temps' (parfois la mise à jour de ces 5/100 est visible) et ensuite 3x '-0' pour la led d'activité (clignotement du point).
- Le bus I2C va permettre des modules supplémentaires et donc des évolutions : le premier module sera une communication vers un PC pour introduire les temps directement dans le programme de gestion -> tout reste dans le chrono, donc quelques centimètres de câble !!

Donc en fait la communication vers le PC se fait uniquement en TX et est transformé dans un string bien spécial (cf plus haut) :
- Au moment du start : le module PC n'est pas au courant, c'est donc le chrono qui envoie ... autrement il faut faire un système de scan constant, au risque de louper un info s'il est mal étudié
- Au moment du Stop : le temps du chien est envoyé
- Tout le reste du temps, il est en attente d'une information : bref vraiment pas grand chose à faire

Le string est issu d'un chrono 'Alge Timing' clé sur porte que le concepteur du programme avait et a donc développé, via un petit programme 'ComToFile' pour l'inscrire dans une table Acces ... je ne fait que m'adapter à ce qui existe.
Le jour où c'est un autre programme, je refais le string ad-hoc ... voir faire une config multi-string paramétrable (switch, bouton rotatif ?, sur une entrée) ;)
 

PieM

Senior Member
- Au moment du start : le module PC n'est pas au courant, c'est donc le chrono qui envoie ... autrement il faut faire un système de scan constant, au risque de louper un info s'il est mal étudié
Non, absolument pas. Les données chrono sont gérées et se trouvent dans le module X2. L'interface PC va lire qd il le veut ces informations. Le fait qu'il y ait un retard dans la transmission ne change rien à la précision de l'info.
Concernant la précision de la mesure du temps au 1/100, je reste très sceptique compte tenu que visiblement le X2 va faire beaucoup de choses, y compris des tâches générant des interruptions. La précision et la fidélité des mesures implique de gérer le start, le stop, et la mesure du temps sur un µC dédié.
Pour info, sur un picaxe, il y a autant de liaisons série que l'on veut sans passer par celle de la programmation!
 

ddaweb

New Member
Je suis tout à fait d'accord avec vous qui faut absolument faire en sorte que le temps du chrono soit le plus fidèle possible.
Le start est géré par une interupt qui lance un timer interne réglé au 1/100.
La lecture du temps est celle de ce timer et se fait certainement aux moments cruciaux, dont le stop en dernier lieu ... au milieu, même si c'est mieux, cela n'a pas trop d'importance qu'il y ai un tout petit retard d'affichage : sur le LCD cela ne se voit de toute façon pas et les 5/100 non plus.

Que ce soit pour le LCD ou l'afficheur extérieur : c'est le temps au stop qui doit être correct ... d'où la màj forcée de l'afficheur extérieur.
Maintenant que le chrono ai une erreur de temps de 2-3 1/100, tant que c'est la même pour tout le monde, cela n'a que peu d'importance ... mais soyons clair que si c'est de l'ordre du 1/10, cela n'est plus normal.
Une fois tout au point, je vais le tester en comparant le temps avec l'ancien : même bouton Start et Stop pour les 2 via commande à la masse ... les valeurs devront être très très proches, au besoin adapter la fréquence du Picaxe. (je sais que celui qui l'a conçu a fait très attention à la précision dans son code).

La meilleur solution est un module temps réel fiable avec lequel on enregistre l'heure au start et ensuite au stop : la différence est le temps du chien.
Le chrono 'Alge' travaille de la sorte, mais c'est un autre budget aussi : x10.

Pour en revenir à l'interface PC : c'est de elle que je parlais qui allait devoir constamment venir chercher le temps dans le X2 vu qu'elle ne sait absolument pas ce qui se passe en amont dans le chrono.

PieM said:
Pour info, sur un picaxe, il y a autant de liaisons série que l'on veut sans passer par celle de la programmation!
Pouvez-vous m'en dire plus là dessus ?
 

PieM

Senior Member
Que ce soit pour le LCD ou l'afficheur extérieur : c'est le temps au stop qui doit être correct ... d'où la màj forcée de l'afficheur extérieur.
ça n'a rien à voir! c'est le comptage qui doit être précis, et non pollué par d'éventuels éléments du programme. L'affichage, même s'il a 1 seconde de retard, n'a aucune incidence.
Sans quartz, les variation d'horloge sur un pic peuvent être de plusieurs % en fonction entre autres, de la température. Le 1/100 est totalement illusoire, comme cela a déjà été évoqué dans un précédent fil. Vouloir comparer avec un chrono c'est comparer des précisions qui ne peuvent donc être comparables. Résolution et précision sont 2 choses différentes.
Pour en revenir à l'interface PC : c'est de elle que je parlais qui allait devoir constamment venir chercher le temps dans le X2 vu qu'elle ne sait absolument pas ce qui se passe en amont dans le chrono.
Non, il n'y a pas besoin de venir chercher constamment le temps. Le PC, si on veut, ne va rien chercher; il reçoit l'info en provenance du Picaxe à la fin du comptage pour mettre à jour la base de données, ou je n'ai rien compris à ce que faisait le PC.

Concernant les liaisons série, voir la doc serin, serout, Hserin ... etc
j'ai 552 lignes de code
Curieux que vous ayez déjà plus de 500 lignes de code sans connaître la base des possibilités du Picaxe.
 

ddaweb

New Member
Pour le PC : on se met sur la fiche du concurrent et dès que le chrono s'arrête, le champs temps est rempli ... le secrétaire ajoute manuellement les fautes et refus pour obtenir un nombre de points. Alors on passe au concurrent suivant qui est au départ (par forcement le numéro de dossard +1, il n'y a pas d'ordre de passage fixé, juste conseillé, mais doit rester dans la même classe !).

Pour le sérial, j'avais cru comprendre qu'il existait d'autres façons de faire ... c'est déjà cela que j'utilise partiellement, je vais regarder le serin-serout.
Voici un exemple de la routine d'affichage du temps du LCD et l'envoi pour l'afficheur extérieur :
Code:
affichage_temps_chrono:  
    bintoascii val_temps, b1,b2,b3,b4,b5            'decomposition ascii
    hserout LCD,(254,136,b1,b2,b3,",",b4,b5," s")   'affichage LCD 1ere ligne : temps
    sertxd ("-",#val_temps)                         'RS232 afficheur exterieur : envoi du temps instantanne en ASCII
    return
Je ne connaissais absolument pas le Picaxe (ni le µC dans sa globalité) il y a quelques mois, je l'ai donc un peu étudié, cherché sur internet et expérimenté ... mais je fais du PHP-MySQL pour la gestion de notre club : gestion membres-chiens-comptabilité-rappel automatiques-etc... aussi un langage de programmation et des routines à avoir, fallait transposer le code qui n'est pas tout à fait identique, tout en ayant les mêmes principes de bon usage.

La longueur du code est du au différentes fonctionnalités, comme par exemple :
- La configuration des barrières comme expliqué plus haut et donc la gestion de l'interrupt vu qu'il change d'une entrée à une autre + 1 BP Start/Stop
- Blocage de toutes les barrières durant 5 sec. après le start ... l'affichage du temps se fait évidemment
- A la sortie du blocage, si le stop est en alarme, le chrono passe en mode manuel : stop avec un BP
- Par contre, si le stop repasse au repos durant 5 sec. consécutives, le chrono revient en mode automatique
- L'appel des 8 derniers temps, uniquement si le chrono n'est pas en route, en mode FIFO : par 2 lignes du LCD, via 1 seul BP
- Reset automatique du chrono après 5 sec. après le stop et alors affichage du dernier temps sur la 2me ligne
- La gestion de l'affichage en fonction de ce qui est ci-dessus : tout s'affiche clairement pour l'utilisateur + bip sonore (buzzer sur CI)

Mais il est cependant vrai que je n'ai pas encore découvert toutes les possibilités du picaxe, à chaque fois que je veux y ajouter une fonctionnalité, je découvre des choses. Je cherche en fonction de ce que j'ai besoin, c'est un tort, mais le manque de temps est un frein pour tout apprendre.
 
Last edited:

ddaweb

New Member
PieM said:
Sans quartz, les variation d'horloge sur un pic peuvent être de plusieurs % en fonction entre autres, de la température. Le 1/100 est totalement illusoire, comme cela a déjà été évoqué dans un précédent fil. Vouloir comparer avec un chrono c'est comparer des précisions qui ne peuvent donc être comparables. Résolution et précision sont 2 choses différentes.
Vous conseillez donc d'ajouter un qwartz ? 16 Mhz ?
Le placer sur le CI est tout à fait possible, j'ai laissé la place au cas où je devrais y passer, et était ma première idée, mais à la lecture de certains topics, je ne l'ai pas fait.
Il faut tout de même tenir à l'oeil que chaque chien doit avoir la même base de référence, normalement le plus proche possible du 1/100 dans mon cas. Si le soleil pointe et que la référence change, ce n'est pas correct pour les concurrents.

Une précision tip-top au 1/100, je n'y crois pas non plus, mais si on parle de quelques 1/1000, voir 1-2 1/100, il me semble assez précis.
Le chrono de secours est manuel ... côté précision on repassera.
 

BESQUEUT

Senior Member
Petit rappel concernant les communications maître/esclave :
- ces termes disent qui a l'initiative du dialogue, pas le sens de la transmission des données,
- d'ailleurs sur un bus, les échanges sont bi-directionnels.
Autrement dit le maître peut envoyer des données à l'esclave, ou lire depuis l'esclave les données dont il a besoin.

Ce qui est important, c'est de savoir qui peut être interrompu, ou pas...

Pour le quartz, j'aurais tendance à utiliser un 32768 hz de qualité horloger avec une horloge DS1307 laquelle donne un signal à 4096 hz très précis.

Pour le Picaxe je prendrais un 20X2 qui tourne nativement à 64 Mhz.
Je pense qu'il doit pouvoir compter le signal sur interruption hard.

L'autre interruption hard peut être utilisée pour démarrer/arrêter le comptage.

La boucle principale ne fait que transmettre sur un ou plusieurs ports série le résultat du comptage. Un rafraîchissement de l'ordre de quelques hz est suffisant à l’œil et n'a aucune influence sur la précision du comptage final.

A noter que dans cette configuration, l'I2C n'est utilisé que pour paramétrer l'horloge.

Le millième de seconde me semble réaliste avec un signal à 4096 hz, même si on rate une impulsion au démarrage ou à l'arrêt du compteur.
 

ddaweb

New Member
@BESQUEUT
J'ai un peu regardé et le qwartz pour le 28x2 est bien 16 Mhz pour une fréquence de travail de 64 Mhz (4 x 16).

Concernant l'interruption hard :
il est possible de faire démarrer le timer (je le fait : variable interne 'timer' que je met à 0 au démarrage), et il serait également possible de l'arrêter dans la même interruption de démarrage ?
Cela je n'ai pas trouvé cela durant mes recherches et il est vrai que ce serait le top de pouvoir le faire.
L'interruption reste le moyen le plus fiable dans le cas d'un chrono.

Dans mon cas, l'utilisation du I2C ne servirait qu'à convertir un valeur temps (décimale) en un string série bien déterminé : au puls du start et du stop ... rien d'autre. Il n'y a aucune précision, juste une conversion d'une valeur reçue en autre chose, donc rien de crucial.
Mais je vais voir si le serout ne pourrait pas faire l'affaire, mais il ne me reste plus que les pin B.6 et C.5 de libres
 

BESQUEUT

Senior Member
La précision d'un quartz "informatique" est à priori moins bonne que celle d'un 32768 taillé pour piloter une horloge.
Mais j'avoue ne pas avoir réellement testé. Un quartz 16Mhz devrait permettre de garantir le 1/100 s si le programme est correctement écrit.
En tout cas, si une horloge externe est utilisée, il faut la brancher en C.0

Sur un 28x2 il y a trois interruptions hard, donc on peut en utiliser une pour démarrer le compteur et une autre pour lire la valeur finale.
A priori, le compteur peut être arrêté avec settimer off
Sauf erreur de ma part, le timer peut être pré chargé avec
63036 pour avoir une interruption tous les 1/100s
65411 pour avoir une interruption tous les 1/200s
65486 pour avoir une interruption tous les 1/500s
65511 pour avoir une interruption tous les 1/1000s

Mais il faut que la routine d'interruption incrémente le ou plutôt les compteurs sans rater aucune interruption.
A priori cette routine ne contient que :

if flag7 then ' Interruption due au timer
if Timer=10000
Timer=0
Inc Dizaines
endif
endif


if flag0 then ' interruption due au hint0
setint...
endif


if flag1 then ' interruption due au hint1
setint off
endif




Du coup, avec une interruption en 1/1000 s , Dizaines compte des dizaines de secondes, donc au maxi 655350 secondes=182 heures


Sur un x2 il y a aussi un timer3 dont le fonctionnement semble un peu différent. Voir si ça permet plus de précision ?

Une fois le timer, les interruptions et la routine d'interruption écrits, il ne reste rien à faire sinon un
do
loop


A priori c'est là dedans que l'on peut lire la valeur du timer de temps en temps et l'envoyer sur les ports série. Ça peut être compliqué et prendre du temps car ça n'influe pas sur la précision du chronomètre.

On peut formater avec un peu de calcul et le serout si ça simplifie la réception. Ça prends du temps, mais c'est pas grave.
Sur le Picaxe ou le PC qui reçoit, c'est pas grave s'il rate une trame : il aura la suivante...
Garder quand même à l'esprit que plus la trame est longue, plus il y a de chances d'en rater un bout...

Au début on envoie que des zéros...
Après déclenchement de la première barrière, on reflète le compteur, avec sans doute un léger décalage. Ça suffit pour voir que le compteur tourne, et de toutes façons il est impossible de lire les 1/100 de seconde qui changent sans arrêt.

Après déclenchement de la deuxième barrière on envoie en boucle le temps final qui lui est précis.

Il faut une patte pour chaque barrière : B.0 B.1 ou B.2 sur un 28x2.
plus une pour chaque sortie série, et une pour le reset.

Il y a plein de pattes libres. Je ne comprends pas a quoi vous les utilisez ?
 
Last edited:

ddaweb

New Member
Le flag7 n'est-il pas un overflow du timer ?

Je vais commencer par mettre les pins de l'initialisation du chrono, cela donnera déjà une petite explication avec les commentaire (j'en met beaucoup car une fois OK , une modification pourrait avoir lieue que d'ici pas mal de temps) :
Code:
; --------------- Les borne de type A
symbol led_status=pinA.0    'Pin A.0 (Out) : Led status du chrono : clignote = attente -- depart = allume -- defaut = eteint
symbol led_defaut=pinA.1    'Pin A.1 (Out) : Led erreur : une barriere est anormalement active
symbol led_sens=pinA.2        'Pin A.2 (Out) : Led sens des barrieres : allume = A->B (vert), eteint = B->A (jaune)
symbol led_nbr=pinA.3        'Pin A.3 (Out) : Led nbr de barrieres -> allume = 2 barrieres (vert), eteint = 1 barriere (rouge)
'pinA.4 : NE PAS UTILISER    'Pin A.4 (Out) : TX -> pour afficheur exterieur
; --------------- Les borne de type B
symbol barriere1=pinB.0        'Pin B.0 (In)  : Cellule barriere1
symbol barriere2=pinB.1        'Pin B.1 (In)  : Cellule barriere2
symbol start_stop=pinB.2    'Pin B.2 (IN)  : BP START/STOP suivant les cas
symbol choix_sens=pinB.3    'Pin B.3 (In)  : Sens des barrires : 1 = barrierre1 -> barriere2 - 0 = barriere2 -> barriere1
symbol choix_nbr=pinB.4        'Pin B.4 (In)  : Nombre de barriere : 1 = 2 barrieres, 0 = 1 barriere
symbol memoires_temps=pinB.5    'Pin B.5 (In)  : Appeler les memoires -> enfoncer BP : impulsion (lacher et reenfoncer BP) pour changer les memoires affichees
;pinB.6
symbol buzzer=pinB.7        'Pin B.7 (Out) : Buzzer
; --------------- Les borne de type C
symbol adresse1=pinC.0        'Pin C.1 (In) : Adresse chrono via strap a couper -> bit 1 (1)-> A PROGRAMMER AVEC ENTREES RF
symbol adresse2=pinC.1        'Pin C.1 (In) : Adresse chrono via strap a couper -> bit 2 (2)
symbol adresse3=pinC.2        'Pin C.2 (IN) : Adresse chrono via strap a couper -> bit 3 (4)
;pinC.3 : NE PAS UTILISER    'Pin C.3 : SCL bus I2C
;pinC.4 : NE PAS UTILISER    'Pin C.4 : SDA bus I2C
;pinC.5
symbol LCD=C.6             'Pin C.6 (Out) : NE PAS MODIFIER -> sortie serie afficheur LCD (pour la fonction HSEROUT : LCD)
;pinC.7 : NE PAS UTILISER    'Pin C.7 (In)  : HSERIN
Comme je compte faire du RF, l'adresse du chrono permettra d'en mettre plusieurs sans que ce soit le bordel entre-eux ;)
J'hésite encore d'en mettre 4 ou 8.

Le chrono en attente, je surveille :
- Le nombre de barrières
- Le sens des barrières
- Si le stop passe en alarme (et/ou le start après une remise à zéro du chrono)
- S'il y a un appel des mémoires
L'affichage LCD est en fonction de l'état réel du chrono

Concernant l'interrupt, je rappelle que le sens du start et du stop peuvent être inversé, je dois donc réinitialiser l'interrup au changement de sens :
Code:
sensbarrieres:
    ; ---------- initialisation du sens des barrieres et interrupt du depart
    if choix_sens=1 then
        high A.2                    'led_sens allumee
        hintsetup %00000101            'Initialisation interrupt sur entree B.0 -> barriere1 ou B.2 -> BP START/STOP
        setint %00000001,%00000001        'trigger entree
        setintflags or %00000101,%00000101     'Activation flag interrupt -- "or" permet une entree OU l'autre
        pause 10
    else if choix_sens=0 then
        low A.2                    'led_sens eteinte
        hintsetup %00000110            'Initialisation interrupt sur entree B.1 -> barriere2 ou B.2 -> BP START/STOP
        setint %00000001,%00000001        'trigger entree
        setintflags or %00000110,%00000110     'Activation flag interrupt
        pause 10
    end if
Au changement de sens, je fais un SETINTFLAGS OFF avant de réinitialiser
Pour 1 seule barrière il n'y a pas d'influence avec l'initialisation vu que c'est la barrière de l'interrupt qui sera start et stop

Pour l'interrupt -> Interrupt: ... cela ne peut être utilisé qu'une seule fois malheureusement

Dans l'interrupt :
- if Sens 1 -> 2 : if hint0flag=1 or hint2flag=1 then (tous les contrôles chrono démarré) end if et à la fin SetIntFlags or %00000101,%00000101
- else Sens 2 -> 1 : If hint1flag=1 or hint2flag=1 then (tous les contrôles chrono démarré) end if et à la fin SetIntFlags or %00000110,%00000110
- et en dernier return pour la boucle initialisé par l'interrupt

La configuration des barrières n'aura pas d'effet, il reste dans celle au moment du start et l'appel des mémoires est impossible

Une fois le chrono arrêté : j'attends 5 sec. et remet le chrono à zéro pour revenir au début

Il est fort possible que la manière dont je fais l'interrupt ne soit pas la meilleure

J'espère que cette explication vous aidera mieux à comprendre ce que j'ai fait.
 

BESQUEUT

Senior Member
Flag7 est l'overflow du timer interne, donc l'incrément automatique de la variable spéciale Timer.
Ça n'est utile que si on a besoin d'un compteur sur 4 octets pour aller au delà du 1/100 s et/ou de 10 minutes.

Pour moi la permutation des entrées pourrait être un bête commutateur double, ce qui évite une entrée, une sortie et pas mal de complication au niveau du code.

Ces deux pattes peuvent servir plus utilement à alimenter deux afficheurs ou PC via des ports com.

De même la led pour le nombre de barrières, si vraiment indispensable en plus de l'indication visuelle de la position du commutateur, peut être commandée directement par le commutateur.

C'est quoi les mémoires affichées ?

A quoi servent hserin et le bus I2C ?

Quelles seront les données transmises par radio et dans quel sens ?

Je suis surpris qu'on ait que 5s pour lire le chrono. Pour moi, le dernier temps est affiché tant qu'on n'arme pas un nouveau comptage, ce qui provoque la remise à zéro des afficheurs.

Etat0 : démarrage : message de bienvenue aux afficheurs, interruptions désarmées.
Le timer et les Dizaines sont à zéro.
==> passage automatique en état 1 au bout de quelques secondes.

Etat1 : Chronomètre désarmé, en attente.
Envoi en boucle vers les afficheurs du dernier comptage via timer et si nécessaire compteur Dizaines
Surveillance du bouton reset et des autres pré-réglages.

==> appui sur reset
=====> remise à zéro du Timer et des Dizaines
=====> armement de l'interruption de départ par barrière, et si nécessaire de l'interruption de départ par bouton poussoir

Etat2 : chronomètre armé :
Envoi en boucle de la valeur zéro aux afficheurs,

==> Première barrière franchie ou bouton enfoncé :
====> armement de l'interruption d'arrêt, du timer et si nécessaire du flag7

Etat3 : chronomètre déclenché
Envoi en boucle vers les afficheurs du comptage via timer et si nécessaire compteur Dizaines

==> Première ou Deuxième barrière franchie ou bouton enfoncé :
====> désarmement du timer et des interruptions

On passe en état1

Suivant la philosophie de développement, on peut avoir :
- soit autant de boucles principales que d'états,
- soit une seule boucle principale, une variable "état" et un select case (state machine)

Dans la deuxième hypothèse, l'état 0 n'est pas pris en compte par la state machine : c'est juste une phase d'initialisation.
Du coup le formatage des données et l'envoi aux afficheurs et aux PC via ports série est toujours le même.
Et puisque l'essentiel est fait dans les interruptions, il n'y a guère que l'état1 qui soit différent des autres...
 
Last edited:

ddaweb

New Member
En effet, J'aurais pu avoir les leds sur un double inverseur ... mais ...
Les sorties leds me servent également de latch de la programmation des barrières quand le chrono est lancé : je regarde l'état des leds au lieu des entrées car elles ne peuvent plus avoir d'effet au risque d'obtenir des incohérence si quelqu'un viendrait à basculer un ou les 2 interrupteurs ... l'interface chaise-clavier fait souvent du grand n'importe quoi :mad:
Durant mes tests approfondis j'ai eu des comportement très bizarre en changeant tout et rien à tout moment, avec le lactch, plus de surprises.
Si le chrono est mal configuré pour le parcours ... et bien tan pis pour l'utilisateur : il devra attendre le chien suivant, il n'avait qu'à faire attention avant le départ ! (le chrono manuel est là pour ce genre de cas).

Pourquoi ce latch ? : au démarrage du chrono, je met hors service toutes les barrières durant 5 sec. (ex. de problème : si 1 seule barrière et le chien la fait tomber au départ) lorsque je sort de ce temps, je vérifie l'état des barrières et si toujours en alarme, le chrono passe en mode manuel (arrêt via le BP START/STOP) ... par contre si la barrière est bien remise et au repos durant 5 sec. consécutives, le chrono repasse en mode automatique (le personnel de terrain va la remettre en place avec beaucoup de alarme-repos : le chrono va s'arrêter si je ne désactive pas les barrières ... d'où 5 sec consécutives au repos) ... c'est là que je regarde à nouveau la configuration des barrières.

Les mémoires sont utilisées en cas de problème, on peut regarder les 8 derniers temps (sans éteindre le chrono) ... au besoin, je pourrais en ajouter car w20 à w27 libres.
Il arrive également que les juges demandent les derniers temps pour adapter le temps qu'ils ont prévu au départ.

hserin : il ne me sert à rien pour l'instant, je n'utilise que le hserout pour l'afficheur LCD ... en cas de communication, je l'ai réservé.

Le I2C : au cas où j'aurais besoin de modules supplémentaires, pour l'instant je pensais à une communication vers un PC ... là il y a matière avec une réponse de Piem : serin-serout .

Le RF : pour l'instant les barrières sont en filaires, mais j'ai le projet de les faire en RF, c'est la barrière qui enverrait le top, le chrono n'envoie rien -> c'est un module supplémentaires, un bornier est présent sur le chrono pour modifier le raccordement vers ce module.
J'aurais pu mettre l'adresse dans la programmation, mais j'ai voulu le rendre plus souple si je viendrais à le construire pour un autre club.
L'adresse hardware n'est lue que durant l'initialisation du chrono ... dès qu'il prêt à fonctionner, elle est en mémoire.

Le boitier a de la place pour ajouter des circuit imprimés pour des modules supplémentaires.

Maintenant, ne soyons pas plus catholoque que le pape, le chrono doit être au 1/100 et ne dure jamais plus de 2 min. : avec 10 min. actuellement, j'ai largement assez ;)
Le jour où on passe au 1/1000 (ce que je doute), je ferai l'adaptation.
 

ddaweb

New Member
Hummm il y a eu un édit durant ma réponse ... loool

Je suis surpris qu'on ait que 5s pour lire le chrono. Pour moi, le dernier temps est affiché tant qu'on n'arme pas un nouveau comptage, ce qui provoque la remise à zéro des afficheurs.
Ce n'est pas un problème vu que le temps se met alors sur la 2me ligne jusqu'à l'arrêt du chrono suivant, tandis que la première ligne ré-affiche comment le chrono va fonctionner pour le chien suivant (peut être modifié et la modification sera affichée).

Maintenant j'essaie de comprendre vos étapes de fonctionnement :p

==> appui sur reset
C'est une étape que j'ai volontairement supprimée car il était régulier que par distraction (je vais dire cela), ils n'appuient pas sur le reset.
J'ai mit 5 secondes, c'est un do val_temps=timer if val_temps>500 then ... loop qui détermine ce temps (le timer ayant été mit à 0 après avoir fait le FIFO des mémoires)
 
Last edited:

BESQUEUT

Senior Member
ah ok, je comprends mieux si il y a (au moins) deux lignes sur chaque afficheur.
Du coup, on pourrait envoyer une commande "changement de chien" lors du reset manuel ou automatique
et les afficheurs se chargent de mémoriser les chronos précédents sur la ou les lignes inférieures tout en affichant les données "temps réel" sur la première ligne.
Lors de la réception d'une commande "changement de chien" on décale les lignes inférieures d'un rang vers le bas, et on recopie la dernière valeur temps réel sur la deuxième ligne.

Je ne sais toujours pas à quoi servent les mémoires ?
 

ddaweb

New Member
Je ne sais toujours pas à quoi servent les mémoires ?
Je suppose que vous parlez des 8 derniers temps ...
Je serais tenté de vous dire à rien ... looool
Mais par expérience, je sais que les personnes qui s'occupent du chrono (secrétariat du terrain) ne sont pas toujours appliquées et parfois ils oublient de noter le temps ... c'est donc un moyen de retourner en arrière pour le récupérer ... j'ai essayé de trouver un bon compromis avec 8 (un multiple de 2 vu les 2 lignes du LCD).
ah ok, je comprends mieux si il y a (au moins) deux lignes sur chaque afficheur.
Uniquement le LCD.
L'afficheur extérieur n'aura qu'une ligne (5 digits) et reste sur le dernier temps jusqu'au démarrage du chrono suivant :
Dès que le chrono tourne, j'envoie, en temps réel, le temps à afficher (val_temps) ... chrono arrêté, il n'y a plus d'envois, donc ne bouge plus.
Code:
affichage_temps_chrono: 
    bintoascii val_temps, b1,b2,b3,b4,b5            'decomposition ascii
    hserout LCD,(254,136,b1,b2,b3,",",b4,b5," s")        'affichage LCD 1ere ligne : temps
    sertxd ("-",#val_temps)                        'RS232 afficheur exterieur : envoi du temps instantanne en ASCII
    return
Le "-" annonce qu'un temps va arriver et le picaxe de réception va faire attention à ce symbole :
Code:
; *************** Premier temps = 00000 ***************
bintoascii val, b1,b2,b3,b4,b5            'decomposition ascii
hserout LCD,(254,136,b1,b2,b3,",",b4,b5," s")    'affichage LCD 1ere ligne : temps = 0

; *************** Reception d'un temps ***************
debut:
Serrxd ("-"),#val                             'RS232 : reception du temps du chrono (en ASCII) -> 0 = arrete
    if val>0 then
        bintoascii val, b1,b2,b3,b4,b5            'conversion du temps pour LCD
        hserout LCD,(254,136,b1,b2,b3,",",b4,b5," s")    'affichage LCD 1ere ligne : temps
        if check>20 and check<40 then        'clignotement du point si chrono en route
            low A.0
            check=timer
        else if check>40 then
            check=0
            timer=0
        else
            high A.0
            check=timer
        end if
    else
        high A.0
    end if
goto debut                                'attente d'un temps
Ici, en mode test, c'est un LCD ... le définitif sera 5 digits 7 segments

A l'arrêt du chrono, j'envoie 3x le temps final du chrono (par sécurité) et ensuite 3x le temps 0 pour allumer le point en fixe (une petite pause entre chaque envoi).
Comme les digits auront un latch, je ne modifierai pas ce temps avec l'envoi du 0.
 
Last edited:

BESQUEUT

Senior Member
L'initialisation me semble un peu compliquée, et le commentaire est inutile (mais c'est pas bien grave...):
Code:
; *************** Premier temps  ***************
hserout LCD,(254,136,"000,00s")
A mon sens, le clignotement du point ne sert à rien :
- ou bien le chrono tourne et on voit bien que les chiffres changent,
- ou bien il affiche le temps final et on voit bien que les chiffres ne changent pas,
- ou bien il affiche 000.00 et on on voit bien qu'on attends que le chien parte.

Accessoirement, si vraiment le point doit clignoter (ou autre chose), la variable check ne sert à rien. Autant tester directement Timer.
Code:
if Timer>40 then
    Timer=0
else if timer>20 then
     low A.0
else
     high A.0
endif
Et s'il n'y a qu'une seule ligne, il n'est pas nécessaire de signaler un changement de chien, donc l'envoi du code zéro ne sert à rien.

Je ne vois pas en quoi le fait d'envoyer 3 fois un message constitue une sécurité ?
S'il manque un octet sur le dernier envoi, l'affichage sera définitivement faux.

Si j'ai bien compris, il y a aussi un ou plusieurs PC en réception. J'imagine que pour eux on n'envoie que le temps final, et une seule fois par chien ?
S'il existe un risque que des données soient perdues lors de la transmission, il faut sécuriser le protocole...

Et juste parce que la vue d'un GOTO en annonce d'autres, merci de remplacer ça par un DO...LOOP
 
Last edited:

jojojo

Senior Member
Le RF : pour l'instant les barrières sont en filaires, mais j'ai le projet de les faire en RF, c'est la barrière qui enverrait le top,

Je ne suis pas sûr que cela soit une bonne idée, si l'on veut garder le 100ième de seconde.
Même si le code Manchester est très fiable, il impose des délais non négligeables, et pas toujours prévisibles.
 

ddaweb

New Member
@BESQUEUT
Bonne idée le code avec 000,00 s ... mais le LCD est juste un test. Le définitif sera en BCD (via le picaxe) avec des circuits ad-hoc pour piloter les 5 chiffres 7 segments (je vais tout de même prévoir le 1/1000, espace libre).
Pour le point qui clignote, c'est purement cosmétique et rassure ceux qui regardent (oui le timer simplifie le code) ... sinon, en effet pas de grande utilité.
Bonne remarque pour l'envoi, si le dernier loupe c'est foutu : je peux faire une comparaison avec le précédent et doit être = pour être valide ... je pourrait également changer le caractère d'annonce '+' au lieu de '-' ... celui avec '+' devra être >= à celui avec '-' (sera souvent > de +/- 5/100) ... je vais réfléchir à cela ;)
Je dois dire que le câble série sera le plus long possible, je commence avec 15m et coupe jusqu'au moment où la communication est stable : câble réseau CAT 6A. Je crois qu'il sera <= 10 m, cela dépend du picaxe et la tension qu'il délivre.
Pour le PC : le top départ avec valeur 0 et le top arrêt avec la valeur val_temps
Heuuuu oui pour le goto ? cela ne revient-il pas au même ou pour le µC c'est plus efficace ?

@jojojo
Qu'il y ai un retard avec la transmission, j'en étais conscient, mais naïvement je pensais que le retard du Stop aurait compensé celui du Start pour devenir nul en différence de temps. Si ce délai est aléatoire, en effet il y aura des différences de temps.
La transmission n'est pas de longue portée : très grand max 20 m sur terrain dégagé.
 

PieM

Senior Member
je vais tout de même prévoir le 1/1000, espace libre
Et beh, si maintenant on en est au 1/1000 de seconde, avec un déclenchement via HF sur du basic interprété, bonne chance !
A titre indicatif, une liaison série peut durer entre 5 et 15 ms rien que pour le serout, un peu plus pour du RFout, et même punition lors de la réception en serin ou rfin.
Et concernant les interruptions, elles sont évaluées entre chaque ligne de programme. C'est de la pseudo interruption hard.

La transmission n'est pas de longue portée : très grand max 20 m sur terrain dégagé.
Pas grand chose à voir avec le retard de transmission!
 

ddaweb

New Member
Naaaan on n'en est pas au 1/1000, je compte juste laisser un espace libre dans l'afficheur au cas où quelques imbécile prendraient cette décision ridicule ... l'adaptation serait alors plus facile.
Pour le chrono c'est le picaxe qui donne le temps, les transmission vers LCD et l'afficheur ne seront que le temps réel du chrono transmit.

Perso je ne suis absolument pas fan du sans fil, quel qu'il soit d'ailleurs, chez moi je suis en réseau câblé pour cette raison ...
Mais il faut avouer que cela peut être facile, dont pas de câble qui parcours le terrain dans lequel les concurrents ou personnel de terrain peuvent se prendre les pieds ... sans compter la mise en place
 

BESQUEUT

Senior Member
Pour moi, le lien entre les barrières et le chrono est préférablement câblé (en tout ou rien)
Pour les afficheurs et le PC, ça peut être n'importe quoi, y compris si ça introduit un décalage car ça n'influe pas sur la précision du chrono.
En dessous de 30m avec un bon câble le RS232 est bien jusqu'à 19200 bauds (en +-15 V avec les circuits ad hoc) Au delà, baisser la vitesse ou passer en RS485.
Le RF est très bien avec les nouveaux modules qui prennent en charge la correction d'erreur.
Sinon, c'est compliqué de sécuriser la transmission , mais faisable.

Pour faire un chrono au 1/1000, (sans utiliser un Ardu...o ou un Tee...y) le plus simple est d'utiliser une horloge et un quartz horloger, puis un compteur binaire à n bits qu'il suffit de lire de temps en temps...
Sinon et si un 6 ième digit est imposé, on peux avoir un timer en 1/200 et afficher soit zéro soit 5 sur le dernier chiffre.
Mais le temps total sera limité à 5 minutes, ou alors il faut gérer l'overflow...

Pour les questions de style de développement (auxquelles je suis très attaché...) :
- un style limpide, voire trivial, marche du premier coup,
- il est facile à soumettre à d'autres lecteurs,
- il nécessite moins de commentaires et d'explications,
- il est plus facile d'y introduire des améliorations,
- et ces améliorations ne dégradent pas le fonctionnement du reste du programme...
- il est souvent plus rapide et prends moins de place en mémoire, mais on peut choisir d'optimiser l'un ou l'autre.

Voir par exemple les deux versions du check timer (qui au final font la même chose...)

La qualité et la lisibilité d'un programme sont inversement proportionnels au nombre de GOTO.
Au delà de 4 ou 5 je déclare en général forfait et je ré-écrit tout en supprimant ces merdes...

L'utilisation de macros peut également améliorer la lisibilité du code.

Pour le PC qui enregistre les infos dans Access, on n'a rien à faire du top départ. Seul le temps à l'arrivée est important, et on peut l'envoyer quand on veut du moment que le bon temps est attribué au bon chien.

Si le PC doit aussi afficher le chrono en temps réel, il faut le traiter comme un afficheur sur un port série.
 
Last edited:

BESQUEUT

Senior Member
@BESQUEUTPour le point qui clignote, c'est purement cosmétique et rassure ceux qui regardent
Je ne comprends pas en quoi c'est rassurant ?
Si les chiffres changent à toute vitesse, c'est bien que le chrono tourne.
Et s'ils ne changent pas, le point ne clignote pas non plus.
Le point clignotant n'est utilisé que pour marquer les secondes sur une horloge qui n'affiche que heures et minutes. Dans ce cas en effet, l'absence de clignotement montre que l'horloge est bloquée.
Mais si on affiche les secondes, c'est déjà inutile...
Avec l'affichage des 1/100 (voire plus...) ça devient carrément loufoque... mais bon...
 

BESQUEUT

Senior Member
Et beh, si maintenant on en est au 1/1000 de seconde, avec un déclenchement via HF sur du basic interprété, bonne chance !
A titre indicatif, une liaison série peut durer entre 5 et 15 ms rien que pour le serout, un peu plus pour du RFout, et même punition lors de la réception en serin ou rfin.
Et concernant les interruptions, elles sont évaluées entre chaque ligne de programme. C'est de la pseudo interruption hard.
!
Ce qui est important, c'est le délai de démarrage et d'arrêt du timer sur un signal tout ou rien, soit quelques instructions.
A 64 Mhz c'est sans doute une fraction de ms, et sans doute assez similaire au démarrage et à l'arrêt.
C'est la seule partie qui soit traitée par le BASIC interprété. Le timer interne et l'incrémentation de la variable Timer sont gérés par le firmware et par le silicium, donc à une vitesse bien suffisante.

Evidemment, il serait peu judicieux d'utiliser une liaison série entre les barrières et le chronomètre.
Mais entre le chrono et les afficheurs, on s'en moque car ça n'influe pas le chronométrage.
Comme vous le dites, c'est de l'ordre de grandeur du traitement d'une instruction, soit autour de 20 us à 64 mhz.
En plus comme l'a remarqué DDAweb, c'est sensiblement le même au départ et à l'arrêt, donc ça se compense au moins partiellement.
Le 1/1000 s ne me semble pas utopique.
Avec un timer à cette fréquence il faut impérativement gérer le débordement de la variable Timer, et ce en moins d'une ms.
sur un 28x2 à 64 mhz :
If Timer>10000 then prends environ 62 us
Timer=Timer-10000 prends environ 61 us
123 us donc,mais il faut ajouter le déclenchement de l'interruption. Ça semble jouable.
Si c'est trop juste, ou pourrait travailler avec un timer a 1/500 s, ce qui est déjà très bien.
 
Last edited:

ddaweb

New Member
PieM said:
Quelle raison ? pas compris... Ondes herziennes ou fil, le traitement de l'info au départ et à l'arrivée est le même.
Ce sont les ondes qui m'ennuient ... surtout leur fréquence, mais bon je ne souhaite pas faire débat là dessus.
Comme tout il y a les adeptes et les contres ... ou comme moi qui essaie de les diminuer le plus possible tout en admettant leur facilité et les utilisant par parcimonie.
 
Last edited:

ddaweb

New Member
Pour le RF, j'ai un peu regardé le système utilisé dans le lien #1 : http://electromag1.wifeo.com/chrono-agility.php
Côté consommation c'est ingénieux de n'émettre que lors d'un top, de plus pas trop besoin de sécurisation ... je devrai juste implémenter une adresse physique identique au chrono (pour rappel : en mettre plusieurs lors d'un même concours).
Je suis juste inquiet pour le démarrage du module RF qui doit se stabiliser en fréquence.
Modules que je regarde :
- Récepteur : https://www.gotronic.fr/art-recepteur-am-rx-am4sf-8602.htm
- Emetteur : https://www.gotronic.fr/art-emetteur-am-tx433-3715.htm
Sinon, comme je l'ai déjà dit : le Xbee qui a tout ce qu'il faut, sauf le prix.

@BESQUEUT
Les GOTO, je ne les utilise pas à outrance, les GOSUB plus régulièrement ... je préfère l'orientation objet pour le code, ce qui a le mérite d'éviter de coder plusieurs fois la même chose (surtout lors d'un changement : 1 seule fois à faire !).
Comme je privilégie le if - else ou if - else if (le if étant celui le plus utilisé) au if seul plusieurs fois ... en PHP cela accélère l'interprétation.
Pour le PC, l'Access enregistre 3 lignes/temps : le départ, l'arrivée et le calcul du temps du chien ... ce n'est pas moi qui l'ai fait, je dois m'y adapter.
C'est lier au chrono qu'il utilise : envoi de l'heure au 1/10000 (4 décimales à la seconde) au départ, l'heure à l'arrivée et le temps du chien est donc la différence des 2 heures ... mais bon, seuls les 1/100 sont traités je crois, ou alors arrondi au 1/100.

@tous :
Je crois que je vais rester sur la base du 1/100, il n'est pas demandé plus pour le temps des parcours.
S'il y a trop de retard cumulés, je pourrais passer en 1/200, mais à priori pas trop utile dans mon cas.
Je vais en tout cas passer par le qwarz tout de même, cela ajoutera une plus grande stabilité au timer.

Je vais plus que probablement repenser mon code durant les vacances ... je prends ma platine test avec, le principe glogal va fortement rester identique à maintenant, il a longuement été pensé avant de me lancer et mes expériences sur le terrain ont dictées certaines fonctionnalités qui vous semblent peut-être loufoques.
La taille compilée fait +/- 2800 / 4k ... aucune idée si c'est beaucoup ou pas.
 

PieM

Senior Member
Ce qui est important, c'est le délai de démarrage et d'arrêt du timer sur un signal tout ou rien, soit quelques instructions.
A 64 Mhz c'est sans doute une fraction de ms, et sans doute assez similaire au démarrage et à l'arrêt.
lire #30 - Démarrage et arrêt sur interruption sont pris en compte à la fin de l'interprétation de l'instruction basic en cours.
C'est à dire que si le top intervient aléatoirement au moment d'un serout le retard est de plusieurs centièmes de seconde. Les 64MHz ne changent rien.
En résumé, un comptage fidèle au 1/100e est déjà une illusion avec un µP interprété.
 

ddaweb

New Member
Quelqu'un pourrait m'indiquer les différentes méthodes pour faire des interruptions (avec l'initialisation) ?
J'ai déjà essayé plusieurs méthodes, seule celle que j'ai utilisée fonctionne correctement, mais de ce que j'ai pu lire, il y a moyen d'en faire d'autre (dont sur le timer).
Il doit certainement me manquer quelque chose avec les codes essayés.

Je fais une interruption sur le start, j'ai toujours l'espoir d'en ajouter une sur le stop.

Je remet le code simplifié de mon interruption :
Code:
hintsetup %00000101 
setint %00000001,%00000001
setintflags or %00000101,%00000101

chrono_demarrage:
    ; Code
goto chrono_demarrage     'boucle d'attente pour le start
Interrupt:
if hint0flag=1 or hint2flag=1 then
    ; Code
end if
SetIntFlags or %00000101,%00000101    '----- reinitialisation flag interrupt : nécessaire pour l'interruption
return
Je n'ai jamais compris à quoi servait le setint %00000001,%00000001, car quel que soit le sens des barrière, il a la même valeur (le flag interrup change à %00000110 au lieu de %00000101)

J'avoue que je ne n'ai pas toutes les connaissances de programmation, juste suffisamment de notions pour m'en sortir.
 
Last edited:

ddaweb

New Member
Afin que vous compreniez comment j'ai conçu le chrono, j'ai essayé de mettre le plus clairement possible les différentes étapes.
Le texte est coloré pour une meilleure compréhension et quelques informations intégrées.
Je viens de me rendre compte en le faisant que je vais devoir modifier le code lors du test des barrières au démarrage du chrono, en ajoutant un durée ininterrompue du repos ... une amélioration, pas une nécessité.

Cela pourrais vous aider à mieux pouvoir répondre aux question que je pose.

Edit :
En regardant un peu mon code, j'ai remarqué des lignes qui se répètent (4x pour certaines), j'ai donc fait une sous-routine mode_manuel en plus et mis le principe du chrono à jour.
 

Attachments

Last edited:
Top