Bibliothèque Accessories et Expander SX1509

[golgoth1009]

Bonjour,
Pour mon réseau analogique, j'utilise un arduino mega avec la bibliothèque Accessories.
J'ai besoin d'ajouter un expander SX1509. Il faut donc apporter des modifications à Accessories pour pouvoir prendre en compte ce type d'expander.
Je voudrais avoir votre avis.
Je comptais rajouter une classe PortExpander qui gérerais les instances vers la bibliothèque fournit par SparkFun pour cet expander et qui permettrai aussi d'intégrer d'autres expanders.
Des modifications sont aussi nécessaires dans la classe Port rediriger vers l'expander si besoin.
Pour éviter de modifier toutes les classes héritant de Port, je comptais rajouter un beginExpander dansla classe Port à appeler avant le begin du port pour préciser si l'accessoire est connecté via l'expander.
Quand pensez-vous ?

[Thierry]

Oui, c'est une bonne idée. Elle trottait déjà  dans ma tête depuis un certain temps.
Mon idée initiale était de changer le nommage des pins pour y inclure un numéro d'expandeur. Ainsi il y aurait une classe Expander, dérivée en ExpanderInput, ExpanderOutput et ExpanderPWM, ou avec seulement un type. Chaque expander aurait un numéro entre 1 et 99 (ça devrait suffire, sinon il faut pousser à un peu plus...) et au moment de déclarer un port avec une broche, fusionner le numéro d'expander et celui de sa broche. En gros au lieu de dire pushButton.begin(10) pour la broche 10, on dirait pushButton.begin(1208) pour la broche 8 de l'expander 12... La classe expander permettrait aussi de typer la communication avec lui selon son mode propre : un expandeur 74HC595 n'a pas le même mode de fonctionnement qu'un PCA9685 qui tourne en I²C . Il faudrait que chaque expander ait ses propres fonctions digitalRead et digitalWrite, analogRead/analogWrite et peut être aussi PWMWrite... Bref, c'est du boulot, mais c'est une proposition à creuser.

[golgoth1009]

Bonjour,
Je vais essayer d'implémenter ces modifications durant ce mois et je posterai mes propositions.
J'hésite sur la numérotation (soit inclure l'expander dans la numérotation ou raoujter un flag précisant qu'il faut passer par la classe Expander).

[Thierry]

L'avantage de cette méthode de 'multiplexage' des numéros c'est qu'il n'est pas besoin de modifier toutes les fonctions qui acceptent une broche, en tout cas pas l'interface de la fonction, et les vieux .ino des utilisateurs continuent de fonctionner sans changement. Ajouter un argument pour chaque broche, c'est tout changer... C'est vrai que l'on peut ajouter aussi des variantes de begin avec plus d'arguments. A toi de voir.
Extraire les valeurs, c'est facile : pin/100 donne le numéro de l'expander, pin%100 donne celui de la broche. Le port doit en interne stocker le numéro d'expander sur un octet à côté du numéro de broche. Ce numéro a besoin d'un entier vu qu'il peut contenir un GPIO_pin_t à cause de l'utilisation de la bibliothèque Dio2.

[golgoth1009]

Bonjour Thierry,
J'ai avancé avec une première version fonctionnelle.
J'ai donc créé une classe PortExpander.
Cette classe est uniquement appelé depuis la classe Port.
Comme échangé ensemble, j'ai intégré le multiplexage. De cette façon, c'est entièrement transparent pour les sketchs n'utilisant pas d'expander.
Les sketchs utilisant des expanders ont uniquement besoin de rajouter dans le setup.

Code: [Sélectionner]

  PortExpander::begin(1, SX1509_ADDRESS , EXPANDER_TYPE::SX1509_IO);
Pour le moment, j'ai uniquement intégré l'expander sx1509 avec la lib fournit par sparkfun.
Je t'ai mis en pièce jointe les fichiers.
Je n'ai pas intégré les #define pour activer ou non l'expander et les types d'expander, les commentaires pour la doc aussi.
Qu'en penses-tu?

[Thierry]

C'est pas mal du tout, et ça a le (grand) mérite de fonctionner.
Mais, parce qu'il y a toujours un mais, ça gagnerai à être mis à la mode objet. Je n'aime pas les switch, ils dénotent un manque de structure. Alors plutôt que de mettre tout le code d'un expander particulier dans ton source, qu'il faudra modifier à chaque nouvel expander, il faudrait laisser une classe de base PortExpander, peut être même abstraite (virtuelle pure) et la dériver en PortExpanderSX1509 avec son fonctionnement à lui. Il faudrait faire pareil dans le Port : lui demander de lancer le digitalWrite() de l'expander, et lui saura ce qu'il doit faire...

J'ai déjà commencer à coder quelque chose, mais je vais m'inspirer de ce que tu as fait et voir comment améliorer, à moins que tu ne te sentes d'attaque pour affiner le code...

En tout cas, c'est du bon boulot.

[golgoth1009]

Merci !
Je peux faire l'héritage, effectivement, c'est plus logique et plus simple à l'avenir.
Normalement, dans la classe Port, cela devrait être transparent, elle appelle déjà les fonctions génériques statiques digitalWrite et analog de la classe Expander.
Par contre, je sèche pour l'émulateur qui redéfinit les méthodes digital et analog.
Je regarde ça ce weekend.

[golgoth1009]

Bonjour Thierry,

J'ai fait les modifications avec l'héritage.
J'ai découvert un bogue lié à la façon dont j'ai intégré l'expander.
Pour ne pas avoir d'impact dans les classes héritant de Port, je démultiplexe à chaque appel de la fonction MovePin().
Mais à la différence de la fonction beginPin(), le pin a pu être modifié si c'est un digital pour utiliser la valeur GPIO.
Pour corriger cela, j'ai ajouté un test supplémentaire dans MovePin():

Code: [Sélectionner]

unsigned long inExpander = 0;
if (GPIO_to_Arduino_pin((GPIO_pin_t)inPin) == -1)
inExpander = inPin / 100;La question que je me pose:
Est-ce que la valeur multiplexée peut être en conflit avec le pin GPIO (ex: 103 ou 515 peut-il être une pin GPIO) ?
Si non, la correction est suffisante.
Si oui, il faut alors modifier les classes héritant de port pour sauvegarder l'expander id et le passer en paramètre de MovePin().
J'ai testé ma mdif sur arduino uno avec des appels à l'expander et aux I/O de la carte.

[golgoth1009]

Bonjour,

Une version revisitée où j'ai retiré l'enum ExpanderType.
Il faut faire le begin en static directement sur la classe de l'expander voulue. Pour calquer au mieux à ce que tu fais pour les autres classes
De cette manière, l'ajout d'un nouveau type d'epxander ne devrait pas demander de modif à la classe de base ni à l'enum.

Code: [Sélectionner]

  int error = 0;
  error = PortExpanderSX1509::begin(1, SX1509_ADDRESS );
  if (error == 0)
    Serial.println(F("Expander issue"));


[Thierry]

Bonjour

Après quelques semaines de développement, je viens de pousser sur le Locogit une nouvelle version 1.2.0 d'Accessories intégrant les évolutions de golgoth1009, et des améliorations de mon crû sur le même sujet.

La classe PortExpander a été ajoutée sur la base du travail de golgoth1009, avec quelques amendements pour mieux coller à l'esprit de la bibliothèque, et avec une doc.
Le classe dérivée de PortExpander pour le SX1509, PortExpanderSX1509 (on a travaillé dur pour un nom original...), a été ajoutée. Elle gère les pins digitales et analogiques (pwm). Par contre il n'y a pas d'accès vers les fonctions spéciales de la bibliothèque originale SX1509 pour la gestion des Leds ou d'un clavier matriciel...
J'y ai ajouté une autre classe dérivée PortExpander74HC595 pour le shift register éponyme. Ne sont considérées que les broches en sortie. Le chaînage de plusieurs modules est reconnu. Par contre je n'ai testé qu'avec mon simulateur (je prépare un message sur le fil correspondant à ce sujet), je n'ai pas essayé sur un véritable montage...

En me relisant, je réalise que je n'ai pas crédité golgoth1009 pour ses idées et son travail dans les readme et les sources d'Accessories, ce qui me parait tout à fait légitime. Ce sera fait avec la prochaine version.

[golgoth1009]

Bonjour Thierry,

Merci pour ces intégrations. J'aime beaucoup les macros pour encoder les pin et expanderid.
J'ai testé la bibliothèque sur un montage réel avec sx1509.
J'ai noté une régression sur le décodage de la pin.
Le bug est le suivant (dans port.cpp):
Si la pin est de type DIGITAL et n'est pas sur un expander, elle est codé pour GPIO (beginPin function).
Ce qui pose un souci dans MovePin, où au moment de son décodage, elle risque d'être interpréter pour un expander.
C'est pour cela que je propose le test suivant dans MovePin et les CheckPin:

Code: [Sélectionner]

unsigned long expanderId = 0;
if (GPIO_to_Arduino_pin((GPIO_pin_t)inPin) == -1)
expanderId = EXPANDER_PORT_EXPID(inPin);
Je ne suis pas si cela suffit à supprimer tous les cas (si des conflits peuvent subsister entre l'encodage pour expander et GPIO).

En tout cas, j'ai testé cette modification sur la bibliothèque que tu as publiée, et tout marche parfaitement dans mon cas.

[Thierry]

Oui je m'en suis aperçu, et j'ai implémenté une correction que je n'ai pas encore testé. Pour y arriver, j'ai utilisé un bit libre dans le statut d'un port pour désigner l'ensemble d'un port comme expander ou pas. Cela oblige toutes les pins utilisées par un port à être sur un expander ou pas. Du coup, certains ports deviennent incompatibles avec les expanders, comme le port dédié au shield l293d et d'autres... Je ne suis pas sûr de conserver cette correction qui limite un peu trop à mon gout l'usage des expanders.

J'aime bien ta correction, mais il y a une petite possibilité de tomber sur des valeurs identiques entre une broche expander et un Gpio_t ...

A creuser.

[Thierry]

Voilà, une nouvelle version 1.2.1 a été poussée sur le Git et rendue disponible à la mise à jour dans l'IDE. En plus du test que tu as ajouté, j'ai mis une vérification au moment du begin() du port pour que l'on voit au plus tôt le problème. J'ai aussi ajouté au tout début, lors de la première loop(), une vérification que toutes les pins expander sont bien accessibles sans conflit avec les GPIO_pin_t.
Cela ne me satisfait pas complètement, j'aurais voulu éviter l'appel de GPIO_to_Arduino_pin() à chaque MovePin. Une fois devrait suffire, mais concrètement je ne vois pas comment sans stocker un bit quelque part, pour chaque pin !