Reprise du message précédent :

Arrrgg... J'ai lu ça je ne sais plus où et l'ai pris pour argent comptant sans jamais prendre le temps de le vérifier: erreur inexcusable    
 
Je vais tester en virant le timer interrupt, le suspect n°1 des dysfonctionnement.
Je suis pratiquement certain que ça fonctionnera sans ce timer maudit.
Mais comme adapter mon code prend un certain temps et que j'ai plus important à faire (mettre à l'abri le bois de chauffage avant l'arrivée de la flotte) dans l'immédiat, je ne m'y collerai que ce soir.
 
Merci en tout cas pour cette info salvatrice    
 
 

J'ai pas vraiment lu (j'ai choppé une cochonnerie de gros rhume, du coup je suis pas en très bon état...), mais si seulement quelque mesures de temps en temps sont fausses ça me fait penser au vieux soucis "atomic access". En gros tu dois avoir une INT qui se déclenche parfois juste au moment de lire une valeur et du coup ça donne n'importe quoi. En effet une valeur c'est probablement >8 bits, donc le µC doit exécuter plusieurs instructions à la suite et si entre temps la valeur est modfiée... https://www.nongnu.org/avr-libc/use [...] tomic.html

Excellente explication qui correspond bien à ce que j'ai pu constater    

@rat de combat    
Je ne suis pas en état pour bien lire, mais en diagonale ça m'a l'air pas mal ton code.
Doit pas falloir grand chose pour que ça fonctionne correctement.

Autre chose: Les variables globales utilisées dans le main/loop et dans une INT doivent être déclarées "volatile". Et il faut faire gaffe avec le atomic access comme je disais.

Volatile est valable pour les variables sur 8 bits, au delà il faut utiliser la macro ATOMIC_BLOCK (en rajoutant #include <util/atomic.h> )

Non, tu mélanges deux choses.
 
volatile -> "cette variable peut changer de valeur à tout moment", toujours nécessaire
 
atomic -> "désactiver temporairement les INT pour éviter que la variable change en plein milieu de lecture". En principe uniquement nécessaire pour >8 bits mais en pratique il faudrait regarder ce que fait le compilateur, du moins si on fait lecture-écriture. Dans le doute un tel block ne fera pas de mal.

Va dire ça aux gars de chez arduino
 

 
https://www.arduino.cc/reference/en [...] /volatile/

Désolé mais je ne vois rien qui contredit ce que je disais. Ils disent bien

et en plus

A force de me prendre la tête sur un bout de code de mon Arduino, je bloque complètement.
Dans ce cas-là, bien souvent, il suffit d'expliquer le problème à quelqu'un d'autre Ca nous contraint à le percevoir différent au point que la solution nous paraisse subitement évidente  
C'est précisément ce qui vient de m'arriver en rédigeant ce qui suit, que je laisse pour info puisque j'ai déjà trouvé la solution.
_____________________
 
Mes déboires avec les interruptions venaient très vraisemblablement du traitement trop lourd assigné à l'une d'entre elle alors que son intervalle de déclenchement peut tomber à 12 ms.
Mon Arduino s'en trouvait saturé au point de faire n'importe quoi.
 
Je cherche comment optimiser le traitement en question, en en déportant la plus grosse partie hors du traitement de l'impulsion, dans la section qui envoie les données au serveur une fois par minute et que je vais nommer post-traitement pour le différencier du traitement de l'impulsion.
 
Les impulsions en question sont celles de l'anémomètre qui mesure la vitesse du vent.
Chaque impulsion représente 2,4 km/h.
La vitesse du vent vaut donc 2400 / intervalle en ms entre deux impulsions
 
12 ms correspondent à 200 km/h, une vitesse qui j'espère ne sera jamais atteinte ni même approchée, mais j'aime autant ne pas risquer de plafonner les mesures même si mon anémomètre s'envolera sans doute bien avant que le vent atteigne 200 km/s.
 
Chaque minute, je dois obtenir:
 - la vitesse moyenne
 - la vitesse maximale
 
Dans le code actuel, tous ces calculs sont effectués dans le traitement de chaque impulsion. Schématiquement, la vitesse ponctuelle du vent est calculée sur chaque impulsion, elle est additionnée à un double servant ultérieurement à calculer la moyenne pondérée et la vitesse maxi est mise à jour.
C'est beaucoup trop lourd.
 
J'étais donc parti pour que chaque impulsion se contente d'insérer la valeur de millis() dans un tableau.
Le post traitement se chargerait des calculs.
Celui de la vitesse moyenne serait très simple puisqu'il n'utiliserait que la première et la dernière valeur du tableau.
Celui de la vitesse maximale serait à peine plus compliqué puisqu'il parcourrait tout le tableau à la recherche du plus petit intervalle entre deux valeurs.
 
Le hic, c'est que tabler sur un intervalle de 12 ms pendant une minute implique un tableau de 5000 unsigned long et ca dépasse bien sûr la mémoire dédiée aux variables globales.
 
L'intervalle minimal (donnant la vitesse maximale) pourrait être calculé par le traitement des impulsions.
Mais comment calculer la moyenne?
_____________________
 
L'idée qui m'est venue en tapant ce qui précède:
 
Dans le traitement de l'impulsion:
 - mettre à jour une variable contenant l'intervalle mini.
 - stocker dans deux variables le premier et le dernier millis() de la série d'impulsions
 - incrémenter le nombre d'impulsions
 
Dans le post-traitement:
 - la vitesse maxi est calculée directement à partir de l'intervalle mini stocké
 - la vitesse moyenne est calculée à partir de l'intervalle moyen valant (dernier millis() - premier millis())/nb d'impulsions
 
Ca alourdit un poil le traitement de l'impulsion mais en restant à priori dans les clous de ce que peut gérer mon Mega 2560
Le post-traitement s'en trouve lui allégé.
 
Bon, il me reste à le coder pour vérifier que ça fonctionne mais je suis confiant.
Le temps qu'on peut perdre sur un petit bout de code quand même  

 
Ca dépend sur quoi on travaille
 
J'arrive après la bataille mais c'est contournable ta limite.
 
Si tu prends réellement une valeur toutes les minutes, tu peux calculer l'heure de chaque mesure à partir de son index dans le tableau. Dans ce cas, il faut juste un peu chiader l'attente entre deux mesures pour prendre en compte la durée du traitement (sinon tu attends 60s + le temps du traitement et tu as une dérive).
 
Sinon pour stocker les secondes sur 24 heures, tu as besoin de 17 bits (valeur max =  131 072). Le truc, c'est de les stocker en valeur relative et non pas absolue. Ca t'obligerait à ajouter une petite boucle qui viendrait mettre à jour tous ces temps à chaque nouvelle mesure pour qu'ils soient toujours relatif à maintenant.
 
Ensuite pour la pluie, tu peux aussi définir une valeur max, au pif-ô-mètre je dirais 15 bits, soit 10 mètres de pluie par minute
 
Ainsi sur 17 + 15 = 32 bits, tu stockes toute l'information dont tu as besoin et tes données tiennent en moins de 8 Ko. Dans ce cas tu utilises des int, et des opérateurs binaires pour affecter/extraire les valeurs qui vont bien (il suffit de faire des macros et ensuite c'est facile).
 
En ne stockant pas les temps, tu t'en sors avec 16 bits et tu peux même calculer tes données sur 48h

Effectivement, concernant le pluviomètre (la flotte), tu arrives après la bataille    
Le traitement de chaque impulsion se contente déjà d'incrémenter le nombre d'impulsions, un simple int qui suffit amplement.
Le post-traitement n'a qu'à multiplier ce nombre d'impulsions par la hauteur d'eau représentée par une impulsion.
 
Des trois impulsions devant être gérées par des interruptions, celle du pluviomètre est la seule qui est assez légère pour ne poser aucun problème.
 
C'est surtout celle de l'anémomètre qui mettait la pagaille, non seulement parce qu'elle se déclenche le plus souvent, mais aussi parce que son traitement était de loin le plus lourd.
C'est ce que je viens de détailler avant la solution qui m'est venue dans le même temps.

 
Mais tu calcules comment ta moyenne glissante sur 24h du coup ?
 

 
Je viens de lire rapidement. C'est effectivement la bonne logique de stocker de la donnée dans l'interruption et de la traiter plus tard (c'est un modèle producer/consumer en gros). Dans la partie consumer, tu commences par désactiver les interruptions, tu récupères tes données, tu réactives les interruptions, tu traites les données / fais ta vie. Si tu ne fais que copier des données dans la partie où tu désactives les interruptions, ça ne prendra que quelques cycles et tu ne perdras pas en précision.

Le calcul des moyennes glissantes sur 1h et 24h est confié au PC qui reçoit les données.
L'arduino se contente de lui envoyer la flotte par minute, en plus de gérer de son côté le cumul qui se remet à zéro avec un poussoir.
 
Pour l'instant, les données sont transmises via une requête http. La page en question calcule via des requêtes SQL les moyennes glissantes sur 1h et 2h, puis insère le tout dans la BDD.
 
A terme, l'envoi des données devrait se faire directement par une requête SQL et le calcul des moyennes par un trigger, afin notamment d'éviter les requêtes http.

C'est un peu l'arme nucléaire pour tuer une mouche ce système. Mais ça marche, c'est l'essentiel
 
Tu as besoin de laisser ton PC allumé 24h/24 pour d'autres raisons ?

Ce PC est celui qui fait office de serveur chez moi. Sa config est plus modeste que celui que j'utilise et que j’éteins ou mets en veille régulièrement.
Ce serveur doit tourner 24h/24 puisqu'il gère:
 - des caméras IP
 - serveur http qui ne sert pas qu'à l'Arduino
 - serveur MQTT (domotique/bidouillages honteux (tm))
 - client Bittorrent    
 
Si ce PC n'avait que l'Arduino à gérer, j'ajouterais une mémoire flash à l'Arduino pour qu'il puisse y stocker les données en attendant leur rapatriement ultérieur sur PC mais vu que ce dernier est toujours en marche, autant lui balancer les données directement.

Rhhhaaa... soit j'ai un bug tellement gros que je ne le vois pas, soit mon Arduino ne sait pas compter.
 
La ligne problématique est celle-ci:
 
windSpeed=2400*anemoNbImps/(msAnemoImps[1]-msAnemoImps[0]);
 
Que l'on peut simplifier en:
a = 2400 * b / c
 
avec b = 239
et c = 59282
a = 72449.0    
 
La formule équivaut à celle-ci:
 
a = 2400 / c * b
 
mais avec les mêmes valeurs de b et c, a vaut cette fois 0.0    
 
b et c sont des unsigned long.
a est un float mais même passé en double, j'obtiens les mêmes résultats aberrants    
 
Devrais-je farcir la formule de casts?
 
EDIT: Ah oui, avec plein de casts en float, j'ai enfin le résultat attendu  

Ca craint la chaleur un ESP32 (ou Arduino) ?
J'ai l'impression que l'un des mien est HS (je m'en suis servi comme "support" pour souder mon nouveau PCB donc probablement transmission de chaleur via les PIN), il n'est pas reconnu par Windows.

Tout composant électronique ne supporte la chaleur que dans une mesure qui lui est propre, et les circuits intégrés ne sont pas généralement les plus résistants de ce point de vue.
Une telle coïncidence serait surprenante donc je pense que ça sent le roussi hélas    

C'est pas méchant, c'est pas bien cher et j'ai un ESP32 en rab donc je suis pas bloqué pour avancer.

Oui m'enfin faut quand même y faire gaffe, avec la pandémie les esp32, stm32 et autres petites bidouilles avaient triplé de prix et /ou n'était plus en stock null part (coucou les contrôleurs de vol de drone passés de 15 à 70€ !)

Mais bon d'habitude ya un shield en métal sur les ESP32 et puis ça ne crève pas comme ça non plus, tu ne l'aurais pas physiquement abimé ?

Je n'ai pas vérifié s'il fonctionnait avant de souder avec.
 
Je l'ai rebranché ce matin, il a été reconnu par Windows (c'était pas le cas hier soir) et j'ai pu flasher un programme dessus mais là, il est de nouveau plus reconnu par Windows.

Ça sent le port USB foireux ça, essaye un autre cable/port/pc...

J'en doute, le câble/port USB marchent bien avec un autre ESP32.

Le quartz de la puce USB série qui a pris un coup de chaud?

Aucune idée mais j'ai quand même bien avancé ce WE :
- soudage de la plaque de prototypage avec les différents éléments (exactement comme le détecteur d'ouverture de porte de garage mais sans la LED rouge)
- perçage du boitier en plastique qui accueille l'ESP32
- adaptation du code (encore celui du détecteur d'ouverture de porte de garage), pas parfait mais ça fait le job
- petite update de la doc avec un schéma pour expliquer où se trouve l'ensemble des câbles/composants

 
J'ai un peu hésité à ajouter un buzzer pour signaler la réception d'un courrier/colis mais l'ESP étant à la cave, ça n'a pas vraiment d'intérêt.
 
Donc globalement, il ne reste plus qu'à passer le câble sous les pavés au niveau de la porte. Je vais tâcher de le faire avant qu'il fasse trop froid.

J'ai enfin réussi à gérer correctement mon anémomètre (qui convertit la vitesse du vent en impulsions) avec des interruptions.
Il aura notamment fallu alléger à mort le code des interruptions.
Autant c'était facile pour les deux autres capteurs mais pour celui-ci, j'en ai bavé.
 
Finalement, je procède en trois temps:
 - L'interruption qui se contente de stocker la valeur de millis()) dans un tableau en incrémentant son indice.
 - en vrac dans loop() pour vider le tableau en traitant ses valeurs
 - dans le bloc de loop() qui s'exécute à un intervalle d'une minute, qui finalise les calculs et balance les résultat au serveur.
 
A cause de ce tableau, la mémoire disponible pour les variables globales est maintenant squattée à 57% et mon code est une usine à gaz.
 
Je n'ai pas encore pu le tester à fond parce que le vent est particulièrement poussif aujourd'hui. Je ne saurais que demain si mon code ne fait pas fondre l'Arduino vu la météo prévue.
 
Le bénéfice des interruptions est déjà flagrant sur la puissance active consommée, dont la courbe n'est plus constellée d'impulsions manquées    
Un exemple avec mon chauffe-eau sur programmateur, dont la courbe est jaune pisse, sans interruption puis avec:
 

Pas moyen d'arriver à des interruptions qui fonctionnent nickel    
 
Sans ATOMIC_BLOCK dans loop(), ce dernier est perturbé par les interruptions.
Avec des ATOMIC_BLOCK, ce sont les interruptions qui sont perturbées, notamment celle utilisée par millis().
 
N'existerait-il pas un Arduino, EPS-32 ou truc du genre mais multicoeurs, capable d'exécuter au moins une thread en parallèle du code principal?

Ta mis toute ta fonction loop dans un atomic_block ?
il faut mettre uniquement l'accés aux variable partagées le temps de les copier dans d'autres variables.

Je ne suis pas bourrin à ce point    

C'est ce que j'ai fait et ça suffit apparemment à mettre la pagaille    
J'avais lu je ne sais plus où que milis() ne fonctionne pas dans une interruption, et c'est peut-être vrai finalement    

Le code relatif à mes deux interruptions, sachant que l'intervalle des impulsions du pluviomètre est grand, au moins d'une dizaine de secondes, et celui du Linky est à peine plus court, de 1,4 secondes quand le chauffe-eau s'ajoute  tout ce qui tourne déjà:

tu peux virer l'atomic block et tenter ce genre de chose ?
 

 
(idem plus bas)
 
sinon il y a bien un delay systématique à la fin de ta boucle ?

 
Le test est lancé. Verdict d'ici quelques heures.
 

Non, aucun delay() directement dans loop() notamment parce que les impulsions de l'anémomètre y sont gérées directement sans interruption, parce que c'était la plus problématique à cause de ses impulsions trop rapprochées (24 ms pour 100 km/h). Lui ne passera sur interruption que si les deux interruptions actuelles fonctionnent nickel, ce qui était loin d'être le cas jusqu'ici.
J'ai même désactivé la mesure de la pression parce que lui nécessitait deux delay().
Des delay() se produisent toujours mais beaucoup plus sporadiquement dans des fonctions appelées par loop(): requêtes NTP, si problème de communication avec le LIDAR, si besoin de reconnecter l'ethernet,...
 
Nb: Je ne vois pas d'objection à poster l'intégralité de mon code mais vu qu'il compte 931 lignes et est toujours aussi illisible, ce serait passablement lourdingue.

Si je peux me permettre, il faudrait justement éviter des calculs (surtout avec des float) dans la partie sans interrupt.
Ex de

passer à

Nb : ici j'ai considéré que les 3 valeurs étaient accédé en écriture dans le traitement de l'interruption, il faut bien entendu se limiter aux variables nécessaires.

Merci encore    
Mais le cas de linkyNbImps me turlupine    
C'est une variable utilisée et modifiée par l'interruption.
Selon moi, sa remise à zéro devrait être dans le bloc sans interruption pour éviter les changements croisés de sa valeur.
Autrement dit, le code ne devrait-il pas plutôt être celui-ci?

 
Oups, plutôt ça:
 

Oui toutafait

Edit ligne 13 ya une erreur sur la variable
mettre lastmsImpLinkyTemp au lieu de lastmsImpLinky

 
Il faut éviter quelque chose de long mais deux casts, une multiplication et une division, c'est rien du tout.
 
Après sur le principe tu as raison.

C'est pas gagné    
 

tu peux mettre ton code sur un dépôt github qu'on puisse regarder s'il n'y a pas un autre souci ?

edit: aussi pour la donnée qui est erronée, affiche à chaque fois linkyNbImpsTemp et intervmsLinky qu'on sache laquelle à un problème

Mon code est sur Github mais je préfère ne vous donner le lien que dans quelques heures.
J'ai en effet un doute sur l'instant où est apparue la valeur fantaisiste. Elle pourrait être antérieure à la dernière version du code, d'où l'intérêt de le laisser pédaler quelques heures pour voir si le bug revient à la charge avec plus de détails dans le log.
 

Le bug est toujours présent hélas:
 
13:48:25.249 -> 448W   linkyNbImpsTemp = 1   intervmsLinky = 8027
13:48:33.279 -> 447W   linkyNbImpsTemp = 1   intervmsLinky = 8052
13:48:41.199 -> 454W   linkyNbImpsTemp = 1   intervmsLinky = 7927
13:48:48.239 -> 11283W   linkyNbImpsTemp = 22   intervmsLinky = 7019  <= WTF
13:48:58.129 -> 3630W   linkyNbImpsTemp = 10   intervmsLinky = 9915    <=  
13:49:16.250 -> 397W   linkyNbImpsTemp = 1   intervmsLinky = 9060
13:49:25.369 -> 395W   linkyNbImpsTemp = 1   intervmsLinky = 9106
 
Si vous avez les nerfs assez solide pour affronter mon code hideux:
 
https://github.com/LermiteFR/Weathe [...] gged_Linky
 
C'est la première fois que j'utilise Github pour publier du code donc si ce lien ne fonctionne pas, n'hésitez pas à râler.