Auteur Sujet: Une alimentation analogique de base et une proposition de structure de classes  (Lu 17688 fois)

Matou

  • Newbie
  • *
  • Messages: 9
    • Voir le profil
Ce code compile avec l'IDE Arduino chez moi (je suis sous Linux). Il y a peut-être des options de compilations différentes, je suis d'accord que la référence en avant, ce n'est pas bon.
Pour la liste chaînée, oui, la remplacer par un bon vieux tableau ne serait pas un problème, sa souplesse n'a rien d'indispensable.
Je ne fais pas d'allocation-libération dans le fonctionnement, seulement à l'init. Je suis d'accord que ce serait une mauvaise chose en général pour ce type de code.

Je vais donc revoir ces points. Je republierai l'ensemble, mais je ne sais pas quand, car j'ai en ce moment d'autres occupations que je ne devrais pas négliger, même pour un projet qui me passionne... La récréation ne doit pas être plus longue que les cours !

Matou

  • Newbie
  • *
  • Messages: 9
    • Voir le profil
Point important que je n'ai pas écrit dans ma réponse précédente : MERCI pour cette relecture, cela fait toujours du bien au code d'être relu par quelqu'un d'autre.

AmadeusHF

  • Full Member
  • ***
  • Messages: 205
    • Voir le profil
Pas de problème pour un coup d'oeil (quand je peux).

Gardez simplement en tete que les "réflexes" de la programmation moderne ne sont pas nécessairement les bons en programmation embarquée, qui plus est sur un CPU aussi limité que celui d'un Arduino.

L'informatique "actuelle" a une (très facheuse) tendance à être sur-consommatrice de ressources : je rencontre tous les jours de jeunes développeurs qui incriminent systématiquement le matériel lorsqu'un programme est "trop lent", sans même se demander si leur code est ne serais-ce qu'acceptable.

Un environnement contraint comme l'Arduino nous ramène quelques (bonnes dizaines) d'années en arrière de ce point de vue. La programmation Objet est, en ce qui me concerne, un "must have" par rapport à une approche structurée de 3ème génération (C,....) Mais il reste vrai que le coup en mémoire des VTABLES d'une hiérarchie d'objets coutent cher, à l'échelle des 2Ko de notre pauvre Atmega 328 ;)
Sébastien.
La perfection est un chemin, non un but...

Matou

  • Newbie
  • *
  • Messages: 9
    • Voir le profil
J'ai remplacé la liste chaînée par un tableau statique de 20 éléments. Il n'est même pas dimensionné dynamiquement.
Donc il y a environ 1500 octets de programme en moins, et les liens de la liste ne se créeront pas lors de l'initialisation.
J'ai supprimé les raisons des warnings (des const qui manquaient et un unsigned inutile)
J'ai renommé les méthodes update() en loop() dans les classes dérivées d'EntreeSortie, puisqu'elles sont appelées lors de l'appel à loop().
J'ai mis dans la méthode print_config') d'EntreesSorties (le fameux gestionnaire du tableau des EntreeSortie's) l'impression du nombre d'éléments. Comme cela, on peut écrire le programme, puis redimensionner à ce qui est nécessaire. De même, s'il est sous-dimensionné, on verra ce nombre apparaître avant le crash inévitable. Je n'ai pas mis de test de débordement, mais si c'était utile, ce serait facile.

Donc encore une fois merci pour les commentaires, c'est aussi le plaisir de partager.