Chrono Agility : nouveau

BESQUEUT

Senior Member
J'ai peut-être des bêtes questions :
qu'est-ce qui empêche de mettre timer=0 dans la boucle attente start -> le if temps>32768 n'est plus utile alors vu qu'il correspond au dépassement de la valeur word ?
Les 2 setint après chaque boucle ne sont-ils pas inversés ?

J'ai évidemment testé + en mettant Barriere2=%0000010 afin de voir si j'avais bien compris : le start sur B.0 et stop sur B.1
Vu que les 2 barrières étaient sur B.0 cela fonctionnais évidemment avec votre code.

Le résultat :
Code:
T1=14    T2=533 chrono=519
T1=14    T2=505 chrono=491
T1=14    T2=1249 chrono=1235
T1=14    T2=451 chrono=437
T1=14    T2=336 chrono=322
T1=14    T2=710 chrono=696
T1=14    T2=409 chrono=395
Edit : j'ai fait le test dans le simulateur du programme, demain, si j'ai le temps, je le fait avec un 28x2 (sans quartz malheureusement) + le générateur d'impulsion avec un 18m2
Vous ne pouvez pas savoir à quel endroit du do loop l'interruption va se produire. Si c'est juste avant timer=0, ca va effacer le travail de L'interruption et comme il n'y a pas de setint, le START ne sera pas pris en compte...

Oui : autant pour moi : les setint sont inverses (sauf si on va de b2 vers b1...)
Oui : les variables barrières devraient permettre de prendre en compte les différents cas de figure.
Si vous faites des tests, mettez aussi en // le chrono de référence...
 
Last edited:

ddaweb

New Member
Vous ne pouvez pas savoir à quel endroit du do loop L'interruption va se produire. Si c'est juste avant timer=0 le chronométrage sera faussé...
Oui : les variables barrières devraient permettre de prendre en compte les différents cas de figure.
Si vous faites des tests, mettez aussi en // le chrono de référence...
Sur un do-loop de 1 ligne : l'attente du start :oops: ... je suis surpris, mais là je suis nul, donc je vous crois ;)

Code:
do
    do                    ' attente du START
        timer=0
        loop until temps>0

    T1=temps
Oui je pourrais mettre soit mon picaxe ou l'autre chrono suivant votre préférence en // ... mais vais devoir bricoler l'entrée avec un transistor car elle fonctionne dans l'autre sens (de haut vers bas) et vous de bas vers haut ... sauf si votre trigger peut être inversé ;)

Edit : suis-je bête ... c'est le générateur d'impulsion qui va travailler, je vais faire 2 sorties inversées + un temps d'attente de 10 sec avant le nouveau start, le temps du reset automatique (me permettra également d'inscrire le temps) : c'est le cas pour les 2 chronos que j'ai.
 
Last edited:

BESQUEUT

Senior Member
Sur un do-loop de 1 ligne : l'attente du start :oops: ... je suis surpris, mais là je suis nul, donc je vous crois ;)

Code:
do
    do                    ' attente du START
        timer=0
        loop until temps>0

    T1=temps
Oui je pourrais mettre soit mon picaxe ou l'autre chrono suivant votre préférence en // ... mais vais devoir bricoler l'entrée avec un transistor car elle fonctionne dans l'autre sens (de haut vers bas) et vous de bas vers haut ... sauf si votre trigger peut être inversé ;)

Edit : suis-je bête ... c'est le générateur d'impulsion qui va travailler, je vais faire 2 sorties inversées + un temps d'attente de 10 sec avant le nouveau start, le temps du reset automatique (me permettra également d'inscrire le temps) : c'est le cas pour les 2 chronos que j'ai.
Imaginez la séquence
Do
Timer=0
Temps=timer ' interruption
RETURN ' interruption
Loop until temps>0

Selon vous L'interruption va-t-elle être prise en compte ?

Ben oui vous pouvez paramétrer les setint dans le sens qui vous arrange mais vous aurez besoin d'autres variables pour les masques...
Vous devriez également pouvoir fixer input à %00000011 ou %00000000 selon ce qui vous arrange
et utiliser Barriere1 et Barriere2 pour le MASK uniquement... (ce qui économise 2 variables...)

Si vous utilisez des sorties différentes les impulsions seront décalées et on ne sait pas de combien...
 
Last edited:

BESQUEUT

Senior Member
Le résultat est déjà plus que correct !
Oui, c'est suffisant pour le besoin envisagé, d'autant que pour travailler en dessous du 1/100 s il faut soit raccourcir la durée chronométrable, soit compliquer un peu le code pour mieux gérer les débordements...
Le test actuel limite le temps chronométrable à 327.67 s soit un peu plus de 5 minutes.
En outre, il me semble qu'il faudrait ajouter 65536 et non 65535 (et d'ailleurs, j'ai observé que le chrono est systématiquement un poil plus court en cas de débordement) :
Code:
if temps>32768 then
        temps=temps+65535+1
    endif
Ce sera également intéressant de comparer les temps donnés par les deux Picaxes en //...
Mais tant qu'on y est, c'est intéressant de savoir jusqu'où on peut aller en poussant le concept à fond...
 
Last edited:

PieM

Senior Member
au lieu de :
temps=t2-t1
if temps>32768 then
temps=temps+65535
endif

Il suffit de faire systématiquement :
temps = t2-t1 +65535 + 1
et toute l'amplitude est disponible
 

BESQUEUT

Senior Member
au lieu de :
temps=t2-t1
if temps>32768 then
temps=temps+65535
endif

Il suffit de faire systématiquement :
temps = t2-t1 +65535 + 1
et toute l'amplitude est disponible
Vinzou : c'est du lourd ça. Je vais me coucher moins con ce soir...
 

BESQUEUT

Senior Member
Je parlais de l'interruption, la précision est un autre problème ;).
Ouaip : ça devient culturel : on a de plus en plus de trucs qui font tout et n'importe quoi, sauf la fonction de base. Genre, mon smartphone fait des photos, gère mon emploi du temps et tuti quanti... mais pour ce qui est de téléphoner, c'est compliqué et le son est limite inaudible...
Dans la même veine, j'ai aussi un kutch en caoutchouc, garanti incassable et un marteau du même métal pour les maladroits qui se tapent sur les doigts... :p
Par contre, j'ai fais un test avec un faisceau de cellules utilisée en système d'alarme pour protéger les fenêtres de 4 ou 6 faisceaux (émetteur et récepteur séparés) ... la vitesse de réaction était en dessous de tout : j'ai donc abandonné ce système, également à cause du câblage entre les 2 côtés de la haie.
Ces machins sont temporisés pour éviter les fausses alarmes. Si on met 0,5s voire 2s pour détecter le malfaisant, ce n'est pas gravissime.
Par contre, pour chronométrer des toutous, évidement ça pose problème...
Le résultat :
Code:
T1=14    T2=533 chrono=519
T1=14    T2=505 chrono=491
T1=14    T2=1249 chrono=1235
T1=14    T2=451 chrono=437
T1=14    T2=336 chrono=322
T1=14    T2=710 chrono=696
T1=14    T2=409 chrono=395
Edit : j'ai fait le test dans le simulateur du programme, demain, si j'ai le temps, je le fait avec un 28x2 (sans quartz malheureusement) + le générateur d'impulsion avec un 18m2
Le T1=14 systématique est ultra suspect : impossible que le premier front montant se produise toujours au même moment...

C'est important de vérifier que l'interruption est bien déclenchée sur le premier front de la barrière :
- montant si l'état d'attente est bas,
- descendant si l'état d'attente est haut

Si on prends le deuxième front, le chronométrage dépends de la durée de l'impulsion, qui est inconnue et variable, en particulier dans le cas de deux barrières...
 
Last edited:

BESQUEUT

Senior Member
Je sens que je vais écrire une bêtise, mais tant pis.
Je trouve que pour l'instant, c'est un peu "usine à gaz".

En supposant, que l'on détermine la durée précise d'une instruction de base, afin de pouvoir appliquer le correctif qui va bien, on ne pourrait pas plutôt faire un truc de ce genre :



Do
Loop Until Start_Chro=1
Do
w0=w0+1
Loop until Stop_Chro=1
Tps_Chronometre= w0*n+k 'en deux ligne, hein...


Si vraiment le temps de comptage peut-être trop long, pour une variable word (65025), on peut chainer sur une deuxième, etc, etc.
On pourrait aussi choisir une instruction assez "lente" (pas trop, quand même, pour la précision).

J'y vois comme avantage, que l'erreur maximale, sur le temps de comptage sera le temps d’exécution de l'instruction choisie.

Pas d'usage de timer, pas d'interférence, durant le comptage.

Sais pas, hein ...
A part que
inc w0
me semble plus performant que w0=w0+1
c'est loin d'être idiot.
Puisque de toutes façons, l'interruption n'est prise en compte qu'entre deux commandes, il n'y a pas de raison que votre code soit moins bon, d'autant plus que inc w0 devrait être plus rapide que w0=Timer
A tester...
Autre réflexion métaphysique (spécial PieM qui est très en forme) pour gérer les débordements et donc les chronométrages ultra-précis sur des durées longues : puisque les X2 ont plusieurs timers, ne pourrait on pas paramétrer deux timers, par exemple un au 1/1000 et l'autre 256 fois plus lent ?
Du coup, ce deuxième timer devrait permettre de savoir combien de fois le premier a fait le tour...
 
Last edited:

PieM

Senior Member
Je suis passé à coté du message de jojojo... sorry.
C'est une solution en effet de faire un timer en soft, mais j'ai quelque doute sur la fidélité du comptage dans un mode interprété. Est-on sûr que l'incrémentation d'un word prends toujours le même temps qqsoit sa valeur. Il faut également gérer d'autre éléments (sélection des entrées, neutralisation de la durée de sécurité)
Je pense que l'utilisation directe d'un timer hard est plus sûre, et ne pose visiblement pas de problème, puisque l'interruption intervient dans une boucle très rapide.
Concernant la réflexion métaphysique (;-) l'utilisation du timer3 n'est pas très souple! Mais je pense qu'une solution serait possible en utilisant un compteur tout bête incrémenté par le flag toflag, à condition d'avoir le timer1 initialisé en boucle pour 65535 - 1000 (ms)
 

ddaweb

New Member
Bonsoir la cie,
J'ai regardé avec attention vos différents posts de la journée et les suggestions ...
Pourrais-je demander de ne plus parler systématiquement en négatif sur ma réalisation ... tout a déjà été dit, j'ai compris et entendu.
Je préfère donc me tourner vers le futur que de ressasser le passé :confused:

Ce sera également intéressant de comparer les temps donnés par les deux Picaxes en //...
Mais tant qu'on y est, c'est intéressant de savoir jusqu'où on peut aller en poussant le concept à fond...
J'ai donc fait une synthèse de vos commentaires pour faire un test avec les codes suivants :
1. Le picaxe 28x2, j'ai laissé le code original en commentaire :
Code:
#no_data
#no_table
' port com : 19200 bauds= 4x 4800
' Interruption soft

#picaxe 28X2            'Type de Picaxe

symbol T1=w25
symbol T2=w26
symbol Temps=w27

;symbol Barriere1=b1
;symbol Barriere2=b2

setfreq m16
settimer 64913    ' 0,001 s
'settimer 65473    ' 0,010 s

;Barriere1=%0000001
;Barriere2=%0000001

;setint Barriere1,Barriere1,B
setint %00000000,%00000001,B
temps=0

do
    do                    ' attente du START
    loop until temps>0

    T1=temps
    sertxd("T1=",#T1,13,10)
    pause 2000                ' 1s à 16 Mhz
    temps=0
    ;setint Barriere1,Barriere1,B
    setint %00000000,%00000001,B

    do                    ' attente du STOP
    loop until temps>0

    T2=temps
    temps=t2-t1+65535+1
    sertxd("T2=",#T2," chrono=",#temps,13,10)
    pause 2000                ' 1s à 16 Mhz
    temps=0
    ;setint Barriere2,Barriere2,B
    setint %00000000,%00000001,B
loop


interrupt:
    Temps=Timer 
return
2. Le générateur d'impulsions ... j'ai du rallonger le temps d'attente et synchroniser les 3 picaxes :
Code:
#no_data
#picaxe 14M2

do
    low b.3    ' START
    pause 500
    high b.3
    pause 9500
  
    low b.3    ' STOP
    pause 500
    high b.3
    pause 12000
loop
3. Résultats des tests :
En fait je ne sais pas trop quoi en penser des premiers résultats obtenus en mettant ma réalisation en // avec votre code pour le temps.
Je l'ai fait une 2me fois, après une coupure de tension et resynchronisation des picaxes pour avoir plus de valeurs.
J'ai du mal à croire ces valeurs et je vais en refaire avec d'autres durées.

Une photo de mon banc de test et les résultats obtenus, j'ai ajouté une led sur la sortie des impulsions pour la visualiser
 

Attachments

BESQUEUT

Senior Member
Bonsoir la cie,
J'ai regardé avec attention vos différents posts de la journée et les suggestions ...
Pourrais-je demander de ne plus parler systématiquement en négatif sur ma réalisation ... tout a déjà été dit, j'ai compris et entendu.
Je préfère donc me tourner vers le futur que de ressasser le passé :confused:



J'ai donc fait une synthèse de vos commentaires pour faire un test avec les codes suivants :
1. Le picaxe 28x2, j'ai laissé le code original en commentaire :
Code:
#no_data
#no_table
' port com : 19200 bauds= 4x 4800
' Interruption soft

#picaxe 28X2            'Type de Picaxe

symbol T1=w25
symbol T2=w26
symbol Temps=w27

;symbol Barriere1=b1
;symbol Barriere2=b2

setfreq m16
settimer 64913    ' 0,001 s
'settimer 65473    ' 0,010 s

;Barriere1=%0000001
;Barriere2=%0000001

;setint Barriere1,Barriere1,B
setint %00000000,%00000001,B
temps=0

do
    do                    ' attente du START
    loop until temps>0

    T1=temps
    sertxd("T1=",#T1,13,10)
    pause 2000                ' 1s à 16 Mhz
    temps=0
    ;setint Barriere1,Barriere1,B
    setint %00000000,%00000001,B

    do                    ' attente du STOP
    loop until temps>0

    T2=temps
    temps=t2-t1+65535+1
    sertxd("T2=",#T2," chrono=",#temps,13,10)
    pause 2000                ' 1s à 16 Mhz
    temps=0
    ;setint Barriere2,Barriere2,B
    setint %00000000,%00000001,B
loop


interrupt:
    Temps=Timer
return
2. Le générateur d'impulsions ... j'ai du rallonger le temps d'attente et synchroniser les 3 picaxes :
Code:
#no_data
#picaxe 14M2

do
    low b.3    ' START
    pause 500
    high b.3
    pause 9500
 
    low b.3    ' STOP
    pause 500
    high b.3
    pause 12000
loop
3. Résultats des tests :
En fait je ne sais pas trop quoi en penser des premiers résultats obtenus en mettant ma réalisation en // avec votre code pour le temps.
Je l'ai fait une 2me fois, après une coupure de tension et resynchronisation des picaxes pour avoir plus de valeurs.
J'ai du mal à croire ces valeurs et je vais en refaire avec d'autres durées.

Une photo de mon banc de test et les résultats obtenus, j'ai ajouté une led sur la sortie des impulsions pour la visualiser
C'est effectivement très troublant...
Pour vos prochains tests, je propose d'augmenter très régulièrement (par exemple d'une seconde à chaque test) la durée à chronométrer de façon à tenter de détecter un éventuel biais.
 

ddaweb

New Member
Hier soir j'ai encore fais des tests à 20 - 30 - 40 sec. ... résultats forts similaires, mais trop tard pour encore les poster.
En fait, les pauses adaptées et non les secondes ... ;)
Je penses que les programmes utilisés, que j'ai postés, sont corrects pour des tests fiables ?

Vous avez dit troublant ... c'est même contre toute attente, je craignais vraiment une grosse catastrophe.

Si vous avez un Picaxe 28x2, avec quelques résistances (LCD ou Putty pour l'affichage) et le pgm que j'ai mit en fichier TXT, vous pourriez confirmer ou non mes résultats.
J'avoue que si cela se confirme, je n'ai plus une grande motivation de creuser la solution avec le temps sur un 2me picaxe.
Je vais tout de même essayer avec un chrono manuel du club pour voir si la durée est correcte ou non, et voir la dérive pour l'ajustement ... mais après avoir placé le quartz (j’attendais en fait la solution qui est en court pour commander les pièces nécessaire en plus)

Concernant l'autre chrono ... beeeeennn il me semble alors caduque :oops: ... je vais tenter les 3 en //

Vraiment, si quelqu'un a le courage de vite faire un 28x2 avec mon programme et tester, cela serait sympa :p
 

BESQUEUT

Senior Member
Hier soir j'ai encore fais des tests à 20 - 30 - 40 sec. ... résultats forts similaires, mais trop tard pour encore les poster.
En fait, les pauses adaptées et non les secondes ... ;)
Je penses que les programmes utilisés, que j'ai postés, sont corrects pour des tests fiables ?

Vous avez dit troublant ... c'est même contre toute attente, je craignais vraiment une grosse catastrophe.

Si vous avez un Picaxe 28x2, avec quelques résistances (LCD ou Putty pour l'affichage) et le pgm que j'ai mit en fichier TXT, vous pourriez confirmer ou non mes résultats.
J'avoue que si cela se confirme, je n'ai plus une grande motivation de creuser la solution avec le temps sur un 2me picaxe.
Je vais tout de même essayer avec un chrono manuel du club pour voir si la durée est correcte ou non, et voir la dérive pour l'ajustement ... mais après avoir placé le quartz (j’attendais en fait la solution qui est en court pour commander les pièces nécessaire en plus)

Concernant l'autre chrono ... beeeeennn il me semble alors caduque :oops: ... je vais tenter les 3 en //

Vraiment, si quelqu'un a le courage de vite faire un 28x2 avec mon programme et tester, cela serait sympa :p
Je peux tenter sur un 40X2, mais pas avant la semaine prochaine.
Effectivement,vu vos derniers résultats ça semble possible, mais comment expliquer une telle différence par rapport à vos précédents tests ?
Régularité du générateur ? Qualité des switchs lors du premier test ?

A y être, pensez à modifier le code pour que les essais soient facilement récupérables dans Excel...

Dans tous les cas, même si vous restez sur un seul Picaxe, je vous conseille de repartir du programme préconisé par PieM, quitte à rajouter des choses dans les boucles d'attente : ça a aux moins le mérite d'être plus facile à déboguer...
L'idéal étant de vérifier régulièrement que les ajouts ne dégradent pas la qualité du chronométrage.
(Toujours la même idée : on part de quelque chose de simple et qui marche pour aller vers plus complexe en vérifiant que ça marche toujours...)
 

ddaweb

New Member
Je viens de faire des tests avec les 3 en // et subitement mon chrono a chuté de 0.05 sec et est resté stable sur cette dernière valeur ... il me semble que mon PowerBank a chuté au même moment (?) ... peut-être un début de réponse vu que je les avais fait sur le PowerBank.
Mes premiers tests étaient avec un BP et régulier (l'un derrière l'autre, le temps de noter les valeurs), mais pas autant qu'avec le générateur d'impulsions.

Les 3 chronos donnent des temps différents, mais tous assez stables dans leurs valeurs ... le vieux chrono donne par contre +/- 30 secondes pour une pause de 30000, mais avec des valeurs plus flottante avec 0.01 sec. de différence (majoritairement 29.99)

Je viens de tester sur l'USB du PC ... il est remonté à ses valeurs avant la chute, avec la même stabilité :rolleyes:

Par contre, l'interruption que j'utilise est-elle différente de celle du programme de test ? ... j'ai des paramètres en plus et DOIT obligatoirement utiliser B.0 à B.2 (interruption hardware)

Edit : je viens d'ajouter ce que Putty affichais pour le chrono de test ... il y a plus de valeurs que dans le pdf, j'avais laissé tourner + test avec USB
 

Attachments

Last edited:

ddaweb

New Member
J'ai peut-être trouvé une autre cause posible au problème avec les 2 chronos en // : j'ai un retour de +/- 7v de l'entrée de l'ancien chrono, avec la R de 10K placée sur le picaxe, elle est donc à 5,35v ... donc au dessus de l'alimentation du picaxe : vraiment pas idéal.
Mettre une diode ou un transistor empêche l'entrée de l'ancien chrono de s'activer étant elle-même pourvue d'un transistor pour isoler le 12v de la barrière du 5v du chrono lui-même.

La seule solution que je vois est un relais double contacts que je n'ai pas : 1 pour les picaxes, l'autre pour l'ancien ... grrrr
Un relais simple contact risque de provoquer un petit retard et donc des données légèrement erronées.
 

jojojo

Senior Member
Un relais simple contact risque de provoquer un petit retard

Ouh là ! Non.
Je temps moyen de réaction d'un relais normal, de bonne qualité est de ... 20mS.
A proscrire absolument.
 

ddaweb

New Member
A y être, pensez à modifier le code pour que les essais soient facilement récupérables dans Excel...

Dans tous les cas, même si vous restez sur un seul Picaxe, je vous conseille de repartir du programme préconisé par PieM, quitte à rajouter des choses dans les boucles d'attente : ça a aux moins le mérite d'être plus facile à déboguer...
L'idéal étant de vérifier régulièrement que les ajouts ne dégradent pas la qualité du chronométrage.
(Toujours la même idée : on part de quelque chose de simple et qui marche pour aller vers plus complexe en vérifiant que ça marche toujours...)
C'est dans Excel que je le fais, mais il me semble que ce n'est pas téléchargeable ici ... je vais essayer bientôt.

J'ai suivit vos conseils et j'ai réécris une bonne partie du code du chrono avec le modèle du chrono de test (les sous-routines ne bouge pratiquement pas heureusement) :
- J'ai déjà la sélection du mode de fonctionnement : via un case comme suggéré par @PieM -> interruptions sur la barrière ad-hoc ou BP START/STOP
- Le blocage de +/- 2sec. au démarrage (led_defaut s'allume durant ce temps) ... en vue du contrôle si une barrière est en alarme
- Les principaux affichage dont la plupart sont hors fonctionnement et ne coûtent pas de temps
- Une seule ligne après interrupt:, la même que celle de l'horloge : tout se fait dans la boucle de départ
- L'affichage du temps toutes les secondes, affichage du temps complet à l'arrêt : les dixièmes et centième coûtent vraiment trop cher en temps comme vous l'aviez répété à maintes reprises
- Dans le chrono de test, j'ai intégré le blocage de l'interruption si la led_defaut est allumée, dans l’éventualité d'un 2me picaxe pour le temps réel : je vais probablement passer par l'i2c pour le mode de fonctionnement et un case pour le fixer -> la led_defaut bloque les interruptions du chrono horloge, c'est le moment de transmettre le mode de fonctionnement (qui s'allume au changement de mode durant +/- 1 sec. et durant l'appel mémoire).
Je crois que cela vaudrait la peine de travailler en millième pour le transmettre en centièmes.
- J'ai su identifier un settimer pour l'horloge (64917) et le chrono (64918) avec un K permettant d'obtenir des résultats très proche (max.0.01 sec. de différence entre les 2 ... la différence d'horloge en est plus que probablement la cause) ... tout sera à refaire avec le quartz évidemment.
Je vais pouvoir à chaque nouvelle fonctionnalité vérifier son coût en temps.
J'ai étalonné l'horloge sur plusieurs temps, mais malheureusement en me servant de l'horloge de Windows comme repère ... donc toujours quelques centièmes d'erreur.

Quand je fais beaucoup de tests d'affilée, une différence de temps plus importante apparaît ... comme si les µC chauffaient un peu, mais pas de la même manière ... une petite pause et cela se stabilise.

Une petite pause et je fais des tests plus complet que je posterai.
 
Last edited:

ddaweb

New Member
Je viens de découvrir avec horreur que le setint ne fonctionne pas s'il y a un choix : case ou if --> cela doit être une ligne propre de code unique.
Comme cela ne fonctionnait pas, je suis reparti de mon code de test en faisant d'abord une case (NOK) et ensuite un if (NOK) pour revenir à une ligne propre (OK)
Cela voudrait dire que je dois faire 4 fois le programme, donc 1 pour chaque mode avec les bons setint
Un choix case ou if fait un goto mode_xx: ... au changement de mode -> retour début ... éventuellement utiliser la fonction restart

Si quelqu'un a une autre idée ?
 

jojojo

Senior Member
Comment ça ?

Bien sûr que SETINT fonctionne sans choix.

Un exemple:

#picaxe 08M2
Setfreq M32
Let dirs=%000101
Symbol ppz=pinC.3
Symbol led=pinC.2

High led 'juste pour voir
pause 8000 '1 seconde
Low led
pause 8000 '1 seconde
Setint %000000,%01000


do
loop
Interrupt:
High led
Setint %000000,%01000

Return

Aucun test conditionnel là-dedans.
 

PieM

Senior Member
Je viens de découvrir avec horreur que le setint ne fonctionne pas s'il y a un choix : case ou if --> cela doit être une ligne propre de code unique.
Merci de prendre l'habitude de mettre votre code en question !
Rich (BB code):
select case b1
      case 11, 12 : setint %00000000, %00000001
      case 22, 21 : setint %00000000, %00000010
end select
interrupt:

return
marche très bien !
 

ddaweb

New Member
Merci de prendre l'habitude de mettre votre code en question !
Rich (BB code):
select case b1
      case 11, 12 : setint %00000000, %00000001
      case 22, 21 : setint %00000000, %00000010
end select
interrupt:

return
marche très bien !
Haaaaa ... je vais réessayer ce soir car hier soir, en test réel, il ne déclenchait pas en actionnant l'entrée de l'interruption.
La seule différence chez moi :
Code:
select case b1
      case 11, 12 : setint or %00000000, %00000101, B
      case 22, 21 : setint or %00000000, %00000110, B
end select
Aucun setint à l'initialisation du picaxe, le case est la première !
Et un 2me case pour l'arrêt, avec forcément les valeurs des cases qui changent.
Je ne suis pas à la maison pour mettre tout le code.

Oui, c'est vrai que le code vous aurait aidé, mais j'ai pensé que la fonction à problème suffisait
 

BESQUEUT

Senior Member
Aucun setint à l'initialisation du picaxe, le case est la première !
...
Oui, c'est vrai que le code vous aurait aidé, mais j'ai pensé que la fonction à problème suffisait
OUI : ça aide...
b1 est-il bien initialisé à une des valeurs possibles ?

D'un point de vue général, une fois qu'on a supprimé tous les GOTO, il est utile de se poser la question et même souvent de compléter
les IF THEN par un ELSE
les SELECT CASE par un CASE ELSE
Quitte a allumer une lampe d'erreur ou à afficher un message d'erreur...
Normalement le programme ne doit pas passer dans cette ligne,....
mais 'il y a passe on va gagner beaucoup de temps pour comprendre pourquoi le programme ne fait pas ce que l'on souhaite.
C'est un début de programmation dite "résiliente"...
 

ddaweb

New Member
Oui j'avais également mit le else pour le défaut avec le case, si la variable n'est pas correcte.
Dans mon cas ce n'est pas b1, mais mode_chrono(=b1) et bien initialisé car j'ai forcé une valeur pour le symbol afin de pouvoir tester le case (la lecture par i2c n'est pas encore active). Je vais tester avec le symbol et la variables système.

Je suis au boulot, pas le code sous la main ;) ... je vous tient au courant dès que j'ai retesté ce soir (et le code utilisé).
 

PieM

Senior Member
case 11, 12 : setint or %00000000, %00000101, B
Oui, c'est vrai que le code vous aurait aidé, mais j'ai pensé que la fonction à problème suffisait
Le diable se cache dans les détails...

Il est possible qu'il y ait un pb que j'ai déjà rencontré sur certains picaxes: le setint OR ne marchait pas.
Astuce, utiliser la fonction booléenne inverse:
setint NOT %00000101, %00000101, B
setint NOT %00000110 , %00000110, B
sinon, utiliser 1 seule entrée avec 2 diodes pour faire un OU
 

ddaweb

New Member
Bon bon ... setint est bien bugué fortement sur 28x2, à voir avec les autres !
Je ne sais pas si c'est vraiment utile de mettre le code, c'est celui du chrono de test où le setint est remplacé par le case :

case 11, 12 : setint or %00000000, %00000101, B -> ne fonctionne pas
case 11, 12 : setint or %00000000, %00000001, B -> ne fonctionne pas

case 11, 12 : setint not %00000101, %00000101, B -> ne fonctionne pas
case 11, 12 : setint not %00000001, %00000001, B -> fonctionne

case 11, 12 : setint %00000000, %00000001, B-> fonctionne
case 11, 12 : setint %00000000, %00000101, B -> ne fonctionne que pour l'entrée 1

La diode n'est pas possible avec les 4 possibilités.

Il ne me reste plus que le case et une partie / mode possible ... dites-moi si c'est efficace sur le principe :

Code:
#no_data
#no_table
#picaxe 28X2            'Type de Picaxe

symbol T1=w24
symbol T2=w25
symbol temps=w26
symbol mode_chrono=b54
symbol status_chrono=b55                     '1 = démarré et 0 = arrêté

symbol led_defaut=pinB.7

setfreq m16
settimer 64917    ' 0,001 s
hi2csetup i2cslave ,%00001000                'Initialisation du i2c Slave adresse 8


mode_chrono=12        'test
demarrage:
    ;get 1, mode_chrono                'mode via i2c venat de mon chrono
    select case mode_chrono                '---------- initialisation interuption du START
        case 12
            goto mode_12
        case 11
            goto mode_11
        case 21
            goto mode_21
        case 22
            goto mode_22
        else
            goto mode_12
    endselect

mode_12:
    do
        setint or %00000000,%00000101,B
        gosub boucle_start
        setint or %00000000,%00000110,B
        gosub boucle_stop
    loop

mode_11:
    do
        setint or %00000000,%00000101,B
        gosub boucle_start
        setint or %00000000,%00000101,B
        gosub boucle_stop   
    loop
mode_21:
    do
        setint or %00000000,%00000110,B
        gosub boucle_start
        setint or %00000000,%00000101,B
        gosub boucle_stop
    loop

mode_22:
    do
        setint or %00000000,%00000110,B
        gosub boucle_start
        setint or %00000000,%00000110,B
        gosub boucle_stop
    loop


interrupt:
    temps=Timer
return

boucle_start:
    do                    ' attente du START
        if led_defaut=1 then
            SETINTFLAGS OFF                'suppresion de l'interruption
            goto demarrage
        endif
    loop until temps>0

    T1=temps
    sertxd("T1=",#T1," - ",#mode_chrono,13,10)
    pause 1000                ' 1s ? 16 Mhz
    temps=0
    return

boucle_stop:
    do                    ' attente du STOP
    loop until temps>0
    T2=temps
    temps=t2-t1+65535+1
    sertxd("T2=",#T2," chrono=",#temps,13,10)
    pause 1000                ' 1s ? 16 Mhz
    bintoascii temps,b1,b2,b3,b4,b5
    put 3,b1,b2,b3,b4,b5                    'temps final disponible via i2c pour mon chrono
    pause 500
    temps=0
    return
Edit : je compte ajouter un code de resynchronisation du chrono-horloge (si nécessaire) et du chrono-complet avec un get 2, status_chrono ... à voir où le mettre
 
Last edited:

BESQUEUT

Senior Member
Euhhh ...
Si on pouvait éviter tous ces GOTO, genre :
Code:
symbol Pstart = b50    ' les PORTs pour le setint
symbol Pstop  = b51

mode_chrono=12        'test
demarrage:

    select case mode_chrono                '---------- initialisation interuption du START
        case 12: Pstart =%00000101 : Pstop =%00000110

        case 11: Pstart =%00000101 : Pstop =%00000101

        case 21: Pstart =%00000110 : Pstop =%00000101

        else :   Pstart =%00000110 : Pstop =%00000110
    endselect

   temps=0
   setint or %00000000,Pstart,B
    do                    ' attente du START
    loop until temps>0
    t1=temps : temps=0

    setint or %00000000,Pstop,B
    do                    ' attente du STOP
    loop until temps>0
    T2=temps
Mais en fait, vu que mode_chrono dépends de choix_sens,
il serait encore plus simple de supprimer mode_chrono
et de régler directement Pstart et Pstop
en fonction de la position des inters...

(Et je n'ai toujours pas compris pourquoi ce ne sont pas les inters qui amènent directement les barrières sur les entrées ad-hoc du Picaxe....)
Pourquoi faire simple quand on sait faire compliqué...
 
Last edited:

BESQUEUT

Senior Member
Juste pour vous tenir au courant de mes travaux en cours...
J'ai monté une plate forme de test avec deux T...y : un comme générateur, et un comme Chronomètre.
Ces bêtes sont habituées à travailler à la µs... et ça se vérifie...
Le générateur sort des pulses de 0,2 s avec un espacement progressif (1,0s 1,1s 1,2s 1,3s 1,4s, ...)
L'idée est d'éviter un systématisme qui donnerait toujours la même erreur pour la même durée, donnant l'impression d'une grande régularité.
Le Chrono varie de +/- 2 µs par rapport à ces temps théoriques (ce qui inclue à la fois le générateur et sa propre horloge...)

Autant dire que pour la ms, on est "large"...

Le programme du Picaxe est la version PieM.
On constate sans surprise que les temps inférieurs à 2s ne sont pas pris en charge.
Après, ça à l'air pas trop mal, mail il y semble y avoir un facteur d'échelle.
23016

23017

Après mise à l'échelle, les résultats sont semblables au test précédent : +/- 2 ms pour le Picaxe
23018
 
Last edited:

ddaweb

New Member
Comprends pas! Vous avez bien 2 entrées barrières différenciées et une entrée BP qui fait les deux. Donc 2 entrées et 4 diodes.
Le BP, via l'interruption, fait Start à l'arrêt et Stop si démarré ... dans tous les cas. Pour les 2 barrières, il y a 4 possibilités suivant le mode.
Une petite explication est la bienvenue ... je ne vois pas trop ce qu vous voulez faire avec les diodes, mais cela m'intéresse.

(Et je n'ai toujours pas compris pourquoi ce ne sont pas les inters qui amènent directement les barrières sur les entrées ad-hoc du Picaxe....)
Pourquoi faire simple quand on sait faire compliqué...
Je viens de comprendre ce que vous aviez déjà dit ... oui c'est faisable je penses, mais le mode dépend également du choix d'une barrière ou 2.
Le picaxe gère l'affichage LCD + les leds et les interruptions le déclenchement.
Vous voulez donc passer du software vers le hardware (plus rigide, mais est-ce vraiment un défaut dans tous les cas ? ... à creuser).

Votre code pour l'interruption est pas mal du tout, je ne savais que l'on pouvais faire cela (dire que je le fait en PHP .... grrrr) ... je teste demain.
J'apprends vraiment beaucoup avec vous ... surtout que je comprend vos codes, mais ne sais pas les écrire et en arrive donc à votre petite phrase humoristique :giggle: .

L'horloge au millième serait idéal, mais faut gérer les overflows ...
 

BESQUEUT

Senior Member
Je viens de comprendre ce que vous aviez déjà dit ... oui c'est faisable je penses, mais le mode dépend également du choix d'une barrière ou 2.
Ben oui : un inter pour chaque entrée (E1 et E2), et deux positions Barrière A ou Barrière B.
Le chronométrage se fait toujours de E1 vers E2 :
Code:
Barrières   E1    E2
A=> B       A      B
A=> A       A      A
B=> A       B      A
B=> B       B      B
Ou alors, on a deux prises E1 et E2 et on branche dans le bon sens, plus un inter qui met les deux entrées en parallèle dans le cas où on n'utilise qu'une seule prise.
Relire #118...
Si au final, on n'affiche que des centièmes, inutile de se casser la tête avec les millièmes : la précision reste la même.
Le seul intérêt est de mettre en évidence les écarts éventuels lors des tests ; si les millièmes sont bons à +/- 3, on est tranquille pour les centièmes.

Si on voit des millièmes qui varient à +/- 9 avec des pointes à 40, le centième est illusoire...
 
Last edited:

PieM

Senior Member
Le BP, via l'interruption, fait Start à l'arrêt et Stop si démarré ... dans tous les cas. Pour les 2 barrières, il y a 4 possibilités suivant le mode.
Une petite explication est la bienvenue ... je ne vois pas trop ce qu vous voulez faire avec les diodes, mais cela m'intéresse.
23020

Il n'y a plus qu'une seule interruption pour le départ (avec A ou B ou BP)
idem pour l'arrivée.
 

BESQUEUT

Senior Member
Vous voulez donc passer du software vers le hardware (plus rigide, mais est-ce vraiment un défaut dans tous les cas ? ... à creuser).
Ben... En l’occurrence, le hardware existe : autant l'utiliser, d'autant que l'on sait que la partie soft est aux limites pour un Picaxe dans ce type d'application...
 

ddaweb

New Member
Ou alors, on a deux prises E1 et E2 et ont branche dans le bon sens.
Plus un inter qui met les deux entrées en parallèle dans le cas où on n'utilise qu'une seule prise.
Non, je n'ai qu'une prise qui est également un adaptateur vers les raccordements de l'ancien chrono dont je dépend par sa fabrication ... les 2 sont 100% compatibles avec les barrières.
Je dois vous donner une petite explication pourquoi les entrées sont fixes sur l’ancien chrono : le start était une barrière simple, le stop une barrière double avec un sens de passage (donc 3 faisceaux au total et aussi 3 entrées), si une seule barrière, que la double était utilisée ... cela est historique et en fonction de la mise en oeuvre au moment de sa création, en bricolant un peu, j'ai su bypasser le sens de passage de la double barrière pour ne pouvoir utiliser qu'un faisceau.

En fait, ma réflexion était la suivante, vu que je n'ai qu'une confiance limitée aux utilisateurs :
- Le hardware est plus facile à mettre en oeuvre car bien défini ... mais si le chrono est démarré, son fonctionnement peu également en être modifié
- Le soft, un peu plus difficile : une fois le chrono démarré, impossible d'en modifier son fonctionnement qui est verrouillé ... j'ai opté pour la sécurité maximale avec cette méthode
- Il est plus facile de manipuler des interrupteurs que de changer des raccordements ... sans compter le gain de temps.

Les 2 méthodes ont évidemment leurs avantages et inconvénients ... rien ne dit pour l'instant que je ne change pas mon fusil d'épaule.

Mon plus grand tort est d'avoir choisi le picaxe pour ce genre d'application et pas un µc compilé ... mais bon, je ne savais pas que le picaxe était interprété au moment de le choisir et son langage était plus à ma portée (malgré mes erreurs).
 

BESQUEUT

Senior Member
Non, je n'ai qu'une prise qui est également un adaptateur vers les raccordements de l'ancien chrono dont je dépend par sa fabrication ... les 2 sont 100% compatibles avec les barrières.
Je dois vous donner une petite explication pourquoi les entrées sont fixes sur l’ancien chrono : le start était une barrière simple, le stop une barrière double avec un sens de passage (donc 3 faisceaux au total et aussi 3 entrées), si une seule barrière, que la double était utilisée ... cela est historique et en fonction de la mise en oeuvre au moment de sa création, en bricolant un peu, j'ai su bypasser le sens de passage de la double barrière pour ne pouvoir utiliser qu'un faisceau.

En fait, ma réflexion était la suivante, vu que je n'ai qu'une confiance limitée aux utilisateurs :
- Le hardware est plus facile à mettre en oeuvre car bien défini ... mais si le chrono est démarré, son fonctionnement peu également en être modifié
- Le soft, un peu plus difficile : une fois le chrono démarré, impossible d'en modifier son fonctionnement qui est verrouillé ... j'ai opté pour la sécurité maximale avec cette méthode
- Il est plus facile de manipuler des interrupteurs que de changer des raccordements ... sans compter le gain de temps.

Les 2 méthodes ont évidemment leurs avantages et inconvénients ... rien ne dit pour l'instant que je ne change pas mon fusil d'épaule.

Mon plus grand tort est d'avoir choisi le picaxe pour ce genre d'application et pas un µc compilé ... mais bon, je ne savais pas que le picaxe était interprété au moment de le choisir et son langage était plus à ma portée (malgré mes erreurs).
OK : on ne nous dit pas tous...
Vous avez maintenant des solutions simples aussi bien hard que soft... A vous de faire au mieux.
Votre choix du Picaxe est excellent parce que c'est le plus facile à mettre en oeuvre et qu'avec quelques précautions il répond aux besoins.
Ne vous méprenez pas : je fais des tests avec un µ compilé parce que j'en ai sous la main et que je sais m'en servir ; ça permet d'y voir clair sur les différentes approches possibles avec le Picaxe.
Par contre, à déconseiller aux débutants : aussi bien l'environnement que le langage nécessitent plus d'apprentissage que le Picaxe, et le tarif n'est pas le même...
Et je confirme utiliser des Picaxes tant que ça fait l'affaire : c'est très fiable, facile à mettre à jour ou à modifier et pas cher. On peut aussi facilement marier les deux : compilé avec un code très simple pour la partie nécessitant une grande vitesse, et Picaxe pour l'interface utilisateur et tout ce qui ne nécessite pas une vitesse extrême...
 
Last edited:

ddaweb

New Member
Je penses déjà avoir expliqué cela ... mais certainement noyé dans les posts ... probablement par morceau.

Je vais essayer d'avoir 2 quartz de 16 Mhz pour mettre sur les picaxe demain : mes tests ne me plaisent pas, trop de petites variations (aussi bien l'horloge que le chrono).
J'espère que cela va bien aider, même, encore en mieux, que mon chrono tel quel sera suffisamment stable ... hummmm du déjà dit :whistle:

En mettant settimer à 64917 et le générateur d'impulsion sur mon chrono, une bonne dizaine de mesures chaque fois, les dernières :
- pause à 30000 -> chrono : 30.07 à 30.08 (parfois 30.09, équivalent)
- pause à 40000 -> chrono : 40.06 à 40.07 (parfois 40.05, majoritairement 40.07)
- pause à 50000 -> chrono : 50.14 à 50.15 (majoritairement 50.15)
Mais si je coupe le 5v de toute l'installation, les valeurs changent légèrement et quelques cycles pour des valeurs plus stable... grrrr
Précision : 2 28x2 pour les chronos et 14m2 pour le générateur.

Bref sans quartz j'arrête tous mes tests ... pas 100% stable l'horloge interne du picaxe 28x2
 

BESQUEUT

Senior Member
Bref sans quartz j'arrête tous mes tests ... pas 100% stable l'horloge interne du picaxe 28x2
Pas stable, c'est certain, comme tous les PICs, et même tous les micros sur leur résonateur interne, qui est en fait un simple circuit R/C...
Attention, on parle bien de quartz, pas de résonateur comme couramment vendu avec les Picaxes...
Dans ce cas, bien penser à prendre avec les condos qui vont bien, sinon ça ne marche pas...
Jamais essayé sur un PIC, mais sur un ATMEL AVR, ce n'est pas toujours évident de trouver la bonne valeur, mêle avec la doc. Du coup, et vu que ces petites bêtes ne coûtent pas trop cher, j'en ai plusieurs avec des valeurs proches de ce qui est recommandé, au cas où. Pour mémoire, il en faut deux identiques, un entre chaque borne du quartz et la masse. Sinon, il y a aussi les oscillateurs à quartz intégré, bien plus fiables mais qui nécessitent une alim : oscillateurs
 

PieM

Senior Member
En mettant settimer à 64917 et le générateur d'impulsion sur mon chrono, une bonne dizaine de mesures chaque fois, les dernières :
- pause à 30000 -> chrono : 30.07 à 30.08 (parfois 30.09, équivalent)
- pause à 40000 -> chrono : 40.06 à 40.07 (parfois 40.05, majoritairement 40.07)
- pause à 50000 -> chrono : 50.14 à 50.15 (majoritairement 50.15)
Donc c'est la pause, instruction interprétée, qui dit que le chrono n'est pas précis ? Y a comme un truc que je n'ai pas compris là !
 

BESQUEUT

Senior Member
Donc c'est la pause, instruction interprétée, qui dit que le chrono n'est pas précis ? Y a comme un truc que je n'ai pas compris là !
Pas directement...Si j'ai bien compris :
Lorsque la pause est réglée à 30s sur le générateur, le chrono donne en général 30,07 ou 30,08 et parfois 30,09
Ce qui suggère que la moyenne est autour de 30,076 avec un écart de +/- 0,02 maximum

Il me semble utile de tester sur des durées différentes : c'est le seul moyen de calibrer un système qui ne serait pas intrinsèquement à l'échelle,
La durée exacte de l'impulsion n'étant pas connue, on ne peut pas s'en servir pour évaluer la précision du chronométrage, mais seulement sa stabilité (il me semble possible d'admettre que le générateur fasse toujours la même chose, pour une pause donnée, même si le temps n'est pas à l'échelle) Par contre, la linéarité des durées par rapport aux pauses n'est pas acquise... La courbe ne passe certainement pas par l'origine. Mais est-ce une droite ? (Fodra que je pense à tester ça maintenant que j'ai un bon étalon...)
Rien qu'avec les 3 durées citées, ce n'est pas linéaire. (Mais la loi des grands nombres ne s'applique pas à un petit nombre...)

Une fois chaud, le Picaxe semble relativement stable. Il est peu probable que le quartz change quoi que ce soit sur la stabilité des mesures rapprochées. C'est plus vraisemblablement le code qui est en cause.

Par contre, ça évitera probablement les différences au démarrage et d'une séance à l'autre.
 
Last edited:
Top