Hello !
Merci pour le retour d'expérience. J'ai quelques remarques :
- Les nombres magiques mériteraient d'avoir leur définition dans le code, par exemple le timeout d'inactivité, la taille de ton tableau. Le code se lirait mieux.
- Les variables globales pourraient être locales à ta boucle.
Pour la détection du bouton rebond je trouve ton test astucieux, qui mériterait plus de commentaires, j'aurais pour ma part utilisé deux variables current et old, pour n'avoir qu'une instruction de lecture.
Pour le décalage des temps à voir si memmove peut aller plus vite , mais le parcours en sens inverse peut faire gagner un peu de temps.
Je pense que tu gagnerais à utiliser une puissance de 2 pour la taille de ton tableau, tu y gagnerais à la division pour le calcul de moyenne ( décalage de bits VS division, voir division non accélérée ). Je ne ferai même pas de test à 0 pour la somme, ainsi pas de test if et n=constante=8 => optimisation compilateur, ou explicite.
Pour l'utilisation d'une IT, cela permettrait d'être plus réactif, car tu peux perdre un tap dans ta boucle d'attente de 10 ms.
Plutôt que de faire appel à l'état retourné par milli, tu pourrais utiliser un compteur local de boucle puisque tu attends un délai fixe. Peut-être moins précis à la longue, car il faut tenir compte de la durée d'exécution de ta boucle.
Pour la mise en veille je suis plutôt d'accord avec la complexification, sauf si tu te contentes d'une mise en veille pendant ton délai d'attente, Ca fait déjà une grosse économie.
Pour le test de performances, un GBF à la place du bouton pourra faire l'affaire :).
cdlt.
# quelques commentaires.
Posté par Selso (site web personnel) . En réponse à la dépêche TapTempo pour Arduino Uno. Évalué à 1.
Hello !
Merci pour le retour d'expérience. J'ai quelques remarques :
- Les nombres magiques mériteraient d'avoir leur définition dans le code, par exemple le timeout d'inactivité, la taille de ton tableau. Le code se lirait mieux.
- Les variables globales pourraient être locales à ta boucle.
Pour la détection du bouton rebond je trouve ton test astucieux, qui mériterait plus de commentaires, j'aurais pour ma part utilisé deux variables current et old, pour n'avoir qu'une instruction de lecture.
Pour le décalage des temps à voir si memmove peut aller plus vite , mais le parcours en sens inverse peut faire gagner un peu de temps.
Je pense que tu gagnerais à utiliser une puissance de 2 pour la taille de ton tableau, tu y gagnerais à la division pour le calcul de moyenne ( décalage de bits VS division, voir division non accélérée ). Je ne ferai même pas de test à 0 pour la somme, ainsi pas de test if et n=constante=8 => optimisation compilateur, ou explicite.
Pour l'utilisation d'une IT, cela permettrait d'être plus réactif, car tu peux perdre un tap dans ta boucle d'attente de 10 ms.
Plutôt que de faire appel à l'état retourné par milli, tu pourrais utiliser un compteur local de boucle puisque tu attends un délai fixe. Peut-être moins précis à la longue, car il faut tenir compte de la durée d'exécution de ta boucle.
Pour la mise en veille je suis plutôt d'accord avec la complexification, sauf si tu te contentes d'une mise en veille pendant ton délai d'attente, Ca fait déjà une grosse économie.
Pour le test de performances, un GBF à la place du bouton pourra faire l'affaire :).
cdlt.