bravo - oui quand la place vient à manquer, aller faire un tour dans les bibliothèques et éliminer ce qui n'est pas pertinent pour son projet permet parfois de gagner pas mal de place.
Version imprimable
bravo - oui quand la place vient à manquer, aller faire un tour dans les bibliothèques et éliminer ce qui n'est pas pertinent pour son projet permet parfois de gagner pas mal de place.
Oui c'est nécessaire mais pas évident...
Les développeurs de bibliothèques sont visiblement tous passés sur des cartes puissantes (ESP32...), on le voit car les versions anciennes occupaient beaucoup moins de place en flash et en RAM.
Le pire c'est les fonctions de débug éparpillées partout (serial.print(), allumage de LEDs...) elles bouffent beaucoup de ressources, ça peut être utile certes mais il faudrait deux versions de bibliothèque :
- une débug pour apprendre
- une release pour la production
Pour IR Remote, il faut ouvrir tous les fichiers source avec NotePad++ sans oublier le fichier IRremoteBoardDefs.h qui est dans le sous-répertoire "private".
Ce n'était pas trop compliqué car heureusement, les fonctions sont relativement indépendantes.
J'en avais bavé avec Ethernet et W5100 car tout était fortement imbriqué.
Je suis quand même surpris que le compilateur ai autant de difficultés à éliminer les codes jamais appelés...
Est-ce les niveaux abstractions du c++ qui lui donne autant de mal ?
J'ai remarqué cette ligne :
Je l'ai retiré de ma version épurée sans effet, mais j'imagine qu'elle a un effet non négligeable quand on utilise la bibliothèque normale.Code:#pragma GCC diagnostic ignored "-Wunused-function"
Peut-on espérer une amélioration avec la nouvelle version de l'EDI Arduino (le "noyau" sera le même ou y aura-t-il un nouveau compilateur) ?
A bientôt
Cet épluchage de bibliothèque m'a fait remarqué quelque chose :
Un rapport cyclique de 30% permet probablement d'économiser le fonctionnement sur piles (mais il faut, c'est évident, désactiver les LED de débug)Code:#define IR_SEND_DUTY_CYCLE 30 // 30 saves power and is compatible to the old existing code
Mais cela peut impacter la portée de la télécommande.
Beaucoup d'acheteurs des modules infrarouge se plaignent de la faible portée de l'émetteur.
Mettre le rapport cyclique à 50 devrait augmenter la portée.
Ce qu'il faut savoir aussi, c'est qu'en alimentant la LED infrarouge avec l'Arduino on limite le courant à 40mA maximum ce qui est peu.
Habituellement, dans les télécommandes, on envoie beaucoup plus sachant que ce sont de petites impulsions que la LED infrarouge supporte (il ne faut surtout pas l'Arduino plante et alimente la LED en permanence)
Pour avoir une meilleure portée, il faut passer par un circuit de pilotage de LED infrarouge avec un petit monostable de sécurité (pour ne pas griller la LED en cas de plantage) suivit d'un transistor de commande alimentant la LED infrarouge via une résistance de faible valeur permettant des pointes de courant plus fortes. On peut aussi piloter plusieurs LED (pas mal de télécommandes ont deux LED).
Ces modules "grand public" ont été conçus pour ne pas griller même en étant maltraités par des électroniciens amateurs, pas pour avoir une grande portée. ;)
A bientôt
Tu es sûr que ces fonctions sont toujours présentes dans le code compilé ? Je pensais qu'il suffisait de jouer avec des #define ou les options de compilation pour qu'elles soient présentes ou non... Cette pratique semble répandue...
Ah ben t'es courageux. Avec le nouveau IDE (et aussi VSCODE ou Atmel Studio) tu peux naviguer dans la lib assez facilement : go to definition, reference, hover... Je ne sais pas si tu as cela avec NotePad++...
Sur Atmel Studio 7 on peut choisir des options d'optimisation, parfois cela me surprend il peut supprimer des lignes complète de code... Je pense qu'on doit aussi pouvoir faire cela avec l'IDE Arduino... A voir...