Il modo migliore per organizzare il software per i driver delle periferiche esterne del microcontrollore

2

Recentemente, ho iniziato a progettare e scrivere codice per microcontrollori al fine di ottenere una comprensione più profonda di come funzionano. Il primo grande progetto che ho intrapreso riguarda la scrittura di un driver per il fidato controller LCD Hitachi HD44780. In pochissimo tempo, sono stato in grado di implementare un'interfaccia di comunicazione con il display LCD e tutti i comandi LCD definiti. Sono felice con il driver di base, sono sicuro che segue la convenzione. Utilizza un approccio top-down stratificato in modo tale che ci sia un'interfaccia pubblica ben definita e il livello inferiore contenga le sole funzioni per parlare all'hardware GPIO.

Tuttavia, ho iniziato a implementare funzionalità avanzate quali spostamento / scorrimento verticale, animazioni, ecc. L'implementazione è stata fatta finora all'interno di un singolo modulo, il che è buono perché mantiene tutte le funzioni insieme e l'utente del driver può solo chiamare le funzioni fornite a lui / lei. Il lato negativo di questo è che il driver sta diventando più complesso da mantenere, il che mi dice che potrei aver bisogno di romperlo piuttosto che perseguire un progetto monolitico.

Sto pensando di creare un altro modulo solo per dire lo scrolling verticale. L'interfaccia pubblica conterrà la struttura dei dati e le funzioni richieste per eseguire lo scrolling che è gestito da main. È un approccio valido o mi manca qualcosa completamente?

Quando dico modulo, sto parlando di un gruppo di funzioni correlate. La mia comprensione è che un driver è un modulo per il controllo di un po 'di hardware, ma il modulo non significa necessariamente driver, ad es. Libreria di stringhe C.

    
posta sulay 01.06.2015 - 03:32
fonte

1 risposta

2

I driver vengono spesso suddivisi in più livelli. Qualcosa di "semplice" come un driver del mouse ha moduli separati per:

  • Specifiche USB diverse: 1.0, 2.0, ecc.
  • Chip controller USB specifici.
  • Dispositivi HID.
  • mouse USB.
  • Tutti i mouse a livello di kernel.
  • Implementazioni equivalenti di quanto sopra per PS / 2 e mouse seriali.
  • Driver del mouse del sistema di generazione (Xorg, ecc.)
  • API di mouse per strumenti grafici (GTK, QT, ecc.)

È certamente ragionevole dividere il driver in base al livello di astrazione o a ciò che è probabile che cambi insieme. Cose come il buffering, lo scrolling, la formattazione, il wrapping e l'animazione possono e devono essere separate e lavorate separatamente, usando solo l'API pubblica degli strati sottostanti.

    
risposta data 01.06.2015 - 14:27
fonte

Leggi altre domande sui tag