Quel est le rôle de la biblio arduino.h ?

Bonjour,

Je viens de pas mal ramer avec un programme incluant des fonctions, l'une permettant d'envoyer des données, l'autre permettant de les recevoir via un transceiver rf24l0+ et un nano.

Mon dispo est un répéteur permettant de collecter led données de deux sources éloignées différentes et de les rediriger vers un récepteur unique (rf24 + esp8266)

Tout paraissait simple, le répéteur captait sans problème, le récepteur aussi... mais pas ensemble.

J'ai semble-t-il résolu le problème en ajoutant la lib arduino.h que j'avais omis dans mes déclarations.

D'où enfin ma question : à quoi sert elle ? J'ai lu des explications deci dela sans avoir tout compris.

L'un d'entre vous peut il éclairer ma lanterne ?

Cordialement

J'ai semble-t-il résolu le problème en ajoutant la lib arduino.h que j'avais omis dans mes déclarations.

vous avez dû faire autre chose sinon ça n'aurait pas compilé...

Bonjour,

Oui c'est ce que je me suis dit après mes lectures sur les forums parlant de cette librairie. Mais je n'ai rien modifié, après des heures de galère ça a fonctionné et ça tourne bien depuis hier.

J'avoue m'y perdre un peu...

J'avais mis en cause la proximité du répéteur et du détecteur lors de la phase de test, j'ai joué sur les puissances des amplis du rf24, sur les tensions d'alim, sur les vitesses de transfert, bref j'ai "tout" essayé jusqu'à rajouter la lib en question.

Comme j'aime bien comprendre, je vais continuer à faire des tests.

J'ai encore une interrogation qui sort un peu du sujet :

Pour aérer un peu le contenu du boîtier, j'ai déporté dans un boîtier annexe le module rf24. J'ai utilisé pour cela un câble rj45 de 1 mètre environ et ça n'a pas été le bon plan, malgré une capa de 100 microns placėe directement sur le module et le blindage relié à la masse.

Le symptôme était le suivant : tout démarrait correctement et après une 15aine de boucles, l'arduino ne bouclait plus, la led L s,allumant mollement.

J'ai réduit la distance à 20 cm et tout fonctionne.

J'ai encore un bout de chemin à faire avant de maîtriser l'arduino (et le rf24)...

Merci des retours.

Cordialement

Il suffit de commenter cette ligne et voir s'il compile quand même...

Bien sûr ça compile, mais est-ce certain que le fait de compiler avec et sans signifie que la lib arduino.h ne joue aucun rôle ? C'est la question que je me pose. D'ailleurs, certains commentaires lus sur les forums laissent entendre que si on a des soucis, pas forcément de compilation l'ajout de la lib peut améliorer les choses.

Cordialement

Je serai surpris parce que tout ce qui est configuration standard est effectuée puisque le sketch principal importe (sans que vous le voyez) ce fichier

Bonjour,

je reste donc dans l'incompréhension, pourquoi ça marche, pourquoi ça ne marche pas...

Cela dit, depuis la soirée d'hier jusqu'a 10h56 ce matin, je récupérais toutes mes données (3 températures de la serre et température et poids de la ruche) à partir de 10h56 , la ruche a été invisible alors qu'un récepteur (rf24 + esp8266) situé au voisinage direct du répéteur continue à la voir et à envoyer les données à ThingSpeak.

En gros, mes récepteurs (basé sur rf24 + esp8266) fonctionnent sans problème

  • comme récepteur de données d'un seul site (ruche ou serre) depuis des semaines, voire des mois.
  • comme récepteur de données des deux sites en même temps, plus récemment, depuis un coup de main du forum arduino.

La même configuration à laquelle j'ai rajouté une fonction d'envoi merdouille. Donc j'en déduis que mon programme est mal bâti.

A toutse fins utiles, voici mes deux fonctions receiveinfo et sendinfo :

void receiveinfo() {
radio.startListening();
delay(200);
uint8_t pipe_num;
if (radio.available(&pipe_num)) { /* cet appel retourne vrai si on a des données
  et initialise pipe_num à la valeur de pipe qui a reçu des données*/
  Serial.println(pipe_num);
  if (pipe_num == pipeRuche) {
  radio.read(dataR, sizeof(dataR)); // lit les trames envoyees 
  delay(1000);
  Serial.println("Envoi des donnees de la ruche");
  tempRuche = (dataR[0]); // on enregistre la temperature ds la ruche
  poidsRuche = (dataR[1]); // on enregistre le poids de la ruche 
  delay(100);
  Serial.print("Poids de la ruche:");
  Serial.println(poidsRuche,2);
  Serial.print("temperature dans la ruche :");
  Serial.println(tempRuche,2);
   } else

  if (pipe_num == pipeSerre) {
     
  radio.read(dataS, sizeof(dataS)); // lit les trames envoyees 
  delay(1000);
  Serial.println("Envoi des donnees de la serre");
  tempSerre =  (dataS[0]); // on enregistre la temperature ds la serre
  tempBacext = (dataS[1]); // on enregistre la temperature ds le bac externe
  tempBacint = (dataS[2]); // on enregistre la temperature ds le bac interne 
  delay(100); 
  Serial.print("temperature dans la serre :");
  Serial.println(tempSerre,2);
  Serial.print("temperature dans le bac interne :");
  Serial.println(tempBacint,2);
  Serial.print("temperature dans le bac externe :");
  Serial.println(tempBacext,2);

  }
  
 }
      
}
void sendinfo() {
  radio.stopListening();
  delay(4);
  float dataT[6] = {dataS[0],dataS[1],dataS[2],dataR[0],dataR[1],tempRTC};
  if (flagtx == 0) { // transmission effective si flag == 0
     delay(4); 
     radio.write(dataT, sizeof(dataT));// envoi trame info
     Serial.println("envoi de la trame");
     delay(4); 
     flagtx = 1; // un envoi effectué
     delay(4);
     digitalWrite(ledTrame, HIGH);
     delay(4); 
      flagtx = 1; // un envoi effectué
     delay(200);
     digitalWrite(ledTrame, LOW);
     delay(200);
     digitalWrite(ledTrame, HIGH);
     delay(200);
     digitalWrite(ledTrame, LOW);
     delay(200);
     digitalWrite(ledTrame, HIGH);
     delay(200);
     digitalWrite(ledTrame, LOW);
     
  }
   
   }

Je virerais si j’étais vous tous les délais du code, ce n’est jamais une bonne idée dans la transmission de donnée de mettre des attentes synchrone.

OK je vais nettoyer...

Merci!

J-M-L: Je serai surpris parce que tout ce qui est configuration standard est effectuée puisque le sketch principal importe (sans que vous le voyez) ce fichier

pepe: Il n'est pas nécessaire s'y faire référence dans le fichier principal du programme (.ino), mais il doit être inclus dans les fichiers supplémentaires (.c, .cpp, .h), et notamment les bibliothèques, qui utilisent des fonctions, objets ou constantes Arduino.

Tout est dit dans ces deux extraits.

On se sait pas si le projet qui ne compile pas est mono fichier ou multi-fichiers.

Si c'est mono-fichier J-M-L a raison de dire que ce fichier est déjà inclu par l'IDE quand elle génère le vrai fichier, non plus ino [u]mais cpp[/u], transmis au compilateur. Si c'est multi-fichier pepe a raison, chaque fichier étant compilé séparément il faut que le compilateur ait été prévenu de tout ce qu'il va rencontrer.

Question : projet mono ou multi fichier ?

Bonsoir,

C'est un seul fichier donc il semble que l'introduction de la lib en question n'explique pas le fait que mon programme fonctionne actuellement

Je continue à explorer pour comprendre.

En fait rien n'est simple, j'ai deux émetteurs, le répéteur et le récepteur, chacun pouvant déconner sans compter l'electronique. Par exemple la disparition brutale des données de la ruche evoquée dans mon precedent post était simplement due å un arrêt de l'émetteur de la ruche.

Je laisse tourner 24h et ensuite je supprimerai l'inclusion de la lib arduino.h on verra bien si ça marche encore.

Cordialement

Nouvel épisode des "Mystère de la programmation " ? :grin:

la lib arduino.h

Non, pepe te l’a déjà dit ce n’est pas une bibliothèque.
C’est un fichier de définitions et de déclarations.
Tu peux le lire ici (sous Linux, le chemin sous Win$ devrait être identique) :
arduino-1.8.3/hardware/arduino/avr/cores/arduino/Arduino.h

Ce n’est pas parce qu’avec l’IDE il suffit d’inclure le fichier machin.h que pour autant la bibliothèque machin se limite à un fichier machin.h, il faut aussi le fichier machin.cpp.

Une bibliothèque c’est principalement un fichier **.cpp qui est généralement accompagné d’un fichier ***.h pour un coté pratique.
En effet l’IDE te le cache, et fait le travail pour toi, mais une fonction doit obligatoirement être déclarée avant d’être appelée dans le programme.
L’IDE ne fait le travail que pour le fichier en extension ***.ino, si tu utilises aussi des fichiers annexes **.cpp (et c’est le cas d’une bibliothèque) il faut faire ces déclarations à la main au début du fichier *.ino et c’est le rôle du fichier h (h provenant de “header” ou en-tête en français). Toutes les informations pour le compilateur sont rassemblées dans un fichier.

Comment cela fonctionne avec l’IDE ?
Quand l’IDE rencontre un fichier ***.h elle regarde :

Je ne garanti pas l’ordre mais seulement les chemins:

  • dans le répertoire : arduino-1.8.3/hardware/arduino/avr/libraries pour les bibliothèques dont arduino à la responsabilité.
  • dans le répertoire pour les tierces parties arduino-1.8.3/libraries
  • dans ton répertoire Arduino/libraries qui est le répertoire où sont enregistrés tous tes programmes personnels.

Le seul fait d’écrire #include<machin.h> en début de fichier ino fait que l’IDE part à la recherche du fichier machin.cpp dans les 3 répertoires.

Note : on peut aussi placer les fichiers h et cpp dans le répertoire du fichier .ino. Dans ce cas il ne faut plus écrire #include<machin.h>** mais #include**“machin.h”** pour dire au compilateur de ne rechercher que dans le répertoire en cours.

OK OK, je ne dirai plus lib arduino.h c'est promis, mais j'avais compris la différence. Pour le reste de l'explication bien utile comme rappel, j'avais lu tout ça mais les discussions ci-dessus ont éclairé ma lanterne sur le rôle de la lib, pardon sur le fichier de définition arduino.h

Merci du coup de main.

Edit : Je viens de rejeter un oeil sur le fichier arduino.h. dans le préambule il est présenté comme une bibliothèque, donc on peut s'y perdre entre lib ou pas lib non ?

Cela dit c'est vrai que c'est essentiellement un fichier de définitions et je vois mal comment sa présence ou son absence serait responsable du fonctionnement ou du dysfonctionnement de mon dispo.

Je vois ça demain en supprimant le fichier de mon sketch.

Cordialement

Cela dit c’est vrai que c’est essentiellement un fichier de définitions et je vois mal comment sa présence ou son absence serait responsable du fonctionnement ou du dysfonctionnement de mon dispo.

Oui et qui plus est si vous n’avez qu’un seul fichier .ino il est inclus pour vous automatiquement - Si vous regardez Dans le fichier main qui va être injecté dans votre .ino avant de compiler il a bien cet include, et comme arduino.h commence par

#ifndef Arduino_h
#define Arduino_h

votre include est purement et simplement ignoré

Bonsoir,

Confirmation, après suppression de l'include arduino.h tout fonctionne comme avant.

Donc déduction obligatoire même si un peu déplaisante pour moi, avant d'ajouter l'include, j'ai dû faire une autre modif qui a débloqué mon sketch.

Cordialement et encore merci pour les suggestions et conseils.

Ok merci de la confirmation... si ça se trouve c’était un fil mal enfoncé :)

Bonjour,

Je penche vers cette option. Dans ce dispo, j'ai choisi des fils électriques enfichables ce n'était pas forcément le bon plan. Dans le prochain dispo, je jouerai du fer à souder.

Cordialement

Dans le prochain dispo, je jouerai du fer à souder.

Je ne peux que "plussoyer".

Bonsoir,

Le bug est détecté et je n'en suis pas fier...

C'était la trop faible distance entre le répéteur et le récepteur qui était responsable du probleme lors de la phase de test. Je l'avais suspecté mais comme il y avait d'autres scories dans mon dispo, je n'ai pas eu de resultat convaincant, meme en jouant sur la puissance du rf24.

Après avoir contrôlé séparément le bon fonctionnement des divers dispos, j'ai éloigné suffisamment répéteur et récepteur et hop ça a fonctionné. J'ai rapproché et ça a buguė.

Donc problème résolu et merci à tous

Lacuzon: Bonsoir,

Le bug est détecté et je n'en suis pas fier...

C'était la trop faible distance entre le répéteur et le récepteur qui était responsable du probleme lors de la phase de test. Je l'avais suspecté mais comme il y avait d'autres scories dans mon dispo, je n'ai pas eu de resultat convaincant, meme en jouant sur la puissance du rf24.

Après avoir contrôlé séparément le bon fonctionnement des divers dispos, j'ai éloigné suffisamment répéteur et récepteur et hop ça a fonctionné. J'ai rapproché et ça a buguė.

Donc problème résolu et merci à tous

Bonsoir Lacuzon ... Les joies du deverminage en conception electronique :grin: