durée transition entre un digitalwrite high et low

bonjour
pas de materiel de mesure sous la main aujourd'hui

quelqu'un a t'il une idée de la fréquence du carré générée sur un uno pour une simple boucle
C'est juste par curiosité :grin:

pseudo loop {
digitalWrite (CLOCK,HIGH);
    //delay(1); OK
    //delayMicroseconds(1); OK aussi ça ne decroche pas 
   // test sans aucun delais soft ça ne decroche pas non plus , tant mieux 
    digitalWrite(CLOCK,LOW);
}

je me répond à moi meme :grin: (ça m’évitera d'oublier)

Durée du créneau 3.6 µs ~

bonjour,

intéressant a savoir merci =)

Skizo !

Il y a quelques mois j'avais fait une comparaison entre utiliser la fonction arduino "digitalWrite" et écrire directement dans les registres ([Tests] Temps pour faire changer d'état une pin (niveau Haut/Bas) - Français - Arduino Forum).
J'avais trouver qu'en écrivant directement dans les registres on gagnait un rapport 10.

Si je regarde ta copie d'écran je trouve une période de 8.2 µs (1) soit une fréquence de 122 kHz, on peut donc espérer 1,22 Mhz en écrivant directement dans les registres.

(1) le temps du "1" (3,6µs) est supérieur à celui du "0" (4,6µs).

Pour information te serait-il possible de mesurer les temps de montée et de descente entre 20% et 80% de l'amplitude du signal, merci.

digitalWrite() fait un peu de vérifications tel que mettre la pin en sortie si ce n'est pas déjà le cas.
Ceci pour des raisons de compatibilité avec Wiring qui n'impose pas d'utiliser pinMode().

C'est dommage parce qu'une version de digitalWrite() sous la forme d'une macro serait beaucoup plus efficace.

68tjs:
Il y a quelques mois j'avais fait une comparaison entre utiliser la fonction arduino "digitalWrite" et écrire directement dans les registres ([Tests] Temps pour faire changer d'état une pin (niveau Haut/Bas) - Français - Arduino Forum).
J'avais trouver qu'en écrivant directement dans les registres on gagnait un rapport 10.

Si je regarde ta copie d'écran je trouve une période de 8.2 µs (1) soit une fréquence de 122 kHz, on peut donc espérer 1,22 Mhz en écrivant directement dans les registres.

(1) le temps du "1" (3,6µs) est supérieur à celui du "0" (4,6µs).

Pour information te serait-il possible de mesurer les temps de montée et de descente entre 20% et 80% de l'amplitude du signal, merci.

bonsoir 68tjs
ok pour le rapport 0/1 ,dans la mesure où c'etait pour jouer, c'etait plus l'ordre de grandeur
je vais mesurer ça plus precisemment mercredi avec du bon materiel, là j'ai ressorti un petit scope de la cave juste pour voir, et je n'ai pas de sondes dignes de ce nom, d'ailleurs ça se voit bien avec les amortis en montée et descente. :grin:
2 photos avant qu'il retourne au stockage 8)

barbudor:
digitalWrite() fait un peu de vérifications tel que mettre la pin en sortie si ce n'est pas déjà le cas.
Ceci pour des raisons de compatibilité avec Wiring qui n'impose pas d'utiliser pinMode().

C'est dommage parce qu'une version de digitalWrite() sous la forme d'une macro serait beaucoup plus efficace.

Ça existe depuis longtemps :wink:
Google -> digitalWriteFast -> Google Code Archive - Long-term storage for Google Code Project Hosting.

Ok, mais une fois encore ce n'est pas dans la lib standard et introuvable depuis les points d'entrées de arduino.cc :wink:
Ni même dans le playground (ou pas trouvé)

Mais merci pour le lien, j'ajoute ca tout de suite dans mon répertoire Libraries (comme ça pour compiler Blink je vais passer de 5 minutes à 6 minutes, vu le nombre de lib que j'ajoute chaque semaine....:frowning: )

barbudor:
Ok, mais une fois encore ce n'est pas dans la lib standard et introuvable depuis les points d'entrées de arduino.cc :wink:
Ni même dans le playground (ou pas trouvé)

Elle est (enfin était) sur le playground, seulement les développeurs arduino on jamais pu blairer cette librairie.
Probléme de taille, cette version est très peu portable, et ne compile que pour quelques micro-contrôleurs classique (atmega2560, atmega328), c'est pour ça quelle ne fait pas parti du core officiel.

barbudor:
Mais merci pour le lien, j'ajoute ca tout de suite dans mon répertoire Libraries (comme ça pour compiler Blink je vais passer de 5 minutes à 6 minutes, vu le nombre de lib que j'ajoute chaque semaine....:frowning: )

J'ai pas ce probléme vu que j'utilise plus l'ide arduino (makefile powaaa) :stuck_out_tongue:

C'était encore une occasion de sortir mon OLS tout neuf

#include "digitalWriteFast.h"

#define PIN_NUM      13

void setup()
{
  pinMode( PIN_NUM, OUTPUT );
}

void loop()
{
 digitalWriteFast( PIN_NUM, LOW );
 digitalWriteFast( PIN_NUM, HIGH );
 digitalWriteFast( PIN_NUM, LOW );
 digitalWriteFast( PIN_NUM, HIGH );
 digitalWriteFast( PIN_NUM, LOW );
 digitalWriteFast( PIN_NUM, HIGH );
 digitalWriteFast( PIN_NUM, LOW );
 digitalWriteFast( PIN_NUM, HIGH );
 digitalWriteFast( PIN_NUM, LOW );
 digitalWriteFast( PIN_NUM, HIGH );
 digitalWriteFast( PIN_NUM, LOW );
 digitalWriteFast( PIN_NUM, HIGH );
 digitalWriteFast( PIN_NUM, LOW );
 digitalWriteFast( PIN_NUM, HIGH );
 digitalWriteFast( PIN_NUM, LOW );
 digitalWriteFast( PIN_NUM, HIGH );
}

Conclusion : 120ns pour un digitalWriteFast mais 760ns pour le loop (sortie de loop(), retour dans main(), while(1) dans main, appel de loop())

En mettant le while(1) dans loop(), on passe à 135ns pour la boucle.

J'ai pas ce probléme vu que j'utilise plus l'ide arduino (makefile powaaa)

Je vais y venir !

@Artouste
Les suroscillations ne viennent pas forcément que des sondes : les pistes tarabiscotées, la qualité du plan de masse sur la carte et les horribles connecteurs pour empiler les cartes ont aussi leur part de responsabilité.
A vue de nez les temps de montée et de descente font 0,2 div soit en gros 100ns.
Je posais la question pour évaluer la bande passante des connexions nécessaire pour ne pas avachir les signaux. En appliquant la formule empirique Fmin = 1/(2.2*tm) on obtient 5 Mhz. Jusqu'à des longueurs de 10cm cela devrait passer sans trop de difficultés mais au delà paire torsadée obligatoire.
C'est vraiment une calamité que dans les implantations des cartes il n'y ait pas plus d'emplacement pour des reprise de masse.

barbudor:
C'était encore une occasion de sortir mon OLS tout neuf

Conclusion : 120ns pour un digitalWriteFast mais 760ns pour le loop (sortie de loop(), retour dans main(), while(1) dans main, appel de loop())

En mettant le while(1) dans loop(), on passe à 135ns pour la boucle.

... Bon c'est décidé, j'achète un OLS dés que "mon fournisseur" aura de nouveau du stock ...
Ras le bol de me trimbaler un oscilloscope hors d'usage et d'être obliger d'utiliser ma carte bus pirate en analyseur logique :stuck_out_tongue_closed_eyes:

68tjs:
@Artouste
Les suroscillations ne viennent pas forcément que des sondes : les pistes tarabiscotées, la qualité du plan de masse sur la carte et les horribles connecteurs pour empiler les cartes ont aussi leur part de responsabilité.
A vue de nez les temps de montée et de descente font 0,2 div soit en gros 100ns.
Je posais la question pour évaluer la bande passante des connexions nécessaire pour ne pas avachir les signaux. En appliquant la formule empirique Fmin = 1/(2.2*tm) on obtient 5 Mhz. Jusqu'à des longueurs de 10cm cela devrait passer sans trop de difficultés mais au delà paire torsadée obligatoire.
C'est vraiment une calamité que dans les implantations des cartes il n'y ait pas plus d'emplacement pour des reprise de masse.

oui , mais bon ce n'est pas ce que j'ai fais de mieux comme câblage :grin:
avec le code de barbudor et une liaison masse un peu plus courte

Donc on est plus proche des 10ns comme temps de montée et descente.
C'est plus raisonnable....