1

Salut,
J'ai fait un petit montage+programme arduino tout à l'heure qui, en gros, est une détection d'interrupteur (avec un pull down via une résistance de 10 kOhms #triclasse#) et un debounce logiciel de 50ms (exemple inspiré de https://www.arduino.cc/en/Tutorial/Debounce)
Ça fonctionne.

Sauf que le bouton en question est actionné par un mécanisme rapide et que le temps de masquage du debounce fait rapidement plafonner le programme. J'ai donc diminué le délai jusqu'à 2ms, et ça semble fonctionner très bien.
Évidemment je peux passer à des micro secondes pour diminuer encore le délai au delà de la milliseconde, mais ça vous semble raisonnable ?
J'ai cru comprendre qu'un condensateur pouvait être une bonne idée pour faire le debounce en hardware. Ce serait plus rapide ? En pratique il y en a justement un en série dans mon mécanisme juste après mon interrupteur, que j'ai pour l'instant shunté vu que je me suis branché avant, mais je peux évidemment me brancher après cheeky Je ne l'ai pas sous les yeux mais vu sa taille il doit avoir une capacité importante. C'est un inconvénient ou un avantage ?

Pour info, le mécanisme est un allumeur de voiture (delco)

PS : en pratique je n'ai pas vraiment besoin de faire mieux que ce que j'ai déjà car tout semble déjà fonctionner, mais je suis quand même curieux embarrassed

2

Le temps de réponse du debouncing hardware dépend de la valeur du condensateur. Le seul vrai intérêt par rapport à un debounce software, c'est que ça n'utilise pas de temps CPU, mais même sur les petits microcontrôleurs actuels c'est devenu négligeable. Je te recommande de garder une solution logicielle, c'est plus facile à régler.

50 ms, c'est vraiment long. En général j'utilise 20 ms, ce qui suffit pour 99% des cas à la louche. 2 ms par contre c'est vraiment court : à moins que le contact soit d'excellente qualité, tu risques d'avoir des rebonds de temps en temps (et potentiellement de plus en plus au fil du temps, avec l'usure du contact).

Attention si tu utilises ça dans une voiture à proximité de l'allumage : avec les courants induits, tu risques de te récupérer des parasites et de fausser le comptage, voire de cramer ton microcontrôleur dans le pire des cas.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

3

Zerosquare (./2) :
Le temps de réponse du debouncing hardware dépend de la valeur du condensateur.
OK, je regarderai demain, mais il fait environ 3cm de long et 8-10mm de diamètre, donc ça ne doit pas être tout petit grin (mais je ne connais pas l'année de production donc c'est peut-être un peu trompeur hehe)

Zerosquare (./2) :
Le seul vrai intérêt par rapport à un debounce software, c'est que ça n'utilise pas de temps CPU, mais même sur les petits microcontrôleurs actuels c'est devenu négligeable.
OK merci, donc pas spécialement intéressant en effet.

Zerosquare (./2) :
50 ms, c'est vraiment long. En général j'utilise 20 ms, ce qui suffit pour 99% des cas à la louche.
OK, merci.

Zerosquare (./2) :
2 ms par contre c'est vraiment court : à moins que le contact soit d'excellente qualité, tu risques d'avoir des rebonds de temps en temps (et potentiellement de plus en plus au fil du temps, avec l'usure du contact).
C'est juste pour un réglage au banc (j'actionne l'arbre primaire de l'allumeur avec une visseuse grin), et les contacts sont des vis platinées montées sur des ressorts à lamelles, le tout étant actionné par des cames. C'est donc le distributeur que je teste (je ne suis pas seulement à proximité de l'allumeur... hehe), mais c'est le primaire et de toute façon ce n'est connecté à rien d'autre que l'aduino, l'allumeur n'est même pas dans la voiture hehe

J'avais commencé à 50ms et mon calcul de compte tour fonctionnait jusque environ 80 t/min; quand j'ai compris d'où ça venait j'ai diminué graduellement le délai de débounce et j'ai pu mesurer les deux vitesses maxi de la visseuse qui semblent correspondre aux vitesses nominales indiquées sur l'étiquette — de mémoire, 380t/min mesurés pour 400 nominaux (à vide et arrondi ?), et même à 2ms ça avait l'air de fonctionner à peu près bien. C'est possible que ça saute un peu de temps en temps, mais à la rigueur ça ne serait même pas très grave vu que je compte moyenner un peu.
Je mettrai le délai maxi qui me permette de mesurer ma vitesse de rotation. De toutes façons je ne suis pas obligé d'aller très vite, l'essentiel étant que la vitesse de rotation sur un tour complet soit régulière.

4

C'est un détail, mais si tu calcules des moyennes, n'oublies pas de virer les valeurs extrêmes (des deux côtés), qui sont probablement aberrantes.

5

Oué, merci, je les afficherai toutes — de toute façon j'avais envie de voir les écarts de timing entre les cames hehe

6

Une beau graphe de distribution statistique !
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7

Oué voilà, je suis en train de finir le composant COM pilotant Excel, et tout ça via le port série trioui

Sérieusement, j'ai affiché les temps d'ouverture et fermeture des cames et ça semble précis, moins d'une milliseconde de différence entre les tours pour une vitesse à peu près constante de l'ordre de 180 t/min (moins d'un t/min de différence)

8

./6 -> voilà, je pensais à ça grin