Chrono Agility : nouveau

BESQUEUT

Senior Member
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é.
Vous avez raison.
Dans ce cas, je ne vois pas d'autre solution que l'utilisation d'un µP compilé pour la partie strictement chronométrage, le reste étant réalisé par un ou plusieurs Picaxes pour leur facilité de mise en oeuvre. La communication peut se faire sur un port série ou en I2C.
 

ddaweb

New Member
Je relance un peu la communication i2c et les différents paramètres.

Côté chrono (picaxe 28x2)
Code:
Au top START :
    hi2csetup i2cmaster, %00000100, i2cfast, i2cword
    hi2cout 0,(val_temps,hint2flag,1)
    hi2csetup off
Au top STOP
    hi2csetup i2cmaster, %00000100, i2cfast, i2cword
    hi2cout 0,(val_temps,start_stop,1)
    hi2csetup off
J'utilise le flag de l'interruption du BP START/STOP au démarrage et l'état du BP au STOP

Côté picaxe pour le PC
Code:
;Communication vers PC - i2cslave (28/05/2019)

#picaxe 20X2                    'Type de Picaxe

;w0 -> w2 : reserve val_temps_cent        'b0 -> b5 = lecture des temps ... NE PAS UTILISER POUR AUTRE CHOSE
;w3 -> w5 : reserve val_temps_sec        'b6 -> b11 = lecture des temps ... NE PAS UTILISER POUR AUTRE CHOSE
;w6 -> w8 : reserve val_temps_min        'b12 -> b17 = lecture des temps ... NE PAS UTILISER POUR AUTRE CHOSE
;w9
symbol tx=w10                    'envoi d'un temps = 1
symbol val_temps=w11                'memorisation temps chrono
symbol val_temps_cent=w12
symbol val_temps_sec=w13
symbol val_temps_min=w14
symbol val_temps_calcul=w15
symbol mode=w16                    'Mode du chrono : 1 = manuel - 0 = automatique
;...
;w27

i2cslave %00000100, i2cfast, i2cword    'Initialisation du i2c Slave adresse 4

main:
    tx=0
 
    hi2cin 0,(val_temps,mode,tx)
 
    if tx=1 then
        if val_temps=0 then    '---------- Top START
            if mode=0 then
                sertxd ("I 9999 c0  00:00:00:0000 00","CR")    'Mode AUTO
            else
                sertxd ("I 9999 c0M 00:00:00:0000 00","CR")    'Mode MANUEL
            end if
        else                '---------- Top STOP
            val_temps_cent=val_temps//100     '=> isole la partie centièmes de secondes
            val_temps_calcul=val_temps/100     '=> supprime les centièmes de secondes: reste le temps en seconde entières
            val_temps_sec=val_temps_calcul//60     '=> isole la partie secondes
            val_temps_min=val_temps_calcul/60     '=> supprime les secondes: reste le temps en minutes entières
         
            bintoascii val_temps_min, b1,b2,b3,b4,b5
            bintoascii val_temps_sec, b7,b8,b9,b10,b11
            bintoascii val_temps_cent, b13,b14,b15,b16,b17
         
            if mode=1 then
                sertxd ("I 9999 c0  00:",b16,b17,":",b10,b11,":",b4,b5,"00"," 00","CR")    'Mode AUTO
            else
                sertxd ("I 9999 c0M 00:",b16,b17,":",b10,b11,":",b4,b5,"00"," 00","CR")    'Mode MANUEL
            end if
        end if
    end if
    goto main
Le bintoascii sert à toujours avoir 2 chiffres pour chaque
Il me semble avoir lu que les 3 premières adresses slave étaient réservées
 
Last edited:

ddaweb

New Member
Aie ... mes essais sont négatifs.
J'ai pu trouver que le code i2c reste à 255, donc erroné !
Je ne rentre donc jamais dans if tx=1 then

J'ai essayé en word et byte

Quelqu'un a une idée de mon erreur, d'un code valide ?
 

PieM

Senior Member
Pour écrire un tel code, vous n'avez visiblement pas lu la doc concernant la liaison I2C.
on initialise un esclave avec hi2csetup i2cslave, Adresse et une seule fois c'est tout
on initialise le maître avec hi2csetup i2cmaster, Adresse, i2cslow, i2cbyte

Un maître va lire ou écrire dans le scrachpad d'un esclave avec hi2cin et hi2cout.
un esclave ne peut qu'aller lire ou écrire dans son scratchpad avec get et put.

La liaison en i2c n'a pas grande utilité ici. Utilisez un serout, ce sera plus simple.
Toujours pas compris l'intérêt d'envoyer autre chose que la valeur temps: on ne met pas le chrono à 0 lors du start ou avant ?
que vient faire le hint2flag dans cette transmission ??
 

ddaweb

New Member
J'ai pas mal lu sur le i2c, mais je n'ai jamais compris comment relire la valeur : je croyais que c'était hi2cin.
Vous m'avez donné l'information : get

Je vais faire un petit retour en arrière pour certaines choses :
1. L'utilité ou non de l'i2c, vous y répondez au post #30 ... afin de laisser le travail du chrono au chrono et augmenter le plus possible sa précision : 2 communications série sont déjà actives -> LCD et afficheur extérieur
2. Le chrono se reset automatiquement après 5 sec., le temps se met alors dans la 2me ligne du LCD et la variable se met à 0 ... trop souvent on oublie le reset quand c'est manuel

Côté initialisation du i2c :

1. Pour le maître, vous dites : on initialise le maître avec hi2csetup i2cmaster, Adresse, i2cslow, i2cbyte
Mon code correspond très fortement:
Code:
Au top START :
    hi2csetup i2cmaster, %00000100, i2cfast, i2cword
    hi2cout 0,(val_temps,hint2flag,1)
    hi2csetup off
Au top STOP
    hi2csetup i2cmaster, %00000100, i2cfast, i2cword
    hi2cout 0,(val_temps,start_stop,1)
    hi2csetup off
Quelques explications :
- Les variables hint2flag et start_stop : servent à envoyer si c'est du manuel ou automatique ... cf les posts avant pour les codes qui seront envoyés au PC
- Utilisation de i2cword : la valeur peut être > 255
- Le 28x2 permet i2cfast me semble-t-il ? Je fais le test avec 2 28x2, je dois vérifier pour le 20x2 prévu !
Je pourrais initialiser le maître au démarrage du picaxe, mais comme il est possible qu'il y ai des autres modules, j'ouvrais la communication sur le slave correspondant ... je sais qu'il existe la fonctionnalité newslave

2. Pour le slave, vous dites : on initialise un esclave avec hi2csetup i2cslave, Adresse et une seule fois c'est tout
Mon code correspond également très fortement, j'ai par contre oublié hi2csetup :
Code:
i2cslave %00000100, i2cfast, i2cword    'Initialisation du i2c Slave adresse 4
Pour la vitesse et le word, je reste cohérent avec le maître.
A partir du main: , c'est la gestion des valeurs et donc le code de travail

En fin de compte je n'étais pas si loin du bon code, le get va me permettre d'aller plus loin
La communication est toujours du chrono (maître) vers le slave
 
Last edited:

PieM

Senior Member
L'utilité ou non de l'i2c, vous y répondez au post #30 ... afin de laisser le travail du chrono au chrono et augmenter le plus possible sa précision : 2 communications série sont déjà actives -> LCD et afficheur extérieur
Et vous allez obtenir le 1/100e de seconde sur le même picaxe? c'est une plaisanterie. Relisez #40 #41
Je ne vois toujours pas de synthèse d'architecture globale après 40 posts.
Il n'y a aucune raison d'envoyer en temps réel une information sur le µC lié au PC. Qd le chrono a fini son comptage, il envoie la valeur sur l'esclave, dont le flag hi2cflag monte à 1. Il peut alors transférer la valeur au PC.
La seule info intéressante est le temps après l'arrivée et le flag manu/auto si c'est vraiment utile.
 

ddaweb

New Member
Et vous allez obtenir le 1/100e de seconde sur le même picaxe? c'est une plaisanterie. Relisez #40 #41
Je ne vois toujours pas de synthèse d'architecture globale après 40 posts.
Il n'y a aucune raison d'envoyer en temps réel une information sur le µC lié au PC. Qd le chrono a fini son comptage, il envoie la valeur sur l'esclave, dont le flag hi2cflag monte à 1. Il peut alors transférer la valeur au PC.
La seule info intéressante est le temps après l'arrivée et le flag manu/auto si c'est vraiment utile.
Je ne comprend pas ce que vous voulez avec l'architecture globale, pouvez-vous clairement m'expliquer ce que vous souhaitez connaître ?
Je me ferai un plaisir de vous le communiquer afin de faire avancer le schmilblick ;)

Voici quelques posts donnant pas mal d'informations :
Au #6, j'explique ce qui doit être transmit au PC ... là je ne suis pas maître du jeu car j'utilise un programme existant fonctionnant de la sorte (le hi2cflag et start_stop va ajouter le M pour le mode manuel ... il y a une ligne pour l'automatique, l'autre pour le manuel, une seule est nécessaire) : donc j'ai besoin du top start et du top stop avec toutes les infos nécessaires pour ce programme ... c'est cela que je compte faire via le i2c.
Au #16, vous avez les sorties série affichant les temps en temps réel sur le LCD et afficheur extérieur.
Au #21, toutes les variables initialisées en fonction des pins et déjà quelques explication du fonctionnement.
Au #40, le principe de fonctionnement du chrono
 

ddaweb

New Member
PieM said:
Et vous allez obtenir le 1/100e de seconde sur le même picaxe? c'est une plaisanterie. Relisez #40 #41.
C'est pour cela que je compte faire le bus i2c pour faire une partie du travail.

Dès que j'aurai trouvé comment faire, je pourrais également déplace l'afficheur extérieur vers ce 2me picaxe (qui s'occuperais donc de l'afficheur extérieur et du PC), mais il faut alors envoyer le temps en continu. Le temps de l'afficheur ne doit pas avoir la précision du chrono, juste le temps final doit être correct. -> ce sont en fait des fonctionnalité optionnelles pas impératives, sur un autre CI.
Le chrono s’occuperait alors uniquement de la gestion du temps et du LCD + i2c.

J'ai encore un problème avec la variable val_temps (c'est sûrement du au word), si j'envoie b1 -> b5 j'ai les bonne infos maintenant (en byte) ... côté hi2cflag et start_stop ce n'est pas encore cohérent + il arrive que des valeurs n'arrivent pas (je vais tester en initialisant le i2c à l'initialisation du chrono au lieu d'ouvrir le i2c uniquement à l'envoi).

Je vous rappelle que je ne suis pas un pro de la programmation, juste quelques connaissances ... veuillez donc ne pas m'en vouloir si je pose des questions qui vous semblent évidentes.
 
Last edited:

BESQUEUT

Senior Member
Comme expliqué par PieM, le Picaxe "NE PEUX PAS" réagir au 1/100 s. tout en gérant des données série...
Même les interruptions hard ne sont pris en compte que de façon aléatoire en fonction de l'instruction sur laquelle ça tombe.
Du coup, dans la boucle d'attente, il ne faut que des pauses ou des instructions super courtes, et surtout pas d'utilisation de port série.

En gros, vous avez un magnifique générateur de nombres aléatoires. Chaque chien a bien un temps, mais ce temps est grossièrement son temps de parcours et finement : n'importe quoi.

J'ai bien quelques idée pour contourner une partie du problème, mais c'est capilotracté et il faudrait faire de véritables tests pour valider que la pratique est conforme à la théorie.
En gros : on lance en parallèle deux Picaxes :
- Le N°1 est le véritable chronomètre et ne fait que ça (et donc aucune com pendant les phases critiques. On utilise un Picaxe 64 Mhz et que des instructions courtes dans la boucle principale.
- l'autre envoie des données en temps réel, (mais on sait que c'est juste décoratif)

Sinon, il y a des µ compilés qui feraient ça les doigts dans le nez, mais c'est une autre histoire...
 

ddaweb

New Member
Une petite question : que fait la variable interne timer durant les TX série ?
Le bus i2c a-t-il une influence comme la communication série ?
Comme il y a moyen de travailler en slow (100k) ou fast (400k) : les 2 fonctionnent correctement.

Dans l'attente de l'interruption, je n'ai, de mémoire, aucunes TX ... elles se font hors interruption ou interruption arrêtée (donc pas de start possible).
Par contre lorsque le chrono démarré, il y a le LCD (et afficheur extérieur que je regarde à déplacer sur le 2me picaxe via i2c) : je lit la valeur du timer juste avant et après l'affichage, idem avant et après chaque sous-routine.

Dans mon cas, les vitesses des séries :
- LCD : 2.400 -> hserout
- Afficheur extérieur : 19.200 -> sertxd

Comme je l'ai déjà soulevé, il est tout à fait envisageable de faire toutes les communication série avec un autre picaxe via l'i2c si cela peut résoudre ou nettement améliorer ce problème.
Je l'ai prévu sur ma plaquette, mais je devrai revoir tout mon code pour faire les même affichages qu'en direct :confused: ... ce ne sera pas facile.
Comme vous dites, le temps durant le fonctionnement n'est pas primordial, le seul qui est important est celui au stop.
Pour le LCD, le plus facile serai évidemment de le laisser sur le chrono ... loool

Par contre, je n'envisage absolument pas les µC compilé, je n'ai d'abord pas les connaissances pour et ensuite je suis déjà trop loin avec le picaxe.
 

ddaweb

New Member
La conversion des secondes en min-sec proposée par @MGU fonctionne nickel ... mais ...
J'ai une autre question : est-il possible de convertir un nombre de 1 chiffre en 0chiffre, ex. 2 en 02 ?

La communication i2c fonctionne dans la majorité des cas, de temps en temps un raté, mais peut-être un question de pause à l'envoi (2 envois consécutifs à l'arrêt du chrono, la pause n'aura donc aucun effet sur la précision ... pour 1 envoi pas de problème) ...
J'ai du bricoler un peu car une partie est transmise en ASCII : 5 chiffres du chrono issus de bintoascii, l'autre en décimal (le status de l'envoi : 0=AUTO - 1=MANUEL - 9=TEMPS pour l'affichage extérieur).
 

ddaweb

New Member
Je n'ai pas reçu de réponse concernant mes questions.
Les principales :
Le bus i2c a-t-il également la même incidence que les communications série ?
La variable interne timer continue-t-elle même durant les différents TX ?

J'ai réussit à mettre au point le TX et RX via i2c, aussi bien pour l'afficheur extérieur, que pour le PC ... donc il n'y a plus que le LCD sur le chrono.
- Pour le TX de l'afficheur extérieur : hi2cout 0,(b1,b2,b3,b4,0,9,1)
- Pour le TX vers le PC : hi2cout 0,(b1,b2,b3,b4,b5,flag2,1) -> START et hi2cout 0,(b1,b2,b3,b4,b5,bit0,1) -> STOP (flag2 et bit0 ont des valeurs 0 ou 1 pour le mode automatique ou manuel)
- Pour le RX du 2me picaxe :
get 1, b1 - get 2, b2 - etc ...
- J'ai choisi le
i2cslow ... plus stable

J'ai des résultats stables, mais je vais tout de même mettre une sorte de watch-dog en cas de raté éventuel.
Voici un petit screen du résultat, pour l'instant toujours sur la même sortie série ... j'ai revu une partie du code du chrono en le simplifiant.
L'afficheur n'affichera pas les centième durant le décompte, pour les mettre à l'arrêt.


Picaxe2_RX.PNG
 

BESQUEUT

Senior Member
Le i2c c'est aussi une liaison série.
Comme déjà expliqué toute tentative d'envoyer des données pendant le chronométrage implique une prise en compte aléatoire de l'interruption de fin.
Seule solution : utiliser pour le chronométrage un picaxe qui ne fait que ça.
 

BESQUEUT

Senior Member
Je n'ai pas reçu de réponse concernant mes questions.
Les principales :
Le bus i2c a-t-il également la même incidence que les communications série ?
La variable interne timer continue-t-elle même durant les différents TX ?
Lire le manuel : Tome 2 page 276 :
Appendix 4 - Possible Conflicting Commands
Le problème est qu'on ne sait pas exactement qui perturbe qui et avec quelle ampleur.
Selon PieM, une commande série peut retarder la prise en compte d'une interruption, et je le crois volontier.
De combien la lecture d'un compteur en I2C par un autre Picaxe est-elle susceptible de retarder la prise en compte d'une interruption ?
Il faudrait tester.

Votre watch dog ne sert à rien. S'il y a un raté, aucune importance. Seul le temps final compte, et il ne faut pas le rater !

Pour tester, il faut une base de temps précise qui déclenche deux interruptions avec un délai connu, par exemple deux minutes, et qui soit stable et vérifiable au moins au 1/100 s. Un picaxe sur quartz peut générer ce signal. S'il ne fait rien d'autre, le délai sera stable. Par contre, difficile de l'étalonner au 1/100 à moins d'utiliser un chrono ad hoc ou un micro compilé.
 

ddaweb

New Member
BESQUEUT said:
Pour tester, il faut une base de temps précise qui déclenche deux interruptions avec un délai connu, par exemple deux minutes, et qui soit stable et vérifiable au moins au 1/100 s. Un picaxe sur quartz peut générer ce signal. S'il ne fait rien d'autre, le délai sera stable. Par contre, difficile de l'étalonner au 1/100 à moins d'utiliser un chrono ad hoc ou un micro compilé.
Je ne vais pas encore me tracasser sur les erreurs de précision du picaxe, j'ai compris qu'il n'est probablement pas le meilleur pour un chrono.
Je vais garder le LCD sur le chrono par facilité, le reste sur le 2me picaxe via i2c : il faut bien prendre une décision à un moment donné pour avancer et comme je l'ai dit, je suis déjà trop loin dans la fabrication !

Je vais adjoindre un qwartz et ensuite, avec notre chrono actuel et un µC compilé, je ferai des comparaison de temps avec un BP unique pour le démarrage et arrêt des 2 chronos (sur une barrière ... avec 2 c'est de toute manière identique) ... ajuster la fréquence du picaxe si nécessaire.
Je vais faire le réglage le plus précis pour la plage de temps des chiens jouant pour les premières places : 30 à 45 sec ... c'était dans mes prévisions
de finalisation.
De toute façon, si le timer reste toujours bien actif en arrière plan durant les communications, je ne pense pas qu'il y aura de grosse différences dans la durée du temps chronométré.

Le pseudo watch-dog est pour le 2me picaxe, durant mes essais, le start et le temps final ont toujours été corrects, c'est l'arrêt au PC qui posait un problème une fois sur xx ... le temps continue alors d'être envoyé à l'afficheur extérieur.
Cet envoi au PC met également un bit à 0 arrêtant l'envoi vers l'afficheur extérieur car c'est lui le dernier envoi ... je vais donc détecter une dizaine de valeur identiques pour relancer l'envoi au PC et alors arrêter l'envoi vers l'afficheur extérieur.
Je vais également prévoir que si un temps est envoyé à l'afficheur sans envoi vers le PC, un envoi de start sera envoyé au PC.
Je dois atteindre presque les 100%.

BESQUEUT said:
Lire le manuel : Tome 2 page 276 :
Appendix 4 - Possible Conflicting Commands
Le problème est qu'on ne sait pas exactement qui perturbe qui et avec quelle ampleur.
Je viens de jeter un coup d'oeil dans le manuel français ... la bonne nouvelle, c'est que je ne devrais pas (plus depuis le TX sur l'afficheur via i2c) être trop affecté par cela.
Le i2c est initialisé au démarrage du picaxe (maître et slave), pas d'interrupt pour le stop, plus de série énuméré ...
Bref les différentes fonctions de cet annexe ne sont pas utilisées durant le démarrage du chrono ... ouf
Une erreur possible est durant la boucle en if - else if pour le stop, mais je crois que c'est de l'ordre du millième de seconde.
 
Last edited:

PieM

Senior Member
De toute façon, si le timer reste toujours bien actif en arrière plan durant les communications, je ne pense pas qu'il y aura de grosse différences dans la durée du temps chronométré.
Visiblement vous n'avez pas compris que la lecture du timer peut intervenir de manière aléatoire par rapport aux communications et aux instructions chronophages.
Quant à ajouter un quartz pour vouloir après "ajuster la fréquence du picaxe si nécessaire. ", il y a comme un soucis.
Vous avez persisté à mettre le chrono en tant que maître de l'I2C, ce qui était le pire au niveau de la gestion du timing.
Une solution logique concernant la répartition des tâches (qu'on ne connait toujours pas!) vous a été donnée en #49.
il faut bien prendre une décision à un moment donné pour avancer et comme je l'ai dit, je suis déjà trop loin dans la fabrication !
Autrement dit: je ne sais pas conduire, je ne sais pas trop où je vais, mais je n'écoute rien et j'accélère car je suis en retard...
Bonne route !
 

ddaweb

New Member
@PieM
J'adore votre façon de dire que c'est mauvais, mais à plusieurs reprises je vous ai demandé de l'aide et ce vous souhaitiez connaître.
Je ne suis qu'un profane et dire que c'est mauvais sans donner une solution avec au moins un début de code, ce qui serai nettement plus constructif, ne m'aide absolument pas (désolé d'alors ne pas vraiment en tenir compte si en cherchant je n'ai pas votre solution idéale).
Le chrono avec i2c en maître n'est pas bon ... soit, il doit être en slave donc, comment dois-je alors lire les valeurs du chrono ? hi2cin ? Autrement ?

je vous ai bien lit (ainsi @BESQUEUT), c'est déjà pour cela que j'ai déplacé le TX série de l'afficheur sur le i2c puisque ce bus sera bien présent (le 2me picaxe reprend l'afficheur extérieur et le PC alors qu'au départ que le PC), que j'ai modifier une partie de mon code du chrono afin de diminuer au max. les communications ... mais les affichages doivent bien avoir lieu !
Le 2me picaxe n'est vraiment pas encore programmé d'une manière définitive et peut donc très facilement être adapté à une nouvelle conception.

Contrairement à ce que vous dites, je sais où je vais, par contre je ne sais pas toujours comment y arriver ... la raison de venir ici.
Je suis ouvert à tout, du moment que je sais comment le mettre en oeuvre et que cela soit réalisable avec le code du chrono lui-même (les fonctionnalité sont bien définies pour des raisons pratiques et par mon expérience sur l'utilisation des chronos depuis plusieurs années).
 

ddaweb

New Member
Nickel, vous donnez en effet des fonctions à utiliser ... mais nullement comment mettre cela en oeuvre, en tout cas en ce qui me concerne comme profane qui ne saisit pas (encore) le fonctionnement profond du bus i2c (tout nouveau pour moi).
Donc, les données brutes sont là en effet ... mais jamais comment les utiliser.
Malgré tout, j'ai réussi une communication cohérente du maître (chrono) vers le slave, mais pas (encore) dans l'autre sens.
J'ai beau lire le manuel, il reste tout de même pour ceux qui ont déjà des connaissances.

En effet alors abdiquons ensemble si cette connaissance vous vous la gardez :cautious:
Il m'a toujours semblé que les forums étaient là pour aider les débutants afin qu'ils apprennent et peuvent alors évoluer, désolé que je ne vous comprenne pas.
Sans rancune ;)

Soit dit en passant, le bus i2c, que ce soit du chrono vers le slave ou dans l'autre sens, cela n'aura pas d'impact sur le programmation des fonctionnalités du chrono lui-même, sur lesquels ne souhaite pas faire de modifications car mûrement réfléchit avant de me lancer.

Edit:
Je vais tout de même essayer, avec de la persévérance et des tests, j'y arriverai probablement :p
 
Last edited:

PieM

Senior Member
Soit dit en passant, le bus i2c, que ce soit du chrono vers le slave ou dans l'autre sens, cela n'aura pas d'impact sur le programmation des fonctionnalités du chrono lui-même, sur lesquels ne souhaite pas faire de modifications car mûrement réfléchit avant de me lancer.
Si vous le dites... après avoir mûrement réfléchi! De toute façon vous avez décidé de faire ce que vous voulez, sans lire ni comprendre ce qu'on vous écrit.
Quand on est débutant, on arrive pas avec un programme de 550 lignes (sic) que personne n'a vu, avec des opinions arrêtées sur des méthodes et moyens à mettre en œuvre.
 

ddaweb

New Member
Là je trouve que vous êtes de très mauvaise foi ... à chaque discussion sur une fonctionnalité, j'ai mit le code correspondant.

Si vous souhaitiez le code complet, il suffisait de me le demander, je vous aurai envoyé le fichier .bas en MP...
Je n'ai, jusqu'à présent, jamais trouvé l'intérêt de mettre le code complet, indigeste à mon sens et trop spécifique avec mes propres critères de fonctionnement (dont j'ai également clairement donné une explication complète fin de la première page), alors que je posais des questions bien spécifiques afin de m'améliorer et améliorer le code.

Je suis, par contre, absolument certain qu'avec vos connaissance vous feriez mieux que moi (plus simplement probablement), mais j'ai fais, en fonction de mes connaissances, quelque chose qui tient la route dans son fonctionnement et affichages ...
Côté notre point d'achottement, la précision, je ne peux vous répondre : vous en savez plus que moi.

Dire que je ne lit pas, là encore j'ai montré des changements de cap ... ne pas tout comprendre, je ne contredit pas, mais je l'ai clairement dit.

Pour le bus i2c, pour lequel j'ai posé la question : en mettant le chrono en slave, je devine qu'il faut faire un put vers le scratchpad (si si je vous vous ai bien lu) ... mais je ne sais pas encore comment aller le lire depuis l'autre picaxe, ni certain comment initialiser les picaxes.

Enfin je ne veux pas me fâcher avec vous, soit vous voulez m'aider et alors me donnez des pistes claires, soit c'est clairement non et on en reste là.
 

PieM

Senior Member
Pour le bus i2c, pour lequel j'ai posé la question : en mettant le chrono en slave, je devine qu'il faut faire un put vers le scratchpad (si si je vous vous ai bien lu) ... mais je ne sais pas encore comment aller le lire depuis l'autre picaxe, ni certain comment initialiser les picaxes.
Post #44
on initialise un esclave avec hi2csetup i2cslave, Adresse et une seule fois c'est tout
on initialise le maître avec hi2csetup i2cmaster, Adresse, i2cslow, i2cbyte

Un maître va lire ou écrire dans le scrachpad d'un esclave avec hi2cin et hi2cout.

un esclave ne peut qu'aller lire ou écrire dans son scratchpad avec get et put.

Vous me fatiguez ! Adieu.
 

ddaweb

New Member
Dommage que vous m'ayez apporté le doute avec le #58 ... un simple "oui le hi2cin" en plus de votre réponse m'aurait donné la route à prendre et surtout retiré la peur de mal faire ...

Merci tout de même, je vais pouvoir m'en sortir.
 

ddaweb

New Member
Juste à titre d'info, le chrono en slave fonctionne pour le bus i2c comme quand il était en maître.

@MGU
Comme vous vous êtes énormément investi dans le chrono de "Le Belge", je vais mettre quelque photos de mon chrono pour montrer que je suis déjà très avancé dans la construction ... un test en grandeur réel devrait avoir lieu en août.
J'avais quelques photos dans mon GSM, quand je rentre, j'achève la construction et vous mettrai des photos si cela vous intéresse.
Je dois maintenant le câbler dans le boitier et tester (dont l'alimentation), la grandeur de la platine du chrono de test est la même que le définitif qui lui a des borniers à visser.
A l'arrière, je dois déplacer le fusible du haut car j'ai mal mesuré avec le support du LCD, il sera en dessous de la fiche USB.

.Chrono_face_avant.JPGChrono_arriere.JPGChrono_boitier_juges.JPGChrono_test.JPGChrono_occasion.JPG

Il y a également le chrono d'occasion avec le µC compilé, que j'avais fabriqué avec une autre personne : lui a fait la partie programmation et CI du chrono, moi le boitier. Il a opté pour un système de bus pour tout interconnecter (BP - afficheur - témoins - etc...).
 

BESQUEUT

Senior Member
Je ne vais pas encore me tracasser sur les erreurs de précision du picaxe, j'ai compris qu'il n'est probablement pas le meilleur pour un chrono.
Euh ???
Le but d'un chrono, (à priori hein... je dis ça, mais je ne suis pas un spécialiste...) c'est de donner un temps entre deux événements.
Si on donne des centièmes mais que ça peut varier d'un dixième en plus ou en moins, j'appelle plutôt ça un générateur de nombres aléatoires...

Le principe de ce type de développement, c'est de s'assurer que le cœur du programme, à savoir le chronométrage, fonctionne correctement. Tout le reste vient après. Ça tiens en quelques lignes de code, mais ça peut être difficile à mettre au point, et différentes solutions peuvent être testées.

En outre, il faut être certain du résultat des tests, et en particulier utiliser un protocole rigoureux, reproductible, objectif. On ne peut pas se contenter de "penser que", il faut être sur. Sinon, il faut s'attendre à des déboires avec le produit fini, et ce sera très difficile de corriger.

Une fois qu'on est sur de ça, on ne risque pas de remettre en cause l'architecture globale, et/ou le circuit imprimé...

Une erreur possible est durant la boucle en if - else if pour le stop, mais je crois que c'est de l'ordre du millième de seconde.
Où avez-vous pêché cette information ?
c'est déjà pour cela que j'ai déplacé le TX série de l'afficheur sur le i2c puisque ce bus sera bien présent (le 2me picaxe reprend l'afficheur extérieur et le PC alors qu'au départ que le PC), que j'ai modifier une partie de mon code du chrono afin de diminuer au max. les communications ... mais les affichages doivent bien avoir lieu !.
Il ne s'agit pas de diminuer les communications : il faut les supprimer !
Une seule communication depuis le Picaxe chronomètre peut entraîner un énorme retard de prise en compte du stop !
La seule voie suggérée est que le Picaxe Chronomètre ne fasse que ça !
Deux Picaxe sont démarrés en parallèle sur le même événement.
L'un est déclaré "Chronomètre" et ne fait rien d'autre qu'attendre l'interruption de fin.
L'autre, appelons le "le Communiquant", assure la communication temps réel. On sait que c'est n'importe quoi, y compris le temps final, mais on s'en moque car ce n'est que décoratif.
Après avoir détecté la fin, le Communiquant va lire en I2C sur le Chronomètre le temps final "officiel" et le transmet aux afficheurs et si besoin au PC.

A noter que le PC NE PEUT PAS assurer un chronométrage entre un événement de début et un événement de fin. Il peut juste recevoir le temps d'un chien, donc un peu après l'arrivée.
 
Last edited:

ddaweb

New Member
Bon, soyons clair, je suis maintenant pratiquement au même point que le chrono d'origine : https://picaxeforum.co.uk/threads/chrono-agility.25290/page-33#post-326706
Il ne reste que le LCD, tout comme celui-là ... le reste se fait via l'i2C avec le chrono en slave, le 2me picaxe va chercher les infos pour l'afficheur extérieur et le PC.
J'ai écouté ce qui a été dit, et pris des actions en conséquence, en suivant certaines recommandations : pas de TX durant le fonctionnement du chrono et i2c en slave.

Ce qui change :
- J'ai la possibilité de changer la manière dont le chrono travaille : 1 -> 2, 2 -> 1, 1 seule ou 2 seule
- La sélection de fonctionnement se fait TOUJOURS hors fonctionnement du chrono, dès qu'il est lancé tout changement sera inopérant jusqu'à l'arrêt du chrono (s'il y a eu des changements, il sera seulement alors pris en compte)
- Je bloque toutes les barrières durant 5 sec au démarrage : au cas où le STOP serait tombé avec le START et arrêterait le chrono (surtout pour 1 seule barrière, il arrive que le chien fasse tomber la barrière), à la sortie, je regarde l'état du STOP et si toujours actif, je passe en mode MANUEL (BP START/STOP permet de l'arrêter) ... je regarde alors l'état du STOP et si de nouveau 5 sec. consécutives au repos, repasse en mode AUTOMATIQUE (la remise en place d'une barrière provoque toujours beaucoup de mise en alarme et arrêterait le chrono).
Le temps de parcours ne sera jamais < 20 sec.
- Le START se fait via une interruption sur l'entrée de la sélection du mode de fonctionnement (ou BP START/STOP)
- Le STOP se fait avec une boucle avec un if - else if (au lieu d'un do - loop) qui regarde le mode de fonctionnement pour arrêter le chrono sur la bonne barrière ... à l'arrêt, le chrono se resette automatiquement après 5 sec., et met le temps sur la 2ème ligne du LCD
- La possibilité de rappeler les 8 derniers temps, uniquement chrono arrêté
- Il y a un boitier pour pour les juges (2 sorties actives ou non) qui leur donne l'état du chrono afin qu'ils ne siflent pas un nouveau départ si le chrono n'est pas 100 % prêt ... enfin c'est le monde parfait s'ils y font attention.

Donc pratiquement toutes les opérations se font chrono arrêté, dès qu'il est démarré, seul le STOP est encore surveillé.

Je suis navré que cela ne semble pas vous plaire.
 
Last edited:

BESQUEUT

Senior Member
Il ne reste que le LCD, ... le reste se fait via l'i2C avec le chrono en slave, le 2me picaxe va chercher les infos pour l'afficheur Je suis navré que cela ne semble pas vous plaire.
Boah, savez-vous, que ça me plaise ou pas, ça n'a strictement aucune importance !
Simplement, pour la beauté du geste, je préfère qu'un chrono au 1/100 soit juste au 1/100 et pas aléatoire jusqu'au 1/10...
Mais c'est vous qui voyez, comme dirait l'humoriste...
SI j'ai bien compris, le LCD est géré par un port série, donc si le STOP tombe au début d'un affichage, il faudra attendre que l'affichage soit terminé pour que le STOP soit pris en compte... Mais j'ai sans doute mal compris...

Accessoirement, même en mode slave, la lecture des données par un autre Picaxe prends nécessairement du temps ; suivant le manuel, il peut y avoir interférence, mais ce n'est pas certain. Il faudrait tester...

C'est pour ça que j'ai préconisé deux Picaxes indépendants, avec chacun son Timer :
- le Chronomètre ne fait strictement que ça, ce qui lui donne une chance d'obtenir un temps final correct,
- Le Communicant fait la même chose sur les mêmes événements, mais en plus il transmet ses données à qui veut bien l'écouter, sachant que c'est un peu n'importe quoi, mais on s'en moque vu que ça change tout le temps... Quand il détecte le STOP final, il peut aller lire le temps final sur le Chronomètre sans le déranger puisque ce dernier a terminé son travail. Il peut alors rectifier les afficheurs et communiquer le temps du chien au PC.

Pour le reste des bidouilles, il faudrait voir le code, mais je crains que de nombreux tests soient nécessaires pour prendre en compte tous ces cas de figure, rallongeant d'autant la prise en compte du STOP...
J'ai déjà dit que tout ça aurait pu être pris en compte par une connectique ad hoc et/ou de bêtes interrupteurs.

Pour le PC, je n'ai toujours pas compris pourquoi il faut envoyer un départ. A priori, seul le temps final est utile, et on peut l'envoyer quand on veut.

Autre suggestion : ouvrir un chronomètre à 2€ et mettre en parallèle le bouton start/stop avec l'entrée du Picaxe...
 
Last edited:

ddaweb

New Member
Oui la communication série semble poser des conflits, si j'en crois l'annexe 4 du manuel, cela concernerait essentiellement : serin, serout, serrxd, sertxd, debug
L'afficheur utilise hserout, on n'en parle pas ... aucune idée si c'est également impacté.

Cet afficheur, tout comme le chrono de base, ne met à jour que le temps, pas tout l'affichage heureusement : cela prend évidemment un tout petit temps de communication en 2400 baud.
Avec le i2c, il est tout à fait envisageable d'également mettre le LCD sur le 2me picaxe ... mais ce ne sera pas facile de refaire tous mes affichages : je vais devoir les lister afin de les identifier sur le 2me picaxe :confused:
J'avais également regardé de les mettre dans l'afficheur lui-même (de mémoire,15 affichages prédéfinis possibles), mais je n'ai pas réussit à les réafficher via mon code ... c'était tout au début, je vais pouvoir réessayer avec les connaissances acquises depuis.
Le picaxe du chrono initialise le bus i2c au démarrage, ensuite j'écris uniquement des valeurs dans le scratchpad que le 2me vient lire.


Il semblerait que le do - loop serait moins gourmand en ressources que le if - else if ... j'ai une petite idée que je dois tester et qui pourrait alors simplifier mon code.
En fouillant dans le manuel, j'ai déjà trouvé certaines choses qui vont également encore diminuer mon code, sans en modifier le fonctionnement.
En ce qui me concerne, le code final n'est certainement pas encore arrêté et je continue à essayer de faire mieux (vos conseils sont évidemment toujours très intéressants).


Pour le PC, comme je l'ai déjà dit, ce n'est pas moi qui ai décidé cela, le programme fonctionne de la sorte et est basé sur un chrono professionnel à plus de 3.000 € qui envoie l'heure réelle au 1/10000 au START et au STOP (la différence est le temps du chien; et c'est pour cela que je dois ajouter 2 zéros après les centièmes) : je ne suis qu'un utilisateur ... je suis en contact avec le créateur afin de voir pour un synergie, cela peu donc changer dans le futur.

Si vous avez une solution pour faire une interruption après celle du START, je suis preneur, je n'ai malheureusement pas trouvé ... j'avais déjà posé la question, sans réponse.

Une petite réponse sur les chronométreurs manuels, même au 1/10, on sera nettement mieux qu'eux : ce sont en général des membres (bénévoles) qui font cela et leur précision laisse vraiment à désirer, pas toujours consciencieux ...
Cela ne nous empêche pas d'être le plus précis possible avec l'électronique ;)
 

ddaweb

New Member
J'ai une petite question qu'en PHP je sais très facilement résoudre, mais pour le picaxe je ne trouve pas.
La gestion des variables est différente qu'en PHP évidemment.

Je compte attribuer au bit1 l'état réel de la barrières STOP (0 ou 1), le problème est que le STOP n'est pas toujours la même barrière :
- Si de 1->2 ou 2 seule : c'est la barrière 2 (variable barriere2)
- Si de 2->1 ou 1 seule : c'est la barrière 1 (variable barriere1)

Je fixe le mode de fonctionnement dans une variable au démarrage ou lors d'un changement de mode (afin d'éviter des TX sur le LCD à chaque boucle), durant cela, je peux faire des opérations qui fixerait le STOP (bit1) sur la bonne barrière et donc bien suivre son état réel : 0 ou 1.
J'arrive à obtenir un état instantané lors de la fixation du mode, mais pas le suivit de l'état réel du STOP sur la barrière correspondante en fonctionnement.

Le but est de simplifier mon code par la lecteur uniquement de ce bit1 au lieu des if - else if qui vérifie la barrière STOP suivant le mode de fonctionnement après le démarrage ... donc également augmenter la précision : c'est là dessus que je travaille pour l'instant, en fonction de vos diverses remarques !

Si quelqu'un a une idée, je suis preneur.
 

BESQUEUT

Senior Member
Le but est de simplifier mon code par la lecteur uniquement de ce bit1 au lieu des if - else if qui vérifie la barrière STOP suivant le mode de fonctionnement après le démarrage ... donc également augmenter la précision : c'est là dessus que je travaille pour l'instant, en fonction de vos diverses remarques !

Si quelqu'un a une idée, je suis preneur.
Déjà dit : deux bêtes interrupteurs et le problème est réglé...
Mais si vous voulez absolument faire ça en code, le mieux est de faire ça en une seule instruction via des opérations sur les bits.
Ne pas utiliser b0,b1 et w0 pour autre chose.
Utiliser bit0, bit1... pour décrire les différents états, puis faire une combinaison avec des OR, AND et XOR...
Pour plus de détails, il faudra réfléchir un peu plus...
Mais de toutes façons, même en optimisant le code, ça va rajouter un délai aléatoire sur la prise en compte du STOP, et c'est une mauvaise idée...

Merci pour les précisions sur le PC. Donc si je comprends bien, vous envoyez systématiquement 0.000 000 au départ, et le temps réel à l'arrivée. Donc, le moment où on envoie ces infos n'a aucune importance : seul le deuxième temps est effectivement pris en compte. Le Communicant peut donc tranquillement récupérer les infos depuis le chronomètre, puis les transmettre au PC. La précision n'est liée qu'au seul travail du Chronomètre.

L'idée du chrono à 2€ est de vérifier visuellement que tout fonctionne correctement. Déjà testé et c'est très efficace, même si ça fait un peu "bricolage".

Pour la séparation entre les deux Picaxes, il semble que vous n'ayez pas compris l'idée puisque vous parlez de l'utilisation d'I2C pour afficher le temps réel : le chronomètre ne doit rien faire d'autre que la prise en compte du STOP final, même pas répondre en esclave sur l'I2C.
Le Communicant dispose de son propre Timer pour avoir le chronométrage en temps réel, et n'a pas besoin d'interroger le Chronomètre pour avoir cette info (c'est évidement faux, mais peu importe comme déjà dit...)
C'est seulement quand il a lui-même détecté le STOP qu'il va chercher le chronométrage final sur le Chronomètre pour rectifier les afficheurs et transmettre l'info au PC.
Il semblerait que le do - loop serait moins gourmand en ressources que le if - else if ... j'ai une petite idée que je dois tester et qui pourrait alors simplifier mon code.
Il faudrait voir le code, mais ces deux commandes ne faisant pas la même chose, je ne vois pas comment l'une peut être plus rapide que l'autre ???
 
Last edited:

ddaweb

New Member
BESQUEUT said:
Pour la séparation entre les deux Picaxes, il semble que vous n'ayez pas compris l'idée puisque vous parlez de l'utilisation d'I2C pour afficher le temps réel : le chronomètre ne doit rien faire d'autre que la prise en compte du STOP final, même pas répondre en esclave sur l'I2C.
Le Communicant dispose de son propre Timer pour avoir le chronométrage en temps réel, et n'a pas besoin d'interroger le Chronomètre pour avoir cette info (c'est évidement faux, mais peu importe comme déjà dit...)
C'est seulement quand il a lui-même détecté le STOP qu'il va chercher le chronométrage final sur le Chronomètre pour rectifier les afficheurs et transmettre l'info au PC.
Si si, j'ai bien compris cela, depuis longtemps d'ailleurs, mais je devais réfléchir à une solution viable pour moi ;)

Je suis occupé de revoir toute la conception et la programmation du chrono dans cette direction vu que de toute façon j'aurai 2 picaxes : l'idée est de +/- garder mon chrono actuel avec les TX + LCD et que le 2me picaxe ne fasse que le calcul du temps réel au lieu des TX (reçoit les top START et STOP en entrées et placera le temps final pour lecture via l'i2c ... moins de communications n'est pas possible).
J'ai encore quelques interrogations, dont sur les tops :
- j'ai 4 modes de fonctionnement : 1->2, 2->1, 1 seule et 2 seule ... les barrières START et STOP changent
- j'ai un mode MANUEL et AUTOMATIQUE : pour rappel, si le chien fait tomber la barrière lorsqu'il n'y en a qu'une -> remise en ordre
- j'ai un BP START/STOP manuel
- quel picaxe utiliser pour le temps : j'ai un 14m2 en stock (devra alors être en maître ... cela ne devrait pas poser de problème vu que cela va se passer chrono arrêté)
- rendre le calcul du temps 100 % fiable

Je pense devoir mettre les barrières en parallèle sur les 2 picaxes, ainsi que le BP START/STOP : passe de +5v à 0V en cas de coupure des barrières via un transistor (barrières en 12v) et appuis sur le BP = mise à 0v, de transmettre le mode de fonctionnement d'une manière ou l'autre (se fait toujours chrono à l'arrêt, même via i2c n'aura pas d'incidence sur la précision) et le chrono prêt (là j'ai une sortie sur le chrono qui pourrait être une entrée sur le temps (+5v en défaut et 0V OK) : led défaut des juges ... aussi bien à l'arrêt : barrière en alarme ou appel mémoires, qu'en fonctionnement : mode manuel).
Il y a donc de quoi y penser sérieusement :p

BESQUEUT said:
L'idée du chrono à 2€ est de vérifier visuellement que tout fonctionne correctement. Déjà testé et c'est très efficace, même si ça fait un peu "bricolage".
Comme je l'ai déjà dit, j'ai un 2me chrono avec µc compilé qui est 100% compatible avec les entrées des barrières ... moins de travail de mettre les BP START et STOP déjà existant en parallèle.
Il ne devrait pas être moins fiable que ce petit bricolage ;)

BESQUEUT said:
Il faudrait voir le code, mais ces deux commandes ne faisant pas la même chose, je ne vois pas comment l'une peut être plus rapide que l'autre ???
C'est mon ami qui a des connaissances sur les µc (plus en compilé qu'interprété) qui me l'a dit ... mais en fait il a parlé du do while
 

BESQUEUT

Senior Member
Comme je l'ai déjà dit, j'ai un 2me chrono avec µc compilé qui est 100% compatible avec les entrées des barrières ... moins de travail de mettre les BP START et STOP déjà existant en parallèle.
Il ne devrait pas être moins fiable que ce petit bricolage ;)
Oui : c'est sans doute un bon élément de comparaison, à mettre en oeuvre avant toutes choses : si le temps final est OK, au moins dans un cas simple, on a une base fiable.
Sinon, il faut d'abord stabiliser ça avant de prendre en compte les différents cas de figure.
A mon humble avis, dès qu'on va faire des tests dans l'interruption, on va perdre des centièmes, voir plus... On pourra donc comparer différentes options de code.
Je n'ai toujours pas eu de réponse concernant l'utilisation d'interrupteurs (ou d'une connectique ad hoc) au moins pour mettre les barrières dans le bon ordre.
Idem pour le fait de n'utiliser qu'une seule barrière (et si le cas précédent est résolu, un seul ou 2 seul c'est la même chose...)
Le bouton START/STOP étant en parallèle il ne n'y a à priori pas d'incidence sur le code.
Reste l'histoire du mode manuel/automatique et de la remise en ordre. Faudrait que je relise les posts et le code.
Le Chronomètre est à priori un esclave, ce qui permet au Communiquant d'aller le lire quand ça lui chante.
Je rappelle pour la 18 000ième fois que la notion de maître/esclave ne concerne pas le sens des échanges (bi-directionnels de toutes façons...), mais qui à l'initiative de transmettre ou de recevoir des données...
Comme il ne fait pas grand chose, il y a une seule contrainte : utilisation d'un quartz 16Mhz pour un fonctionnement en 64 Mhz.
 

ddaweb

New Member
BESQUEUT said:
Je n'ai toujours pas eu de réponse concernant l'utilisation d'interrupteurs (ou d'une connectique ad hoc) au moins pour mettre les barrières dans le bon ordre.
Idem pour le fait de n'utiliser qu'une seule barrière (et si le cas précédent est résolu, un seul ou 2 seul c'est la même chose...)
Le bouton START/STOP étant en parallèle il ne n'y a à priori pas d'incidence sur le code.
Reste l'histoire du mode manuel/automatique et de la remise en ordre. Faudrait que je relise les posts et le code.
Le Chronomètre est à priori un esclave, ce qui permet au Communiquant d'aller le lire quand ça lui chante.
Je rappelle pour la 18 000ième fois que la notion de maître/esclave ne concerne pas le sens des échanges (bi-directionnels de toutes façons...), mais qui à l'initiative de transmettre ou de recevoir des données...
Comme il ne fait pas grand chose, il y a une seule contrainte : utilisation d'un quartz 16Mhz pour un fonctionnement en 64 Mhz.
Heuuu, je ne comprends pas votre histoire d'interrupteurs, par contre je peux vous dire comment je travaille (qui devrait être la réponse) :
- Un interrupteur détermine le sens 1->2 ou 2->1 sur une entrée
- Un 2me interrupteur détermine si c'est 1 ou 2 barrières sur une autre entrée : pour 1 seule, le sens détermine laquelle (ex. 1->2 = 1 seule)
C'est donc la lecture de ces 2 entrées qui va configurer le mode de fonctionnement et initialiser l'interruption du START ... toute modification du mode de fonctionnement provoque l'arrêt de l'interruption pour la réinitialiser correctement ensuite ... une fois démarré, ces entrées ne sont plus lues et reste, pour le STOP, dans le mode au moment du démarrage du chrono.

Pour le maître ou slave, je signalais juste le picaxe que j'ai en stock ... devant être maître (pas possible de le mettre en slave) ... il ne sera probablement pas utilisable car j'ai l'impression qu'il n'a pas de scratchpad (ou alors si c'est possible de le faire sur les autres mémoires 'storage' RAM ... Je n'ai pas encore analysé cela ... j'ai toujours utilisé le scratchpad) !
J'ai, maintenant, compris comment faire les communications entre les 2, dans les 2 sens.

Oui le quartz sera placé, c'est prévu, je le commande de retour en Belgique avec d'autres pièces qui me manquent et relance celle en attente.

Notez, que par acquis de conscience, je vais tout de même tester mon chrono avec le LCD uniquement (afficheur et PC via i2c) ... ce qui va me permettre de mieux évaluer les incidences en désactivant certaines choses (dont le LCD).
Par contre, si j'obtiens des valeurs hyper proches et constantes sur plusieurs durées (beaucoup de tests) ... je déciderai d'utiliser ou non le 2me picaxe en horloge ... mais on n'en est pas encore là, partons sur la base de l'horloge.
Je réécrit toute une partie du code ... j'espère ainsi mieux le coder ... en pensant µc et ses fonctions, plus php :rolleyes:
 

PieM

Senior Member
Je n'ai toujours pas eu de réponse concernant l'utilisation d'interrupteurs (ou d'une connectique ad hoc) au moins pour mettre les barrières dans le bon ordre.
Je pense même que cette discrimination n'a pas lieu d'être. Elle est d'ailleurs un peu illusoire, puisqu'il n'y a qu'une seule interruption possible.
Il s'agit de mesurer deux informations temporelles, la première faisant une RAZ du chrono, l'autre validant la lecture du temps.
Donc que les deux infos start et stop arrivant sur la même interruption viennent de 2>1, 1>2, 1>1 ou 2>2, ne dépendent absolument pas de la source.
Il suffit de monter un flag lors de la première interruption pour avoir la chronologie des évènements.
 

MGU

Senior Member
Bonjour,
J'ai vu #64, ...Belle réalisation.
Comment sont constituées les barrières, il me semble qu'il était question de deux faisceaux IR ?

MM
 

ddaweb

New Member
Bonjour,
J'ai vu #64, ...Belle réalisation.
Comment sont constituées les barrières, il me semble qu'il était question de deux faisceaux IR ?

MM
Merci ;)
Voici des photos des cellules qui sont réglables en hauteur sur la haie, en fonction de la classe et grandeur des chiens, avec des trous baillonnettes. Le bloc cellules peut être ajusté un peu pour l'alignement horizontal
Pour le catadioptre, j'ai une bande sur toute la hauteur de la haie (également ajustable pour la verticale) et ne doit plus être bougé, juste aligné avec les cellules au montage.
Hé oui, les terrains ne sont pas très plats ... ces réglages d'alignement sont parfois nécessaires :cautious:

haies.JPGcellules.JPG
 
Last edited:

ddaweb

New Member
J'ai un peu réfléchit sur le principe que je pourrais utiliser avec le 2me picaxe en horloge :

1. Mettre des entrées et sortie en parallèle sur les 2 picaxe : barrières - BP START/STOP - led défaut
2. Horloge avec une interruption sur les entrées (comme le chrono) soit barrière 1 et START/STOP, soit barrière 2 et START/STOP
3. Chrono à l'arrêt : horloge
- Si le défaut allumé : il va lire le mode de fonctionnement du chrono via i2c, interruption arrêtée (comme sur le chrono)
- Si le défaut éteint : plus de lecture i2c, interruption active et attente un puls sur une des entrées de l'interruption pour démarrer le temps
4. Chrono démarré : horloge
- Si le défaut allumé : uniquement START/STOP arrête le temps ... faire une boucle de 3 sec. où START/STOP inactif, sinon incohérence avec le chrono
- Si le défaut éteint (après 3 sec. blocage et STOP au repos à la sortie de ce temps) : barrière STOP ou START/STOP arrêtent le temps
- Au STOP : temps final disponible via i2c et temps horloge à 0

J'aurais donc une image du fonctionnement du chrono sur l'horloge, mais sans tous les TX présents sur le chrono.
Au LCD et afficheur extérieur je n'afficherai plus les centièmes (voir les dixièmes si nécessaire) ... au STOP màj du temps complet de l'horloge via lecture i2c
 

BESQUEUT

Senior Member
1. Mettre des entrées et sortie en parallèle sur les 2 picaxe : barrières - BP START/STOP - led défaut
Euh... Ça suppose que le Chronomètre gère ce défaut... A voir si le code correspondant ne gêne pas le chronométrage...
2. Horloge avec une interruption sur les entrées (comme le chrono) soit barrière 1 et START/STOP, soit barrière 2 et START/STOP
3. Chrono à l'arrêt : horloge
- Si le défaut allumé : il va lire le mode de fonctionnement du chrono via i2c, interruption arrêtée (comme sur le chrono)
- Si le défaut éteint : plus de lecture i2c, interruption active et attente un puls sur une des entrées de l'interruption pour démarrer le temps
4. Chrono démarré : horloge
- Si le défaut allumé : uniquement START/STOP arrête le temps ... faire une boucle de 3 sec. où START/STOP inactif, sinon incohérence avec le chrono
- Si le défaut éteint (après 3 sec. blocage et STOP au repos à la sortie de ce temps) : barrière STOP ou START/STOP arrêtent le temps
- Au STOP : temps final disponible via i2c et temps horloge à 0

J'aurais donc une image du fonctionnement du chrono sur l'horloge, mais sans tous les TX présents sur le chrono.
Au LCD et afficheur extérieur je n'afficherai plus les centièmes (voir les dixièmes si nécessaire) ... au STOP màj du temps complet de l'horloge via lecture i2c
Ça à l'air à peu près cohérent,même si j ne comprends pas la logique des "défauts".
Il faudrait maintenant voir le code de chaque Picaxe (en fait, surtout celui du Chronomètre), ainsi que les résultats de la comparaison avec le chronomètre étalon.
 

ddaweb

New Member
Euh... Ça suppose que le Chronomètre gère ce défaut... A voir si le code correspondant ne gêne pas le chronométrage...
En théorie cela devrait fonctionner :
- Les entrées et BP ont un R de 10K au + 5V et si actives met à 0v
- La sortie est à 0v au repos et + 5v active ... une R sera nécessaire pour l'entrée du picaxe horloge, avec une diode probablement

Ça à l'air à peu près cohérent,même si j ne comprends pas la logique des "défauts".
Il faudrait maintenant voir le code de chaque Picaxe (en fait, surtout celui du Chronomètre), ainsi que les résultats de la comparaison avec le chronomètre étalon.
Je veux bien mettre le code si vous le souhaitez, mais cela fait quelques (sss) lignes de codes ... je suis encore occupé de le modifier légèrement (simplifier) en fonction de ce que j'ai déjà fait durant mes vacances, sans en modifier le principe.

Le principe de la led défaut (sortie) est très simple (et complexe) ... elle s'allume :
- Si une des entrées est en alarme au démarrage où après remise à zéro : arrête l'interruption du START
- Si on change le mode de fonctionnement du chrono : arrête également l'interruption
- Si on fait un appel des mémoires : arrête également l'interruption
- Durant le blocage des barrières de 3 sec. après le START et si le STOP toujours en alarme après ce délai
En résumé, elle est éteinte que si le chrono est 100% prêt ... à l'arrêt ou après les 3 sec. de blocage.

Le picaxe horloge, je ne l'ai pas encore commencé, j'analyse le principe de fonctionnement pour l'instant.
Je vais commencé le code lorsque j'aurai fini le chrono lui-même et fait les tests avec les 2 chronos ... je viens de le ramener du club.
Pour le moment, le code avec le 2me picaxe en TX est toujours présent.
 

ddaweb

New Member
Voilà les premier test de comparaison du chrono : avec LCD et i2c.
Donc les mêmes BP actionnent les 2 chronos en même temps (en parallèle) et les 2 sur batterie.

On ne peut pas dire que ce soit excellent ... mais vraiment pas aussi catastrophique que cela en fin de compte.
La majorité des tests sont avec le settimer à 64915 que j'ai considéré comme plus proches les unes des autres ... à voir avec un quartz maintenant.
Dans la tranche 30 à 60 sec., c'est relativement stable.
La première colonne pour trouver la meilleure valeur pour commencer.
Je vais faire d'autres tests, dont avec 64916 (qui dévie fort avec des temps plus long) ... à voir donc

Rien ne garanti que l'autre chrono soit 100%, mais certainement plus stable.
 

Attachments

Top