ma question existentielle du jour (après le menu de la cantine, faut pas pousser) ...
Je prépare une IÉM (interface élève-machine) volontairement rudimentaire à base d'un unique bouton et de la LED de la carte (ESP32-C3-Mini)
En entrée, je veux pouvoir, sans que ce soit bloquant pour les mesures, détecter un clic (0,1 s < t < 0,5 s) et un clic long ( t > 5s - la grosse différence est voulue pour éviter les erreurs de manip' )
En sortie, la LED doit :
être éteinte la plus part du temps
faire un éclat (~ 0,5s) unique à certains moments (déterminés par les mesures des capteurs) et/ou le clic
clignoter en continu rapidement (~10 Hz) (déterminé par un autre capteur)
J'ai bien compris que je pouvait trouver des bibliothèques pour aider à coder cela mais aussi que je peux faire ça en DIY.
En DIY, j'envisage l'utilisation de millis() et de plusieurs variables pour stocker les différents « tops » :
deux unsigned long pour appui et relâche du bouton (à renseigner avec une interruption)
un int pour les trois états de la LED
un (ou deux) unsigned long
Puis dans le loop() je teste en continu millis()avec les différentes variables.
J'ai déjà fait ça pour un bouton ou une LED (en tout ou rien) mais pas encore tout ça ensemble. Le code risque donc d'être un peu plus « sac de spaghettis ». Me connaissant, ce sera laborieux mais c'est peut-être à ma portée (sauf erreur de conception de ma part dans ce que j'ai évoqué plus haut)
Je sais aussi qu'il existe de multiples bibliothèques (OneButton et autres) pour gérer ça, boutons comme LED, mais, outre que je mets en balance le temps à y passer et le plaisir de faire moi-même, j'ai besoin de vos conseils :
les fonctionnalités que je n'utiliserai de ces bib risquent-elles d'être pénalisantes (vitesse, poids, autre...) ?
que penser de certaines bib. qui n'ont pas bougé depuis 3, 4, 5 ou 10 ans ? Vous fixez-vous une limite à l'archéologie ?
avez-vous des suggestions pour certaines bib. ou d'autres à éviter ?
Merci !!
(mis au bar puisque c'est plus pour la discussion que sur le code en lui-même)
En principe un bibliothèque est plutôt polyvalente car il faut qu'elle puisse être utilisée par le plus grand nombre de personnes. En conséquence il y a du code en trop pour une utilisation précise. Si j'ai besoin d'un bouton qui reconnait les triples clics, il faudra sans doute utiliser une bibliothèque qui cherchera aussi les simples clics et les doubles clics. Que de code qui est alors inutile!
Prenons l'exemple d'un bouton branchée sur l'entrée D2. Si on fait un programme général qui lit un bouton, on va mettre le numéro du bouton dans une variable. L'accès au bouton se fait alors généralement par digitalRead qui est assez lent et gourmand. Si on se passe de la bibliothèque et comme on sait que l'entrée est 2 et pas une autre, on peut alors utiliser digitalReadFast qui va beaucoup plus vite.
On ne peux pas toujours optimiser un code pour qu'il fasse à la fois moins d'octets et pour qu'il aille plus vite. Il y a un compromis à faire. Si tu veux aller vite, tu écriras un programme plus rapide qu'une bibliothèque standard, mais qui peut être plus gros. Si au contraire tu as plus de temps, tu peux privilégier un programme compact, qui sera plus petit que le standard.
Il y a des vieilles bibliothèques qui n'ont pas changées. Ce peut être parce qu'elles sont suffisamment simples pour ne pas avoir de bugs. J'ai écris un logiciel pour passer de la musique pour un atelier. Depuis je n'ai jamais constaté de bug ni de fonctionnalités manquantes. Il est assez simple et si j'en rajoutais, la personne qui l'utilise ne saurait pas forcément les utiliser. Je n'y touche plus, et pourtant c'est toujours d'actualité.
On ne peut donc pas généraliser.
Toutes les bibliothèques sont à éviter si on veut de la performance. Maintenant écrite une bibliothèque pour un usage précis est très long (mais formateur), bien plus que d'utiliser une toute faite qui convient à peu près.
En général, on ne fait soi même que ce qui n'existe pas.
Bien que pour ma part, il est des fois plus simple d'écrire mon code que d'essayer de faire fonctionner le code d'un autre.
Oui, c'est un risque.
Tu as aussi le risque, que la personne y est plus réfléchit que toi et donc à plus optimisé le code.
Si le gain de temps est important, la bonne question je pense serait de demander aux utilisateurs de ces librairies un retour par rapport à ton besoin.
Je suis d'ailleurs complétement d'accord avec @vileroi sur le fait d'avoir du code gelé.
Sur ce point particulier, je ne fixerais pas de limite.
Sinon complétement indépendant de l'utilisation d'une librairie de bouton, je pense que l'on peut apposer le tampon de @J-M-L sur les machines à état
Sinon personnellement je n'utilise pas de librairie, je trouve que le codage par soit même, ne nécessite pas un investissement en temps très important.
Par contre, J'utilise systématiquement un condensateur pour amortir les rebonds.
J'avais trés récemment fait un petit sketch pour mesurer le temps "ON" et le temps "OFF" d'un signal OW' généré par l'Arduino.
Sachant que la fréquence du PWM ést de 500 ou 1000Hz sur un UNO, je devais donc pouvoir mesurer de temps de l'ordre en utilisant micros().
J'entrais le signal PWM sur D2 à laquelle j'avais zttaché une interruption.
J'avais utilisé l'option "CHANGE" par ce qu'avec du rebond, "RISING" ou "FALLING", ça ne marche pas top.
Mais effectivement, une bonne capacité, ça devrait faire l'affaire.
Mon programme d'interruption tenait en quelques lignes, et j'arrivais à mesurer sans pobléme et de façons répétitives les temps que je voulait mesurer.
Alors â 10Hz au lieu de 500Hz, va devrai aller non?
