(deleted)
Postez le code complet - ma boule de cristal me dit que vous dépassez la taille du tableau dans votre boucle for.. (comment est défini listeImpuls) ?
Bonjour,
Tu es vraiment sur que c'est cette version du programme qui s'exécute?
Il faudrait avoir le programme entier, mais à priori, il n'y a aucune raison que ça cause un problème.
(deleted)
Tu es sur que oscillo() n'est pas exécuté dans une interruption?
Dans une interruption millis() n'avance pas.
J’ai pas lu en détail mais vous utilisez Wire. Un point à explorer : Il me semble que le handler passé à Wire.onReceive est exécuté dans le contexte de l’ISR I2C... donc d’une part il est bon que le handler soit très court et d’autre part comme vous êtes dans le contexte d’une interruption, vous avez les interruptions bloquées —> millis() ne se met pas à jour et les Serial.print - si vous ne remplissez pas les 64 octets - seront bufferisés jusqu’à la fin de l’ISR et ne s’imprimeront que plus tard. Si vous envoyez plus de 64 octets votre code sera bloqué car print est bloquant.
(deleted)
Bonjour
Effectivement je confirme : receiveEvent est déclenchée par une interruption. Le corps de cette fonction doit être limité au strict minimum = transférer les octets reçus vers des variables globales pour traitement ultérieur dans le loop().
Et c'est encore plus vrai avec le requestEvent, car celui-ci intervient alors que la communication sur le bus I2C est en cours (le maître du bus a demandé des octets, il est en train d'attendre).
Alors que le receiveEvent est déclenché après la fin de communication sur le bus I2C, une fois que les octets reçus ont été chargés dans un buffer interne à la bibliothèque Wire et qu'un ACK a été retourné au maître.
C'est vraiment le genre de fonctions dans lesquelles il ne faut surtout pas coller le moindre Serial.print().