Mesure de temps d' exécution d' une ou plusieurs instructions

[PapyJP]

Voici une réponse tardive ( mieux vaut tard que jamais ) à la question posée par emge25 le 18/04/2012 dans son post " infos sur le timing ".

Où peut on trouver des informations sur la durée des diverses commandes pour d'une part optimiser le programme et
d'autre part, évaluer avant essai, l'ordre de grandeur de la durée des différentes boucles d'un programme.

S'il nous suit toujours, il trouvera ci-dessous quelques infos mais, ne connaissant pas son code, la meilleure façon est qu' il fasse sa mesure lui-même. Pour cela, je propose une méthode pratique et fiable pour réaliser ces mesures.
Malheureusementt elle ne s' adresse qu' aux possesseurs d' un analyseur logique ( ici un Scanalogic2 ) et d' un terminal avec clavier ( ici un Minitel 1B ).
Cette méthode peut-être utilisée quelle que soit la complexité du code et quel que soit le modèle de Picaxe ( ici un 20M2 ) sur lequel on aura réservé une entrée et une sortie à cet effet..

* Quelques résultats obtenus par cette méthode ( les résultats sont en millisecondes )

1/ Temps d'exécution d' une instruction.
1,a/ pause
pause 10 ---> 12,23
pause 50 ---> 52,28
pause 100 --->102,27
pause 200 --->202,25
1,b/ toggle
toggle C.0 ---> 2,34
toggle C.0 : toggle C.1 ---> 2,84
toggle C.0 : toggle C.1 : toggle C.2 ---> 3,34
1,c/ low / high
low C.0 ---> 2,31
low C.0 : low C.1 ---> 2,74
low C.0 : low C.1 : low C.2 ---> 3,17
high C.0 : low C.1 : low C.2 --->3,17
high C.0 : high C.1 : high C.2 --->3,17

2/ Temps d' exécution d' une boucle ( incrémenter b3 dix fois )
2,a/ do ... loop until
b3=0 : do : inc b3 : loop until b3=10 ---> 19,99
2,b/ for ... next
for n = 1 to 10 : inc b3 : next n ---> 12,56

3/ Temps d' exécution d' un branchement ( s'il y a match, exécution d' une sous routine contenant 'pause 100' )
3,a/ Select case
match au premier choix ---> 104,57
match au second choix ---> 106,13
match au 3ème ---> 107,88
match au 4ème ---> 109,53
match au 5ème ---> 111,28
3,b/ On n gosub sub0,sub1,sub2,sub3,sub4
n = 0 --->116,05
n = 1 ---> 117,94
n = 2 ---> 119,92
n = 3 ---> 121,70
n = 4 ---> 122,90
3,c/ branch n,(sub0,sub1,sub2,sub3,sub4)
n = 0 ---> 125,04
n = 1 ---> 126,80
n = 2 ---> 128,57
n = 3 ---> 130,34
n = 4 ---> 131,75

* Méthode de mesure.

L' analyseur logique va nous servir de chronomètre
Il est branché sur la broche d'entrée du Picaxe ( channel 1 par exemple ) et sur la broche de sortie ( channel 2 par exemple ). L'échantillonnage est choisi à 1 Mhz ( soit 1 us de résolution ).
Pour connaître la durée d' exécution d' une instruction, d' un bloc d' instructions ( nombre et imbrications non limité ) voire de tout un programme, il suffit de la ou les placer entre une instruction serin et une instruction serout.
Exemple :

;Mesure de temps d' exécution ---> une à n instructions simples
;20M2 + Minitel 1B + Analyseur logique ( Scanalogic-2-pro )
;==============================================================================

Init:
	high B.1			;place la ligne d' émission en un ( état repos )		

reception:
	low C.0:high C.1:high C.2 ;état initial des sorties
	
	serin C.7,T1200,b2	;attente de reception d' un caractère
	
	toggle C.0			;inversion de la sortie
	toggle C.1			;	"
	toggle C.2			;	"

	serout B.1,T1200,($0C)	;efface l' écran, curseur en L1xC1
	goto reception

On lance le programme. Il s' arrêterra en attente d' un caractère. Ce caractère, tapé au clavier, sera enregistré sur channel 1 ( serin ), puis la ou les instructions à mesurer seront exécutées et enfin l' analyseur enregistrera la réponse du Picaxe ( serout ) sur channel 2.
Le trigger de l' analyseur étant calé au zéro de l' échelle des temps, le temps d' exécution recherché est égal à la mesure du temps au premier flanc de la trame serout sur channel 2 diminué du temps d' exécution de serin.
Dans le cas de l' utilisation d' un Minitel, ce temps d' exécution de serin est égal à 1 / 1200 * 10 = 8,333 ms ( 10 bits à 1200 bps ). C' est ce temps qu' il faut retrancher.
On peut aussi ' saucissonner ' le code en y plaçant plusieurs serout. Dans ce cas retrancher, en plus, autant de fois 8,333 ms qu' il y a de trames serout précédant celui mesuré.
Les trames échangées comportant toujours un bit ' start ' il n'y a aucune ambiguité.

Commentaires et avis bienvenus ( pas de demandes de mesures svp ).

 

[PieM]

Bonjour,

Si on utilise un analyseur logique, je ne comprends pas trop l'intérêt d'utiliser un minitel...
Je pense que la procédure suivie n'est pas correcte car elle introduit des temps non estimé. Le premier flanc d'un serout n'est pas le temps de fin de l'instructon précédente.

à 4MHz, un 08M2 met environ 250 µs pour un toggle, un high ou un low soit 10 fois moins que ce que vous trouvez.

 

[PapyJP]

je ne comprends pas trop l'intérêt d'utiliser un minitel...

J' ai écrit : un terminal avec clavier. Il se trouve que, dans mon cas c' est un Minitel.
L' avantage du serin est que l' on peut réarmer l' analyseur pendant l' attente pour effectuer plusieurs mesures successives.
C' est peut-être mince, voire inutile, mais c' est confortable !

introduit des temps non estimé

Bien sûr ce n' est pas la mesure du temps d' exécution de l' instruction pure et dure.
Ca n' aurait aucun interet pratique.
L' important est de savoir quand la commutation d' une sortie ( toggle par exemple par exemple ) sera effective.
La méthode proposée y réponds. En pratique c' est ça l' important.
Il semble, et c' est bien normal, que le Picaxe mouline, avant et aprés une instruction avant de commuter réellement une sortie ( pause par exemple dure 2,23 ms de plus que le temps demandé: j' imagine que c' est le temps nécessaire pour dire : Bon, serin est fini, que me demande-t-on, Ah une pause, de combien de temps ?, ok je charge un compteur avec cette valeur, j' ouvre le porte de l' oscillateur, j' attends l' over flow, etc etc.......................... ).

Cette hypothèse se vérifie en faisant serin immédiatement suivi d' un serout ( sans rien entre les deux ). On trouve un retard de 1,86 ms entre la fin de serin et le flanc avant de serout.
( Cette joute me rappelle un certain ' start ' implicite )

un 08M2 met environ 250 µs pour un toggle

C' est possible. Ca m' agace de vous contredire mais j' ai refait des mesures avec le code donné en exemple et je confirme les valeurs annonçées ( moulinage + exécution de l' instruction ) .
Vous remarquerez que pour passer de un à deux toggle successifs, la durée n'augmente que de 430 us puis à nouveau de 430 us pour passer de deux à trois.
Même chose pour les low / high.
Tout a fait compatible avec les valeurs que vous annoncez !
Que fait le Picaxe le reste du temps ? Que mouline-t-il ?

 

[westaust55]

Bien qu'en Anglais, vous trouverez quelques détails de plus utiles dans les informations de programmation j'ai posté en mars 2011 ici :
http://www.picaxeforum.co.uk/showthread.php?17782-PICAXE-program-Size-Optimisations-and-Speed

L'information couvre non seulement moment de commande de programme, mais comment l'utilisation de la mémoire les effets de la structure du programme

 

[PieM]

Bien sûr ce n' est pas la mesure du temps d' exécution de l' instruction pure et dure.
ça n' aurait aucun interet pratique.

Ah bon ? Mais quel intérêt de faire une mesure en introduisant une instruction particulièrement gourmande en temps qui vient tout fausser!
Ce qui intéresse dans l'optimisation d'un programme c'est de connaître au plus près la durée effective d'une instruction, sans rajouter du "moulinage" qui n'a rien à voir avec l'exécution de l'instruction.

L' important est de savoir quand la commutation d' une sortie ( toggle par exemple par exemple ) sera effective.

Ce n'est pas ce que vous mesurez :

la mesure du temps au premier flanc de la trame serout sur channel 2 diminué du temps d' exécution de serin. ( du minitel ??)

Ce qui est très différent de la fin de mesure liée au changement d'état de la sortie toggle.


Si pour vous pause 10 mets 12 ms, cela voudrait dire qu'il y a selon vous 2 ms de "moulinage" donc que pause 1 met plus de 2 ms ?

A ce titre la procédure suivie par Westaust, Hippy et MartinM57 (à l'oscillo) me semble plus proche de la réalité observée à l'analyseur logique dans un programme réel.
Et si dans celui ci j'utilise des serin et des serout, je sais que ça va prendre en plus plusieurs ms en fonction de ce qui est transmis. (10 ms à 4MHz de plus pour transmettre ("AAA") au lieu de ("") !)

Dans le document de Westaust, une boucle
loop1:
high 1
low 1
goto loop1

va mettre effectivement 875 µs soit proche de : 260 + 260 + 330 µs, la somme des temps élémentaires mesurés avec leur méthode.

Ca m' agace de vous contredire mais j' ai refait des mesures avec le code donné en exemple et je confirme les valeurs annonçées

Mais ce n'est pas le chronomètre qui est en cause ! c'est la méthode, et l'objet mesuré !

 

[PapyJP]

Je n' ai pas encore lu le document de Westaust.
Donc à suivre ..................

Par contre

donc que pause 1 met plus de 2 ms ?

Oui.
Toujours à l' analyseur, si j' exécute " high C.0 : pause 1 : high C.1 "
je trouve 2,08 ms entre les flancs montants de C.0 et C.1
Donc ' pause 1 ' entraîne un retard de 2ms
Je ne crois pas m' être trompé !

 

[PieM]

je trouve 2,08 ms entre les flancs montants de C.0 et C.1, Donc ' pause 1 ' entraîne un retard de 2ms

La mesure entre deux fronts montants inclut la durée de l'instruction high en plus de la pause.
Et visiblement, vous avez changé votre méthode de mesure, puisque avant vous trouviez plus de 2ms pour un simple high ou low C.0 ...

Croyez moi écrire "pause 1 ' entraîne un retard de 2ms" n'est pas conforme à la réalité.

Le document de Westaust n'a jusqu'à présent jamais été mis en défaut .

 

[PapyJP]

Mais quel intérêt de faire une mesure en introduisant une instruction particulièrement gourmande en temps qui vient tout fausser!

Cette instruction serin, certes gourmande en temps, ne vient rien fausser du tout dans la mesure ou son temps d' exécution est parfaitement connu.

Vous doutez du Minitel ? Ou de votre terminal ? Tapez ' G ' qui a l' avantage de créer un flanc à la fin du 9 ème bit, c' est à dire le début du dixième bit.( la fin du dixième bit de la transmission n' est pas mesurable car il rejoint le niveau de repos de la ligne d' émission ). Vous mesurez son instant d' arrivée soit 7,500 ms donc pour 10 bits : 7500 / 9 * 10 = 8,333 ms.
La valeur théorique ( 10 bits à 1200 bps pour un Minitel ) est 1 / 1200 * 10 = 8,333 ms.
Pas mal ! Il doit y avoir un oscillateur à quartz dans ce Minitel.
Quant à serout, seul le flanc avant nous importe.
Heureusement car je n' en dirais pas autant de la durée de serout envoyé par le Picaxe. J' aurai un doute. Si j' y pense je ferai une mesure.
Les oscillateurs de nos chers Picaxes semblent être un peu différents en fréquence d' un type à l' autre mais jamais calés sur la fréquence théorique donnée dans les sheets. J' en veux pour preuve un article dans le Forum en anglais dans lequel il est expliqué qu' il n' est pas possible de faire des transferts de longues chaînes de caractères entre un 08M2 et un 20M2. Il est conseillé de ne faire des transferts qu' entre Picaxes du même type.
La raison en serait que l' un est plus rapide, l' autre moins rapide par rapport à la fréquence théorique et que, par conséquent, au bout de quelques caractères transmis le décalage en temps entraîne une mauvaise transmission.
L' article précise que ces écarts de fréquence des oscillateurs sont identiques et constants pour un même type et seraient dus à des pb de fabrication.

La mesure entre deux fronts montants inclut la durée de l'instruction high en plus de la pause.

Bien sûr il y a d' abord, à partir du flanc montant de C.0, le traitement ' de pause 1 ' suivi du traitement de ' high C.1 '.
Comme ni letraitement de ' pause 1 ' ni le traitement de ' high C.1 ' ne sont instantanés , la commutation de la sortie n' a lieu que 2ms après le flanc montant de C.0. Tout s' explique.

Croyez moi écrire "pause 1 ' entraîne un retard de 2ms" n'est pas conforme à la réalité.

Pourtant si l' on voulait avoir deux flancs séparés exactement de 1ms, il faudrait trouver une autre forme de code car ' pause 1 ' ne convient pas comme on pourrait le croire.
En effet, si ' pause 1 ' dure exactement 1ms et ' high C.1 ' dure 430 us ( voir ci-dessous ) ça fait déjà 1,43 ms. Moi je mesure 2 ms.

vous avez changé votre méthode de mesure

Non. J' aurais dû commenter ces mesures en 1,b et 1,c de #1. I apologise !
Ce qui compte dans ces § c' est la différence des instants de mesure ( par exemple entre 1 toggle et 2 toggle l' écart donne le temps d' exécution du second toggle. On peut vérifier pour deux ou trois instructions successives, on trouve toujours environ 430 us pour ces instructions comme je vous le faisais remarquer en #3.
J' ai fait tourner le code proposé par Westaust que vous donnez en #5. Je mesure 455 us. Je ne vais pas pinailler pour quelques us.
Vous proposez 260 us ...........essayez ! Et tenez moi au courant, merci.

Le document de Westaust n'a jusqu'à présent jamais été mis en défaut .

Ce n' est pas mon intention, mais je juge sur pièces , comme St Thomas.

 

[PieM]

Pourtant si l' on voulait avoir deux flancs séparés exactement de 1ms, il faudrait trouver une autre forme de code car ' pause 1 ' ne convient pas comme on pourrait le croire.

Mais c'est évident ! pause 1 c'est une milliseconde entre le début de l'instruction et la fin de la même instruction. Si on ajoute une instruction (High 1) il est certain que le temps total entre fronts montants est supérieur au temps de pause.
Cela ne vous permet pas de dire que pause 1 entraine un retard de 2 ms.
pas plus que de dire que la durée de pause 10 est de 12.23 ms , etc ...

Si en utilisant la même routine que Westaust, vous trouvez des valeurs aussi différentes, c'est bien que votre méthode de mesure est en cause.
Personnellement j'ai toujours vérifié en pratique la fiabilité de ses mesures.

je juge sur pièces , comme St Thomas.

encore faut-il juger la même pièce !

Utiliser l'artifice de mesure entre 1er front d'un serin puis d'un serout pour mesurer la durée d'une instruction me semble une approche totalement biaisée.

Votre calcul de la durée de transmission de 10 bits est une chose, mais qui vous dit que le Picaxe enchaîne immédiatement après le dernier bit reçu, sur l'instruction suivante...
Et vous dites vous même ne pas connaître la durée d'un serout entre début d'instruction et le bit de start, alors que vous l'incluez dans la mesure.

Amusez vous à faire un chronogramme des signaux et vous verrez ...

Pour faire ce type de mesure, il suffit de mesurer les temps directement sur les broches actives du picaxe soit avec un analyseur, un oscillo ou un picaxe externe via un pulsin, comme l'a fait Westaust dont la référence de son document avait déjà été donnée dans la question emge25 du 18/04/2012, par Besqueut.

 

[PieM]

Pour info, voici des mesures effectuées avec un analyseur et une résolution de 0.1 µs, pour Toggle et High / Low sur un Picaxe 18M2:





Elles confirment, si besoin était, les valeurs du tableau de Westaust.

 

[PieM]

Et pour confirmer que la mesure faite sur le front montant d'un serout entraîne un retard systématique par rapport à l'instruction précédente, voici le chronogramme du serout N2400, ("").
Un retard de 1.616 ms peut être observé. Par contre la durée du serout est bien dans ce cas de 5.3 ms, conformément aux mesures de Westaust.


de la même façon que le serout N2400 ("AAA") a bien une durée de l'ordre de 15 ms, y compris le retard de 1.7 ms

 

[PieM]

Quant au pause 1, la mesure montre 1626 - 340 µs (du low) soit 1.286 ms pour 1.290 dans le tableau !

 

[PapyJP]

Merci à Westaust et Besqueut pour leur intérêt et leurs infos.

PieM
Vous vous êtes mépris sur le sens de mon post #1. Je n' avais pas l' intention de donner des valeurs précises de temps d' exécution des instructions mais seulement de confirmer à emge25 qu' en effet les Picaxes sous Basic sont loin d' être véloces.
Vous même, Besqueut et d' autres ont souvent signalé qu' une instruction Basic demandait 1000 voire jusqu' a 10.000 instructions machine.
Je donnais quelques temps d' exécution parfaitement dissuasifs pour celui qui cherche la rapidité.
Je lui suggérais de faire lui-même des mesures " in vivo " par une méthode que je lui décrivais, même si elle n' est pas originale pour vous.

Dans vos réponses et remarques, ( je vous remercie d' y avoir passé du temps ), votre ton moqueur, légèrement condescendant ( au sens indulgent s' entend ) mais je suppose en toute amitié, m' a piqué au vif.
C' est la raison pour laquelle j' ai refait tout un tas de manips avec mon 20M2 en y apportant toute la rigueur et le soin possible pour obtenir MA confiance dans les résultats.

Le document de Westaust fait référence ? Ok !
Dommage que le 20M2 y soit exclu ( trop récent ? ) car je constate une grande disparité entre les modèles de Picaxes.
Comme la présentation des mesures en #1 est assez brouillonne et difficile à interpréter sans réflexion, vous trouverez ci-dessous un tableau ( galère en html ! ) qui reprends les mesures " de référence " auxquelles j' ai ajouté une colonne concernant le 20M2.
Je précise que ce sont MES mesures et, qu' en l' absence de l' imprimatur de Westaust, elles restent discutables et sujettes à caution ( de Westaust en l' occurrence ).

	_____08M_​	_____18M2_​	_____28X2_​	_____20M2_​
Pause 1	1250​	1290​	2320​	1258​
Pause 15	15320​	15360​	30310​	17574​
High 0	250​	310​	390​	420​
High 4	290​	340​	440​	430​
Low 0	250​	310​	390​	420​
Low 4	290​	340​	440​	430​
If b0=1 then	​	550​	810​	640​
If w0=w1 then	​	540​	990​	800​
b0 = 16	430​	510​	580​	490​
b1 = b1+b2	500​	650​	770​	650​
b1 = b2+b1	760​	770​	1140​	960​
toggle 2	290​	420​	440​	430​
serout ("")	5210​	5380​	5180​	8362​
serout ("AAA")	15010​	15100​	14490​	28486​

Remarques sur le serout :
- Les valeurs données par W sont réalisées à 2400 bps. Il convient donc de tenir compte d' un facteur 2 pour comparer.
- Deux anomalies dans les valeurs de W :
*** Il y a toujours dix bits transmis que ce soit une chaîne vide ("") ( 9 bits à zéro + stop dans mon cas ) ou un caractère ("A") ( également 9 bits + stop )
Donc, a 2400 bps, le temps de " serout " pour une chaîne vide ou un caractère devrait être 1 / 2400 * 10 = 4166 us ( ? )
Le résultat annoncé est 23% plus élevé, incompatible avec une dérive d' horloge .
On voit bien que 4166 * 2 = 8332, trés proche de ma mesure.
*** La durée de transmission de trois caractères ("AAA") est inférieure à trois fois celle d' un caractère ( ? ).

En conclusion, je considère que ce fastidieux travail n' est d' aucune utilité pratique.
Pour un code un peu complexe je doute que la durée totale d' exécution soit la somme mesurée de ses parties.
St Thomas ne croit pas aux miracles.
Si un projet nécessite une maîtrise absolue des temps entre deux actions, seule une mesure sur maquette peut donner les durées réelles entre les actions et valider le code. Cette mesure tiendra même compte des écarts de fréquence des différents types de Picaxes.
Si l' on veut deux flancs séparés de 1 ms, " pause 1 " ne convient pas comme on pourrait le croire.
Et il n' y a pas de " nop " pour peaufiner la us !

 

[PieM]

Bonjour,

Si un projet nécessite une maîtrise absolue des temps entre deux actions, seule une mesure sur maquette peut donner les durées réelles entre les actions et valider le code. Cette mesure tiendra même compte des écarts de fréquence des différents types de Picaxes.

Il me semble que c'est exactement ce qu'ont fait W55 et les autres, y compris moi même avec les chronogrammes que je vous ai fait.

Les différences de fréquences sont expliquées dans le texte du document Westaust, en particulier le problème lié aux M2 et X2 par rapport aux M,X, et X1.

Par contre quand vous reprenez les valeurs du tableau, pour ce qui concerne le 28X2, je vous signale que sa fréquence de base est de 8 MHz et non 4MHz correspondant aux valeurs que vous avez retenues. Il est normal qu'à 4 Mhz un 28X2 soit donc plus lent. Il fallait prendre les valeur de l'autre colonne pour être cohérent.

Donc, a 2400 bps, le temps de " serout " pour une chaîne vide ou un caractère devrait être 1 / 2400 * 10 = 4166 us ( ? )
Le résultat annoncé est 23% plus élevé, incompatible avec une dérive d' horloge .
On voit bien que 4166 * 2 = 8332, trés proche de ma mesure.
*** La durée de transmission de trois caractères ("AAA") est inférieure à trois fois celle d' un caractère ( ? ).

Vous n'avez visiblement pas vu les chronogrammes d'une sortie serout ....
J'y expliquais qu'entre le début de l'instruction et le front montant du bit de start, s'écoulait entre 1.6 et 1.7 ms. Un serout ne comprend donc pas uniquement le temps de transmission des bits.
Donc il est normal que la transmission de 3 caractères soit inférieur à 3 fois le temps de transmission d'un seul caractère.

Pour finir, il n'y a aucun "ton moqueur, légèrement condescendant " de ma part.
Mais je pense que l'approche faite lors de vos mesures et des conclusions "Je donnais quelques temps d' exécution parfaitement dissuasifs pour celui qui cherche la rapidité." ne correspond pas à la réalité et pouvais conduire des utilisateurs à renoncer à certains projets. Ce qui serait regrettable.

Et il n' y a pas de " nop " pour peaufiner la us !

: si .... avec d'autres instructions que pause et en utilisant une fréquence d'horloge élevée.

En conclusion, je considère que ce fastidieux travail n' est d' aucune utilité pratique.

C'est votre opinion que je suis désolé de ne pas partager. Je suis personellement très heureux de pouvoir d'utiliser les travaux rigoureux de Westaust & Co sur le sujet.

PS : Dans les valeurs que vous avez recopiées du tableau, il y a quelques erreurs concernant le 18M2. certaines données sont celles du 08M.

 

[PapyJP]

En effet, je me suis emmêlé les crayons dans les " If " ( rien à voir avec vos beaux arbres du midi ... ).
Par contre, concernant le 28X2, j' ai bien recopié l' avant dernière colonne du tableau ( 28X2, clock speed 4 MHz en ligne 2 )
Ci-dessous tableau corrigé ( en us ), tous les Picaxes à 4 MHz, sauf erreur :

	_____08M_​	_____18M2_​	_____28X2_​	_____20M2_​
Pause 1	1250​	1290​	2320​	1258​
Pause 15	15320​	15360​	30310​	17574​
High 0	250​	310​	390​	420​
High 4	290​	340​	440​	430​
Low 0	250​	310​	390​	420​
Low 4	290​	340​	440​	430​
If b0=1 then	550​	710​	810​	640​
If w0=w1 then	540​	1260​	910​	800​
b0 = 16	430​	510​	580​	490​
b1 = b1+b2	500​	650​	770​	650​
b1 = b2+b1	760​	770​	1140​	960​
toggle 2	290​	420​	440​	430​
serout ("")	5210​	5380​	5180​	8362​
serout ("AAA")	15010​	15100​	14490​	28486​

* Pour les serout du 20M2, mesures à 1200 bps, "moulinage" initial non compris.

Vous n'avez visiblement pas vu les chronogrammes d'une sortie serout ....

Vous plaisantez ou vous vous moquez ?
Soyons positifs et dites-moi plutôt quel signal vous enregistrez en channel 3 de #11 pour encadrer un serout dont on ne connait pas la fin. Et expliquez-moi par quel mystère les temps ' morts ' entre les serout 2 et 3 de serout ("AAA") sont plus courts d'une durée de 1 bps.

Quant au pause 1, la mesure montre 1626 - 340 µs (du low) soit 1.286 ms pour 1.290 dans le tableau !

Donc nous sommes d' accord ! Pour les instructions ' cadencées ' ( Pause, serout ) il faut ajouter un temps de " moulinage " qui dépends du type de Picaxe.

...pourrait conduire des utilisateurs à renoncer à certains projets

Les Picaxes ont leurs avantages et leurs inconvénients. Je ne vois aucune raison de les cacher.
Lorsque l' on a le projet de faire un trou dans du béton pour y placer une cheville, on choisit un outil adapté ( à savoir une perceuse à percussion et un foret à béton).
La déception de emge25 provient manifestement d' un mauvais choix. Et d' une méconnaissance des caractéristiques des Picaxes.
D' ailleurs vous le dite vous-même :

La solution existe: prenez un PIC et programmez le en assembleur si vous devez suivre des étoiles filantes !

 

[PieM]

Je vous ai écrit :

pour ce qui concerne le 28X2, je vous signale que sa fréquence de base est de 8 MHz et non 4MHz correspondant aux valeurs que vous avez retenues. Il est normal qu'à 4 Mhz un 28X2 soit donc plus lent. Il fallait prendre les valeur de l'autre colonne pour être cohérent.

C'est la documentation, suis désolé! mais vous n'êtes pas obligé de la croire, elle non plus, mais c'est le principe même de la gestion des temps sur Picaxe.

Syntax:
PAUSE milliseconds
- Milliseconds is a variable/constant (0-65535) which specifies how many
milliseconds to pause (at 8MHz on X2 parts, 4MHz on all other parts)

Vous plaisantez ou vous vous moquez ?

ni l'un ni l'autre. La mesure a été faite avec la même procédure que celle de Westaust avec un 18M2 ver.2A à 4MHz, avec un analyseur logique et 1µs de résolution.

Main:
High C.0
'command under test
Low C.0 (de durée connue avec précision)
Goto Main

Connaissant la durée d'un Low , la fin du serout est ainsi parfaitement définie, et il est très facile de faire une mesure.
Des mesures faites sur un Picaxe 14M2 Ver. 6.A plus récent, donnent sensiblement les mêmes valeurs: 5430 µs pour un serout ("") et 15728 µs pour un serout ("AAA") et 15296 pour un pause 15

Je vous précise sur ce chronogramme a quoi correspondait les différents fronts de mesure, pour qu'il n'y ait aucune interprétation erronée.

par quel mystère les temps ' morts ' entre les serout 2 et 3 de serout ("AAA") sont plus courts d'une durée de 1 bps

Je ne vois pas de quoi il s'agit. Il y a au début 1.7 ms lié a l'instruction Serout (votre moulinage) puis ensuite, 1.365 µs entre une fin de bit de stop et le bit de start suivant, chaque bit durant 409 µs.

Les Picaxes ont leurs avantages et leurs inconvénients. Je ne vois aucune raison de les cacher.

Bien évidemment ! mais il est inutile de leur trouver des inconvénients qu'ils n'ont pas, en particulier auprès d'un utilisateur qui n'avait, semble t-il qu'une approche assez ... récente des Picaxe.

pour passer de un à deux toggle successifs, la durée n'augmente que de 430 us puis à nouveau de 430 us pour passer de deux à trois.

Dire "toggle C.0 ---> 2,34ms" mais que si on rajoute un second toggle ça ne prends que 430µs de plus, est faux, et fait donc douter de la mesure du 1er toggle, donc du reste..

Voilà , cher Saint Thomas je vous laisse avec vos croyances, mystères, et autres miracles , car il s'agit là d'un domaine qui m'est très étranger. N'attendez donc de ma part aucun prosélytisme ...

 

[PapyJP]

Ok sur l' ensemble de vos remarques.
Sauf que je ne comprends toujours pas le chronogramme !
Comme je l' ai dit :

[ expliquez-moi par quel mystère les temps ' morts ' entre les serout 2 et 3 de serout ("AAA") sont plus courts ...

La transmission se fait sur 10 bits, le bit start étant implicite ( cf une de nos joutes précédentes où vous avez bien sûr gagné ! ) mais il est bien présent sur le chronogramme.
Le comptage du nombre de bits transmis ( avec un calque ) montre 1 bit start suivis de 8 bits " data ".
Comme déja dit, la fin du bit stop est difficile à borner puisque la ligne revient à zéro ( dans votre cas ).
Vous répondez :

Je ne vois pas de quoi il s'agit. Il y a au début 1.7 ms lié a l'instruction Serout (votre moulinage) puis ensuite, 1.365 µs entre une fin de bit de stop et le bit de start suivant, chaque bit durant 409 µs.

C 'est bien se qui me gène car si l' instruction suivant le serout attendait la fin du bit stop l' instruction " low C.0 " devrait être décalée de la durée du bit stop soit 409 us.
L' analyse de ce chronogramme ( qqsoit le "A" transmis ) me fait penser que le Picaxe se fout du bit stop comme de sa première chemise.
Vous remarquerez que 1365 + 409 = 1774

PS : Comment faites-vous pour écrire et plaquer un calque en surimpression sur votre chronogramme ?

 

[PieM]

Nous sommes dans l'estimation des durées des instructions du Picaxe.

Mesurer le pulse correspondant à la durée d'une instruction serout plus une instruction LOW , connaissant la durée de cette dernière, permet de connaître la durée d'une instruction SEROUT xxxx.

Après on peut s'amuser à découper en rondelles le contenu de Serout pour savoir pourquoi il ne correspond pas à vos attentes en termes de timing, mais c'est un autre problème qu'il vaudrait mieux poser aux techniciens de Rev-Ed ...

Comment faites-vous pour écrire et plaquer un calque en surimpression sur votre chronogramme ?

c'est du texte sur un fichier jpg.

 

[emiliogallard]

Je ne rêve pas, nous sommes bien sur un forum français!
Dans tous les cas, chapeau bas pour ces démonstrations éblouissantes, j'ai encore bien des choses à apprendre sur le sexe des anges.
Amitiés