Qual è il modo corretto di rendere configurabili i mapping dei pin della libreria?


8

Sto lavorando con alcune librerie che forniscono API per l'interazione con specifici chip hardware (che rende questi driver?). Tuttavia, schede o scudi personalizzati diversi avranno il chip mappato su diversi pin, il che significa che la libreria deve essere modificata per ogni caso. La necessità di modificare la libreria non funziona bene con il Gestore libreria IDE di Arduino.

Esistono schemi preferiti / consigliati per esporre questa configurazione in modo che la libreria stessa non debba essere modificata ogni volta?

Ecco un esempio in cui è documentato quale parte deve essere modificata per adattarsi al layout dei pin della scheda.


Molte delle normali librerie di Arduino lo fanno già: inizia familiarizzando con quel metodo, anche dal punto di vista dell'utente.
Chris Stratton,

Risposte:


6

Il metodo che uso è fornire i pin come parametri al costruttore. Quei numeri pin sono memorizzati in variabili da usare in seguito nella .begin()funzione e altrove.

Il più delle volte utilizzo gli elenchi di inizializzazione per semplificare le cose. Per esempio:

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

Vorrei utilizzare una delle due seguenti possibilità:

Usa le variabili (di classe) e impostale nel costruttore.

vantaggi:

  • Inizializzato sempre
  • Facile da usare (costruttore e configurazione pin contemporaneamente)

Utilizzare un metodo separato (ad es. Init).

vantaggi:

  • Può essere modificato dinamicamente

Osservazioni

Per le impostazioni dei pin, vengono utilizzati principalmente circuiti statici, quindi il primo approccio è probabilmente migliore.

Per le impostazioni, principalmente il secondo metodo è migliore.

Se sono coinvolti molti pin (probabilmente), utilizzare una struttura o una classe di impostazioni dei pin separata.

Macro

Quello che non consiglierei sono le macro. Quando gli utenti devono modificare autonomamente il codice sorgente e sono installate nuove versioni, devono unire o ripetere nuovamente le modifiche. I vantaggi sono un po 'meno codice (macchina), probabilmente un po' più veloce e un po 'meno utilizzo della memoria, ma tutti e tre gli aspetti sono minimi.


2

a seconda del tuo approccio.

1) se fornisci semplicemente i file binari + header, dovrai rendere variabili i pin.

2) se si fornisce il codice sorgente e si prevede che l'utente ricompili il codice sorgente, utilizzare le macro.


2

Nel caso in cui evitassi le cose del costruttore C ++ che sono abbastanza comuni su Arduino, potresti usare #definele macro simili a oggetti.

Così:

#define PIN_ONE 1
#define PIN_TWO 2

Il preprocessore sostituirà senza problemi PIN_ONEcon il numero 1 e PIN_TWO2 supponendo che tali definizioni si trovino nel .hfile di intestazione della libreria . Molto probabilmente questo richiederà la quantità minima di risorse rispetto alle altre possibili soluzioni.


Il problema è che devono trovarsi in un posto in cui sia il file .ino che l'origine della libreria possano raggiungerli. Questo di solito significa un file di intestazione separato con tutto ciò che richiede.
Ignacio Vazquez-Abrams,

Sei sicuro? Abbastanza sicuro di poter fare switch #define in .ino e sono usati nelle librerie, ma potrei sbagliarmi.
Avamandro

1
Può funzionare se il codice per la libreria è rigorosamente nell'intestazione, ma non se si trova in un'unità di compilazione diversa.
Ignacio Vazquez-Abrams,

Sì, questo ha senso, non conosceva i limiti esatti, ha aggiunto quel disclaimer.
Avamandro
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.