Quelle est la bonne façon de rendre les mappages de broches de bibliothèque configurables?


8

Je travaille avec certaines bibliothèques qui fournissent des API pour interagir avec des puces matérielles spécifiques (qui font ces pilotes?). Cependant, différentes cartes ou écrans personnalisés auront la puce mappée sur différentes broches, ce qui signifie que la bibliothèque doit être modifiée pour chaque cas. La nécessité de modifier la bibliothèque ne fonctionne pas bien avec le gestionnaire de bibliothèque Arduino IDE.

Existe-t-il des modèles préférés / recommandés pour exposer cette configuration afin que la bibliothèque elle-même n'ait pas besoin d'être modifiée à chaque fois?

Voici un exemple où il est documenté quelle partie doit être modifiée pour correspondre à la disposition des broches de votre carte.


Beaucoup de bibliothèques Arduino normales le font déjà - commencez par vous familiariser avec cette méthode, même du point de vue de l'utilisateur.
Chris Stratton

Réponses:


6

La méthode que j'utilise est de fournir les broches en tant que paramètres au constructeur. Ces numéros de broches sont stockés dans des variables à utiliser plus tard dans la .begin()fonction et ailleurs.

La plupart du temps, j'utilise des listes d'initialisation pour garder les choses simples. Par exemple:

class Something {
    uint8_t _cs;
    uint8_t _dc;

    Something(uint8_t cs, uint8_t dc) : _cs(cs), _dc(dc) {}
    void begin();
};

void Something::begin() {
    pinMode(_cs, OUTPUT);
    pinMode(_dc, OUTPUT);
}

Something mySomething(10, 8);

6

J'utiliserais l'une des deux possibilités suivantes:

Utilisez des variables (de classe) et définissez-les dans le constructeur.

Avantages:

  • Toujours initialisé
  • Facile à utiliser (constructeur et configuration des broches à la fois)

Utilisez une méthode distincte (par exemple, Init).

Avantages:

  • Peut être modifié dynamiquement

Remarques

Pour les réglages des broches, des circuits principalement statiques sont utilisés, donc la première approche est probablement meilleure.

Pour les paramètres, la deuxième méthode est généralement meilleure.

Si plusieurs broches sont impliquées (peu probable), utilisez une structure ou une classe de paramètres de broches distincte.

Macros

Ce que je ne conseillerais pas, ce sont les macros. Lorsque les utilisateurs doivent modifier le code source eux-mêmes et que de nouvelles versions sont installées, ils doivent fusionner ou refaire les modifications. Les avantages sont un peu moins de code (machine), un peu plus rapide probablement et un peu moins de mémoire, mais les trois aspects sont minimes.


2

selon votre approche.

1) si vous fournissez simplement les fichiers binaires + en-tête, vous devrez faire les variables pins.

2) si vous fournissez le code source et attendez de l'utilisateur qu'il recompile le code source, utilisez des macros.


2

Dans le cas où vous évitez les éléments du constructeur C ++ qui sont assez couramment une surpuissance sur Arduino, vous pouvez utiliser #defineles (macros de type objet).

Ainsi:

#define PIN_ONE 1
#define PIN_TWO 2

Le préprocesseur sera facilement remplacé PIN_ONEpar le numéro 1 et PIN_TWOpar 2 en supposant que ces définitions se trouvent dans le .hfichier d'en- tête de la bibliothèque . Cela prendra probablement le moins de ressources par rapport aux autres solutions possibles.


Le problème est qu'ils doivent se trouver dans un endroit où le fichier .ino ainsi que la source de la bibliothèque peuvent y accéder. Cela signifie généralement un fichier d'en-tête séparé avec tout ce qui nécessite.
Ignacio Vazquez-Abrams

Êtes-vous sûr? Je suis presque sûr que je peux faire des commutateurs #define dans .ino et qu'ils sont utilisés dans les bibliothèques, mais je peux me tromper
Avamander

1
Cela peut fonctionner si le code de la bibliothèque se trouve strictement dans l'en-tête, mais pas s'il se trouve dans une autre unité de compilation.
Ignacio Vazquez-Abrams

Oui, cela a du sens, je ne connaissais pas les limites exactes, a ajouté cet avertissement.
Avamander
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.