Discussion :

[grizzli06]

Bonjour,

J'ai 2 versions différentes de l'Arduino IDE: la version "classique" 1.8.15 dans son répertoire ("E:\Programmes\Arduino"), et la nouvelle version 2.0 dans un autre répertoire qui lui est propre (E:\Programmes\Arduino 2").

Aujourd'hui, en lançant l'IDE 2.0 il m'a proposé la màj vers la 2.1.0 ce que j'ai fait sans soucis.

Mais après cette mise à jour 2.0 -> 2.1, il me dit que des màj des bibliothèques et des cartes sont disponibles.

Je voudrais savoir si l'IDE 2.1 dispose de ses propres bibliothèques et définition de cartes au sein de son propre répertoire, car je ne veux rien changer à mon environnement 1.8.15 qui me sert pour mes projets terminés (ou très avancés).

Merci !

[Jay M]

Les bibliothèques sont partagées entre les IDEs, donc si vous mettez à jour. Dans 2.0 vous avez mis à jour aussi celles utilisées par l’ancienne version de l’IDe (ce qui dans l’absolu est une bonne chose d’avoir toujours les bibliothèques à jour).

[grizzli06]

Arf, ça ne fait pas du tout mes affaires ça : car j'ai eu une incompatibilité par le passé entre les version 2 et la version 3 de la bibliothèque IRremote.

La version 3 ne détecte pas le même code lors de l'appui d'un (même) bouton d'une télécommande infrarouge, j'ai dû:

1-relire tous les codes émis par une télécommande pour savoir ce que la v3 détectait comme codes
2- me retaper tous mes contrôles dans mes programmes pour les adapter aux nouvelles valeurs détectées !

Il n'y a pas moyen de faire en sorte que l'IDE 2.x travaille avec ses propres versions de bibliothèques et de cartes ??

[Jay M]

IRRemote a été effectivement complètement réécrite de façon incompatible mais ce n’est généralement pas le cas.

Éventuellement mettez la bibliothèque dans votre projet pour figer la version - il faut ensuite utiliser des guillemets dans le #include au lieu des <>

[grizzli06]

Éventuellement mettez la bibliothèque dans votre projet pour figer la version

ça c'est facile: il suffit de la recopier dans le répertoire hébergeant le ".ino", c'est ça ?

il faut ensuite utiliser des guillemets dans le #include au lieu des <>

Veux-tu dire que dans le ".ino", il faut rempacer:

#include <IRremote.h>

par:
#include "IRremote.h"

pour indiquer au programme d'utiliser la version située dans son répertoire ?

[Bernard_68]

Information :
Avec l'EDI arduino toutes les bibliothèques sont centralisées donc les mises à jour sont communes à tous les projets.

Avec platformIO par défaut, les bibliothèques sont affectées à un seul projet.
Si on veut, il est possible de modifier ce réglage et de les rendre communes à tous les projets,

L'avantage de la configuration par défaut de PIO est de ne plus être gênés par les incompatibilités de version.
À l'ouverture d'un ancien projet, si on sait qu'il y a des risques d'incompatibilités, il doit être possible de refuser la mise à jour (cas jamais testé).

Autre solution avec l'EDI arduino :
Il est possible de placer manuellement les fichiers de bibliothèques dans le même répertoire que le fichier ino.
Tous les fichiers de la bibliothèque : les *.h sans oublier les *.cpp qui sont le cœur de la bibliothèque.

Il faut alors remplacer les lignes :
#include<truc.h> par #include"truc.h"
< > dit au compilateur d'aller chercher les fichiers dans le répertoire commun des bibliothèques.
" " dit au compilateur d'aller chercher les fichiers dans le répertoire courant.

[grizzli06]

Merci à tous les deux, cela me fait donc 2 solutions:

1.Adapter la syntaxe dans le ".ino" selon cette suggestion: #include<truc.h> par #include"truc.h"

2.Utiliser PlatformIO: je viens donc d'installer "VS Core" + "Python" + "PlatformIO".

Je suis bluffé par ce que semble permettre PlatformIO dont je n'avais jamais entendu parler ! je n'ai pas encore créé mon 1er projet avec, mais ça semble très puissant comparé à l'IDE Arduino 1.8.x

Et si comme tu expliques, cela permet de s'affranchir des problèmes de versions de bibliothèques, ça devient très intéressant pour moi ! je suis toujours traumatisé par le passage à IRRemote 3.X qui m'a mis un bazar innommable dans mes programmes développés à l'époque de IRRemote 2.x.

D'où ma question: mais que reste-t-il à l'IDE Arduino 2.x ???? je n'en vois plus l'intérêt si PlatformIO permet d'éliminer les problèmes de versions de bibliothèques, tout en étant (apparemment) plus puissant ?

Sauf si vous m'indiquez une bonne raison de conserver Arduino IDE 2.x, je vais le désinstaller, et ne conserver que l'IDe Arduino 1.8.x (mes projets en cours tournent dessus) et PlatformIO.

Merci

[Bernard_68]

"D'où ma question: mais que reste-t-il à l'IDE Arduino 2.x ????"

L'EDI Arduino est quand même plus simple d'usage.
Je suis quelqu'un qui vient du matériel, qui n'avait pas programmé avant la retraite.
Honnêtement, je dis que c'est grâce à l'EDI Wiring/Arduino que j'ai pu acquérir une expérience et faire un apprentissage "en douceur" des concepts de programmation sans lesquels je n'aurais pas pu utiliser platformIO en partant de zéro.

Mon avis très personnel : l'EDI Arduino est essentielle pour débuter, après la phase de début chacun fait comme il veut, mais je conseille de tenter l'expérience avec PIO et de comparer.

La solution de placer les fichiers des bibliothèques dans le répertoire courant est digne d'intérêt.
En fait, c'est, à mon avis, un excellant moyen pour démystifier ce terme de bibliothèque.
Une bibliothèque n'est rien d'autre qu'un emplacement connu du compilateur où des fichiers communs sont déposés.

C'est aussi la découverte de la programmation en fichiers séparés cpp et non ino.
Parce que le découpage en plusieurs fichiers ino n'est pas de la programmation en fichiers séparés. C'est juste de la cosmétique.

Au final, l'EDI arduino concatène tous les fichiers ino en un seul fichier ino.
Cet unique fichier ino l'EDI le transforme en un vrai fichier main.cpp.
C'est ce fichier main.cpp qui est transmis au compilateur.

Conséquence : une modification dans un seul des fichiers ino provoque la recompilation de l'ensemble du projet.
Alors qu'en programmation en fichiers séparés (un seul fichier ino et plusieurs fichiers h et cpp) seul le ou les fichiers modifiés seront recompilés.

[Jay M]

La version de l’IDE ne change pas la façon dont les bibliothèques sont gérées par Arduino. L’idée de centralisation se défend, d’une part par la place occupée sur le disque (pas besoin de dupliquer à chaque fois) et si un correctif est mis à disposition alors toutes les applications en bénéficient par simple reximpilation sans avoir à la copier 10 fois dans 19 répertoires différents.

C’est l’objectif de l’approche retenue par arduino et c’est super pour les débutants ou quand on ne veut pas se prendre la tête mais parfois quand des cow-boys détruisent la compatibilité des API d’une bibliothèque sans créer une nouvelle bibliothèque (le cas de IRRemote) alors ça met le bazar - mais c’est plus une exception que la norme. Et dans ce cas on fait comme avec PIO, on copie l’ancienne bibliothèque dans le projet et généralement ça règle l’affaire.

Ensuite PIO vs Arduino c’est une affaire de choix. PIO est plus riche mais n’a pas les «*petites roues*» qui aident les débutants.

Un article qui en parle (dans la langue de Shakespeare)

https://dronebotworkshop.com/platformio/

[Bernard_68]

Il n'y a pas d'EDI meilleure que l'autre.

Il y a une EDI plus adaptée à ses besoins et à son plaisir personnel, le plaisir est subjectif, mais ne l'oublions pas.

Note :
Par défaut (c'est modifiable), PIO fait une copie des bibliothèques dans chaque projet (à l'époque des terraoctets ce ne doit pas être gênant) mais les bibliothèques se téléchargent aussi à partir d'un gestionnaire.

Je n'ai jamais rencontré le cas où j'aurai eu besoin d'une ancienne version et donc je ne connais pas la procédure.

J'ajoute que dans l'univers arduino il n'y a pas que des conflits de version d'une même bibliothèque, il y a les gens-foutre qui utilisent un nom de bibliothèque déjà utilisé pour créer leur bibliothèque incompatible avec la ou les précédentes.
C'est plutôt pour ce point que j'approuve la configuration par défaut de PIO, tant pis pour les quelques kilo octets sur mon disque dur.

[grizzli06]

@JayM: merci beaucoup pour ces précisions que je comprends parfaitement ! J'ai juste été "traumatisé" par l'expérience IRRemote qui m'a fait perdre beaucoup de temps à l'époque... là j'ai la 3.3 mais je suppose que la 3.6 reste compatible avec mes développements 3.3....

@Bernard_68: je partage aussi car si PlatformIO est configuré par défaut pour éviter les problèmes en question en "figeant" la version de bibliothèques pour chaque projet (il faudra s'en assurer), ça me fait une sécurité très appréciable pour des projets "non personnels" où je devrai programmer des µC dans le temps...

Je vais donc tester PlatformIO ces jours-ci: je pense garder Arduino IDE 1.8.x pour mes petits projets basiques, et PlatformIO pour les projets plus complexes, du moins dans un 1er temps. Espérons que les "petites roues" qui manquent, signalées par JayM, ne me gênent pas.

Je vais probablement virer l'IDE Arduino 2.x, car les mises à jour centralisées présentent trop de risques dans mon cas (même si j'en comprends l'approche): hier j'ai mis à jour quelques bibliothèques en prenant soin de ne pas toucher à IRRemote avant de savoir, et depuis vos réponses je sais que j'ai bien fait.

Merci pour vos réponses, je passe en résolu, en espérant que les màj d'hier sur Arduino 2.x ne m'aient pas affecté mes programmes comme au temps infernal du passage d'IRRemote en 3.x...

Bravo pour votre expertise,

[f-leb]

Salut,

PlatformIO peut même gérer finement la version des librairies par projet qui respectent la sémantique <majeur.mineur.correctif> (ce qui est le cas en général). On peut accepter toute mise à jour, mais aussi verrouiller sur une version, ou accepter seulement les mises à jour mineures.

On débute en général sur l'EDI Arduino, et quand on découvre ses limites on commence à chercher ailleurs comme PlatformIO en surmontant progressivement les difficultés (interface un peu déroutante, fichiers de configuration à foison...)