Discussion :

[cobra38]

Bonjour à Tous

Je sollicite votre aide car je me retrouve devant une énigme
j'ai dans mon programme, j'ai 3 sous-programmes :

1) mesure de distance à l'aide de 2 capteurs VL53L0X : read_dual_sensors()
2) mesure de tension batterie : do_vcc()
3) mesure de température et d'humidité : do_read_dht()

Constat :
- si j'active tous les sous-programmes , le programme se bloque (?)
- si je les active séparément tous fonctionnent
- si j'active (2) et (3) le programme fonctionne
- si j'active (1) et (2) le programme fonctionne
- si j'active (1) et (3) le programme se bloque

il semblerait que le blocage se situe à la lecture des lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
lox1.rangingTest(&measure1, false); // passez dans 'true' pour obtenir l'impression des données de débogage !
  lox2.rangingTest(&measure2, false); // passez dans 'true' pour obtenir l'impression des données de débogage !

y aurait-il un conflit entre le DHT22 et VL53L0X ?

merci par avance
pascal

[Guesset]

Bonjour,

Il y a des variables redéfinies. Par exemple valldr est définie comme variable entière globale puis, au sein de loop() comme bool ce qui est plus logique (c'est le cas de le dire). Elle devrait être déclarée en lmocal à loop() puisqu'elle n'est utilisée que là et réinitialisée avant usage.

valhumidite n'est jamais lue et reste à 0 : la partie en affectation est en commentaire dans do_read_dht() et plutôt que d'écrire :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 if (h>90){  // humidite Max
   valhumidite = 1;
   } else {
   valhumidite = 0;

Il est préférable d'écrire (après avoir déclaré valhumidite comme bool : valhumidite = h > 90;Dans les expressions logiques il est préférable d'utiliser || et && car, entre autres, cela permet au compilateur d'optimiser les branchements conditionnels : par exemple dans un && pas la peine de regarder la seconde expression si la première est fausse.

Dans do_read_dht(), isnan() est utilisé avec des entiers, il retournera toujours true. Par ailleurs faire la conversion d'un float en entier avant de savoir si c'est un nombre valide est un peu bizarre. Il faut déplacer les conversions après les tests isnan() et faire ces tests sur t et h et non sur tt et hh.

Il y a des variables qui mériteraient d'être passées en local : measure1, measure2...

Des variables ne sont pas utilisées : par exemple gReverseDirection

Je n'ai pas regardé la mécanique d'ensemble mais il y a déjà du travail.

Bon courage.

[cobra38]

Merci Guesset pour la réponse

En effet , il y a du boulot sur les variables
j'ai bien noté les incohérences et je vais donc modifier les variables concernées

néanmoins j'ai un peu progressé ce matin et j'ai repris le prg hors traitement des alarmes et je me suis aperçu
qu'il fonctionnait très bien ....( tout est relatif ..)
mais dès que je voulais y introduire le traitement des alarmes via Fastled
là le prg ne fonctionnait plus ....
et ceci contrairement à ce que j'avais annoncé dans le titre du sujet par erreur

hormis les problèmes liés aux variables, le problème principal ne viendrait-il pas de l'absence
d'une gestion des interruptions ?

pascal

[Guesset]

Bonjour,

Il y a un problème avec la bande de leds. Il y en a 3 de déclarées mais dans la boucle d'alarme on balaye certes de i = 0 à 2 mais on adresse également i + 3. Dans un vrai tableau ce serait un plantage assuré.

Salutations

[cobra38]

Oui en effet merci bien , j'ai corrigé mais mon problème reste en entier

Sur le Moniteur je lis :

Sans les lignes Fastled :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 //Init led strips
 // FastLED.addLeds<LED_TYPE, ALPIN, COLOR_ORDER>(leds, NUM_LEDS);
 // FastLED.setBrightness(  BRIGHTNESS );

**********************************************
Broches d'arrêt activées...
Les deux en mode de réinitialisation...(les broches à l'etat bas)
Départ...
Humidite: 32%
Temperature: 26C°
Panneau N°1 => Ouvert
Panneau N°2 => Ouvert
VCC = 4.60 Volts
BAT = 100 %
../..
**************************************************

donc çà marche

et en activant les lignes FastLed

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
//Init led strips
 FastLED.addLeds<LED_TYPE, ALPIN, COLOR_ORDER>(leds, NUM_LEDS);
 FastLED.setBrightness(  BRIGHTNESS );

*******************************************************
Broches d'arrêt activées...
Les deux en mode de réinitialisation...(les broches à l'etat bas)
Départ...
Broches d'arrêt activées...
Les deux en mode de réinitialisation...(les broches à l'etat bas)
Départ...
../..
******************************************************

çà boucle dans le SETUP ?? je ne comprends pas ...

pascal

[Guesset]

Bonjour,

Cela sent le reset vraisemblablement parce que l'alimentation n'est pas suffisante.

Les neopixels peuvent consommer jusqu'à 60 mA par unité soit 180 mA dans ce cas. Il faudrait faire un bilan de toutes les consommations des divers éléments (dht + 2*vl53L0X + Neopixels + Nano + LM385Z + TPL5110 + ...).

Dans le cas où ce serait limite mais pas dramatique, un bon découplage pourrait manger les pics courts de surconsommation (par exemple condensateur sur la ligne d'alimentation des Neopixels).

Il y a un truc bizarre également. La bande de Leds est déclarée sur la broche 4 donc réservée à un pilotage via fasled mais cette même broche est utilisée dans alormOFF directement par digitalWrite. Comme c'est la broche de protocole DataIn des LEDs cela n'aura aucun effet. De plus, un cycle d'alarme se terminant toujours par des leds éteintes, je doute qu'une tentative d'extinction sauvage soit justifiée. On retrouve ce même accès (mais direct sans variable) à la broche 4 dans read_dual_sensors, là encore en dehors de tout protocole. Donc, soit ce devrait être deux broches différentes, soit il faut supprimer les accès type digitalWrite à l'entrée DataIn des leds et les remplacer par une commande via fastled.

Bonne chance