[résolu]Modification d'une librairie

Bonjour

Je dispose d'une librairie pour utiliser mon capteur de pH (Gravity__Analog_pH_Sensor_Meter_Kit_V2_SKU_SEN0161-V2-DFRobot).
Pour accéder au module d'étalonnage de la sonde, je dois saisir dans le moniteur série des commandes.
J'aimerais pouvoir modifier le texte qui s'affiche lors de l'étalonnage : comme ce texte ne figure pas dans le programme proposé sur la documentation, j'imagine qu'il est disponible dans la librairie du capteur.
D'où ma question : est-il possible de modifier une librairie ? Et si oui, avec quel(s) outil(s) ?

Merci d'avance

Vous avez tout le code source de la librairie sur github. Vous avez du l’installer

Si vous allez voir le code source (dans vos librairies) vous l’éditez avec n’importe quel éditeur de texte (y compris celui de l’IDE) qui ne modifie pas le format texte (ie ne sauvez pas en fichier word :slight_smile: ) et par exemple dans cette partie:

case 1:
        enterCalibrationFlag = 1;
        phCalibrationFinish  = 0;
        Serial.println();
        Serial.println(F(">>>Enter PH Calibration Mode<<<"));
        Serial.println(F(">>>Please put the probe into the 4.0 or 7.0 standard buffer solution<<<"));
        Serial.println();
        break;

vous n’avez qu’à changer le texte dans les Serial.println()

Idem ailleurs dans le code de la librairie.

Vous sauvez ensuite le fichier et la prochaine fois que vous compilez ça prendra en compte vos modifications

Oui
Avec quel outil ?

Une bibliothèque ce n'est que des fichiers d'extension h et cpp.
Il faut les ouvrir et les modifier.

N'importe quel éditeur de fichier sait le faire.
Il est probable que tu sois sous Win—machin, notepad peut le faire mais bien moins que Notepad ++ qui possède la coloration syntaxique et que tu as intérêt a télécharger, il est gratuit.
Sous Linux tous les éditeurs sont bons.

Bonjour,

68tjs:
Notepad ++ qui possède la coloration syntaxique

et une option "Langage" "Arduino"

Cordialement,
bidouilleelec

Il serait sage de modifier le nom de la librairie parce qu'à la prochaine mise à jour de la librairie les fichiers risquent d'être écrasés.

@fdufnews:
+1 (ils ne risquent pas: si la mise à jour fonctionne, ils seront éscrabouillés)

Quel est la priorité pour l’IDE : les bibliothèques qui sont dans le cœur de l’IDE où les bibliothèques qui sont dans le sous répertoire de l’utilisateur (répertoire .arduino15 pour Linux) ?

Si on écrit #include l’IDE va chercher les fichiers de la bibliothèque dans ses répertoires prédéfinis (dont .arduino15) et si on écrit #include “xxxxxxxx” il faut placer les fichiers de la “bibliothèques” dans le même répertoire que le fichier ino. C’est comme si on faisait de la compilation en plusieurs fichiers et là il n’y a plus de problème.

C’est au choix de l’utilisateur : sans renommer, avoir deux versions de bibliothèques à deux endroits différents c’est un peu casse-figure, quoique dans ce cas c’est juste des dialogues qui changent, s’il se retrouve en anglais au lieu du français le programme fonctionnera quand même.

Renommer une bibliothèque si on veut le faire dans les règles de l’art demande de faire attention. Pour être assuré de ne pas avoir de collision il faut renommer le nom des fichiers et aussi celui de la classe.

@ bidouilleelec

dans le #3 tu dis si je comprends bien qu'il y a une option coloration propre à Arduino dans Notepad++ mais je ne la trouve pas.

j'ai regardé dans les langages mais je ne vois pas

Bonjour,

Personnellement j'ai ajouté les fichiers ino:
Menu Paramétrage
Configuration de couleur syntaxique...
Sélection C++ dans la liste de gauche
Ajouter ino dans Ext utilisateur

Bonjour

Merci pour vos réponses, j'ai réussi à modifier mon fichier dans la librairie : je verrai bien s'il est impacté lors d'une éventuelle mise à jour.

il sera impacté, c'est sûr, mais vous n'êtes pas obligé de faire la màj de celui là :slight_smile:
(faites un backup de vos changements, juste au cas où...)

Est ce sûr, qu'il sera impacté?
a) Dans les exemples de cette librairie, elle est "appelée" par :

#include "DFRobot_PH.h"
#include "DFRobot_EC.h"
Si j'ai bien compris, les fichiers d'en tete -et les cpp correspondant- doivent être dans le même répertoire que le fichier de projet : je vois mal comment une mise à jour peut les affecter-

b)il n'a pas été mis à jour depuis 10 mois, sans doute parce qu'elle donne satisfaction : on peut espèrer, si je me suis trompé sur le point a) que DFRobot a une politique conservatrice en matière de mise à jour.

Point a = je suis d’accord tant que l’on utilise include “xxxx” et non pas include
Point b = autant jouer au Loto, plus la dernière mise à jour est ancienne, plus la date de la suivante est imminente.

Vous faites une analyse monovariée:

  • l'audience de ce circuit est assez faible: l'ajout de nouvelles fonctionnalités est peu probable.... pas de demande.
  • en 10 mois, ils n'ont pas détecté de bugs -et ils en font rarement-.
  • DFR robots est moins connu que lady Ada, mais fait des mises à jour régulièrement s'il y a lieu (une source de non mise à jour est le découragement d'un individu : on n'est pas dans ce cas) .

La probabilité d'une mise à jour dépend donc de :
la politique de la maison
la detection de bugs
la fréquence des demandes d'amélioration et de celle d'apparition de nouveaux circuits (cas des écrans TFTs, qui sortent à une cadence infernale), mais

en aucun cas du
passé (ex: si j'ai eu 50 tirages sans "6" aux dés, aucun dieu n'augmentera la probabilité que j'ai un 6 au tirage suivant... si je garde les mêmes dés.).

Mon point b) est à moitié valable: DFR robot a une politique à moitié conservatrice (ne met à jour que s'il y a une demande)
Mais je suis bien content que le point a) soit validé (le point b ne faisant que le renforcer)

bof …

En tous cas, le raisonnement ", plus la dernière mise à jour est ancienne, plus la date de la suivante est imminente." a les mêmes fondements "logiques" que
"j'ai tout perdu aux dés, mais le sort prendra conscience de sa méchanceté et me renflouera"
(il me semble préférable de comprendre pourquoi une mise à jour est ancienne (pas de bug; lassitude du développeur; attente d'une mise à jour : ce ne sont pas les mêmes conduites à tenir) pour faire un pari moins stupide que la mise à jour est imminente)

Statistiquement parlant si on sait qu’une mise à jour arrivera un jour de manière certaine ou si on modélise une file d’attente avec des événements se produisant avec une loi statistique, c’est pas la même chose que ne pas avoir cette information

DFRobot a plus de 200 projets dans github et il ont tous une mise à jour de temps en temps...

Mais bon c’est un débat un peu stérile - le point c’est que si vous déclenchez une màj depuis l’IDE ça remplace l’ancienne et donc ça écrasera les modify. Il faut donc conserver le boulot de localisation ailleurs

“le point c’est que si vous déclenchez une màj depuis l’IDE ça remplace l’ancienne et donc ça écrasera les modify”

A condition que la librairie soit dans le $INCLUDE_PATH: alors là, elle serait invoquée par
#include <librairie.h>
Or, les exemples donnent
#include “librairie.h”

Sauf astuce (symlink) que personne n’osera, la librairie aura tous ses fichiers dans le reprtoire de projet … et sera protégée desz mises à jour.

“Statistiquement parlant si on sait qu’une mise à jour arrivera un jour de manière certaine ou si on modélise une file d’attente avec des événements se produisant avec une loi statistique, c’est pas la même chose que ne pas avoir cette information”

Peut être pas UNE file d’attente avec UNE loi statistique, mais trois files d’attentes:
a) celles des logiciels dont le développeur s’est lassé (DFR Robot n’a pas l’air de se lasser
b) celles qui ont tout plein de défauts de jeunesse (cas des ecrans TFT) ou de demandes d’amélioration.
c) celles qui n’ont pas de bugs et presque parfaites…

Oui bien sûr si vous avez mis votre copie de la librairie dans un endroit « non standard » et qu'il a priorité dans le chemin d'inclusion, ça fonctionne.

Mais vous ne bénéficiez pas des bug fix quand la librairie sera modifiée.

(ça reste une "file d'attente" avec des évènements générés avec une probabilité différente en fonction de la maturité.. Mais bon comme dit plus haut, ça n'a pas grand intérêt, ce qui compte c'est de ne pas perdre le boulot effectué "bêtement" parce qu'on aurait gardé la librairie modifiée dans le répertoire standard et sans back-up).

Les examples de son phmètre ne peuvent pas fonctionner dans un endroit "standard" tels quels.

Et s'interroger sur les causes de la variabilité des mises à jour dans github est interessant en soi : des défauts de jeunesse/maladies infantiles pour les TFT -vaut mieux attendre avant d'acheter,pour avoir des librairies bien stables- , une maturité avec des mises à jour peu fréquentes.