Discussion :

[electroremy]

Bonjour,

Plus j'avance avec Arduino plus je me rend compte qu'il ne faut pas hésiter à "casser" les librairies pour les adapter à son projet.

Exemple ici https://www.developpez.net/forums/d2...-client-write/

L'embarqué, surtout sur petites cartes, n'a rien à voir avec la programmation sur PC

Sur PC, on a des librairies (DLL, API, ...) :
- dont on n'a pas accès au code, ce sont des "boites noires"
- qui sont partagées par plusieurs logiciels qui s'exécutent sur l'ordinateur
=> il faut donc "faire avec" les librairies

Sur Arduino c'est totalement l'inverse :
- on a accès au code des librairies, on peut les modifier
- l'Arduino n'est pas un ordinateur multitâches, il va seulement exécuter un seul projet .ino ; même si des librairies sont utilisées par plusieurs projets, elles ne le sont jamais en même temps par la même carte

Donc ce n'est pas grave d'avoir des librairies "incompatibles" d'un projet à l'autre, les projets ne s’exécutant jamais ensemble.

Ca revient d'ailleurs aux début de la programmation sur microcontrôleur en assembleur, où les outils ne permettaient pas de faire des #include, il fallait alors user du copier coller pour réutiliser des fonctions.

Modifier les librairies est intéressant mais demande du travail...

Les librairies sont fortement "intriquées" avec de nombreux fichiers qui font appel les uns aux autres, et quand on veut créer une version dérivée, pour ne pas avoir de confusion de dépendances, on a d'abord un travail fastidieux de recherche des fichiers utilisés, puis de copie et de renommage des fichiers, puis de renommage des classes, des #include et des déclarations de fonctions à faire, pour avoir une base de travail avant de pouvoir modifier quoi que ce soit.

=> Je me demande s'il n'est pas possible "d'automatiser" ce processus pour avoir, dans chaque projet Arduino, une copie "locale" de toutes les bibliothèques utilisées.

Le compilateur n'utiliserait uniquement que du code venant du dossier du projet.

Libre à moi ensuite de modifier ce que je souhaite.

A bientôt

[naute]

Bonjour electroremy .

=> Je me demande s'il n'est pas possible "d'automatiser" ce processus pour avoir, dans chaque projet Arduino, une copie "locale" de toutes les bibliothèques utilisées.

Je n'ai pas l'impression que ça soit possible au niveau du projet, car L'IDE Arduino ne gère pas, à ma connaissance, la notion de projet (première approche ), mais tu peux toujours avoir plusieurs versions personnalisées de l'IDE Arduino.

Alors bien sûr, si tous tes projets nécessitent une personnalisation différente, ça va faire beaucoup d'installations , mais si ce besoin est vraiment ponctuel, ça peut être une première solution.

Amicalement,
naute

[Jay M]

En dupliquant les Bibliothèques dans le répertoire du sketch et en les incluant avec des guillemets au lieu des <> vous travaillerez sur les versions locales.
Ce n'est pas automatique, mais ce n'est pas non plus super difficile, on a toujours un nombre relativement limité de bibliothèques au niveau d'un sketch

Bien sûr vous perdez le bénéfice des mises-à-jour mais ça peut aussi être l'objectif recherché.

[electroremy]

En dupliquant les Bibliothèques dans le répertoire du sketch et en les incluant avec des guillemets au lieu des <> vous travaillerez sur les versions locales.

C'est ce que j'ai essayé de faire au début mais j'ai eu des problèmes...

Il y avait toujours des conflits de nom quelque part

La difficulté est que de nombreuses bibliothèques font des #includes d'autres bibliothèques et parfois de façon "croisée"

Ce que je trouve dommage c'est que pour attirer des gens vers l'embarqué, les IDE propose de programmer "normalement comme sur un PC".
Si c'est bien au début, c'est vite pénalisant.
L'intérêt de l'embarqué c'est justement de pouvoir tout maitriser de A à Z sans être emprisonné dans X couche de modèle OSI et Y niveaux d'abstractions étanches...
Une grosse application sur un PC multitâche n'a rien à voir avec une application sur microcontrôleur
Quoique les derniers microcontrôleurs commencent à avoir des capacités proches d'un ordinateur - mais ces "monstres" ne doivent pas pénaliser le développement sur les petits micros...

J'ai totalement "éclaté" puis fusionné les biblitohèques autour de l'afficheur ILI9341 et je ne le regrette pas. Code bien plus compact et plus rapide, avec plus de fonctionnalités.

Je me rend compte que j'ai intérêt à faire la même chose avec tout ce qui tourne autour d'Ethernet.
Quand on épluche tout on se rend compte que les classes "de haut niveau" IpAdress, Ethernet, EthernetClient, EthernetServeur ne font finalement pas grand chose et qu'elles apportent lourdeurs et limitations...
On a presque meilleur temps de gérer directement les sockets, quitte à ajouter quelques petites fonctions.
Le W5500 met à disposition 32 ko de buffer (c'est 16 fois la quantité de RAM de l'Arduino UNO !) que l'on peut répartir dans 1 à 8 sockets.
Cela permet de faire vraiment ce qu'on veut, par exemple avoir un projet pouvant indifféremment recevoir des requêtes en tant que server et envoyer des requêtes en temps que client.
Surtout qu'un socket peut être libéré dès qu'on en a plus besoin, donc si les traitements sont rapides, les possibilités sont vraiement énormes
Par exemple, un serveur qui gère d'autres cartes configurées en "client", et qui en même temps va aller piocher lui-même des infos en tant que client sur Internet (heure, météo) ou depuis d'autres dispositifs (médiacenter Raspberry Pi, machin domotique...)

Alors certes gérer des sockets en direct c'est moins facile que d'avoir des belles classes "client" et "server" mais ça vaut le coup !

A bientôt

[naute]

Les bibliothèques sont là essentiellement pour faciliter l'accès aux matériels à ceux dont les compétences peuvent être insuffisantes ou pour optimiser les temps de développement. Elles sont d'un usage généraliste et donc ne sont pas forcément optimisée, et de plus elles fournissent des fonctionnalités qui peuvent être inutiles à un projet donné.
Il parait évident que quand on dispose du temps et des compétences nécessaires, le code résultant a de bonnes chances d'être à la fois plus compact et plus efficace.

On pourrait dire qu'elles ont dans un projet Arduino la même place que la plaque de prototypage. On se sert des bibliothèques et de la plaque de prototypage pour réaliser rapidement la maquette du projet et quand on passe au stade suivant, on optimise le code et on réalise le PCB du montage. Sauf erreur, Arduino a été conçu, à l'origine, plus pour faire du prototypage et de la formation que pour intégrer tel quel un dispositif abouti.

Ou pas ?

[Jay M]

oui, bcp de classes sont pour faire des trucs "simples" voir "simplistes" parfois... ça coûte cher de faire un truc optimisé, donc à moins qu'un passionné s'y mette, celle de Adafruit & Co sont un juste milieu entre fonctions / performance et coût de développement... pour vendre leur cartes

[electroremy]

C'est exactement ça

J'ai un peu le sentiment que la lourdeur et le manque d'optimisation des bibliothèques est aussi un argument pour dire "prenez donc la nouvelle carte qui vient de sortir, bien plus puissante"

C'est aussi plus facile de faire une lib moins optimisée et compatible avec un grand nombre de cartes

[Jay M]

cela dit dès que Adafruit et autres sortent une carte et la bibliothèque qui va avec, ils se font copier leur carte par les asiatiques et la majorité des ventes se fait sur ces cartes "clones"... Les cloneurs n'investissent aucune resource dans la partie logicielle... ça coûte cher des ingénieurs et donc ils ne peuvent pas non plus se permettre de faire un truc super approfondi. La communauté est là aussi pour cela si quelqu'un juge qu'on peut faire mieux. soit on propose des Pull Requests directement soit on écrit une autre bibliothèque.

[electroremy]

Entièrement d'accord...

C'est pour ça que j'ai acheté des Arduino UNO et des Shields Ethernet Arduino officiels et pas des clones.

En plus, on est sûr de la qualité.
Le développement est déjà assez difficile comme ça, si en plus on ajoute des problèmes matériels

Pour mes afficheurs TFT tactiles, je n'ai trouvé que de l'import chinois... avec de gros problèmes de qualité : plusieurs écrans défectueux, plusieurs reçus cassés... et parmi ceux qui marchent on voit que ça a été fabriqué à la va vite...

A bientôt