Quando è necessario un driver di periferica e quando è possibile leggere / scrivere direttamente sulla porta?

Ci sono diversi motivi per cui potresti aver bisogno / bisogno di scrivere un driver di dispositivo.

1. stai creando un dispositivo che rientra in una categoria generica. Una stampante, uno scanner, una webcam, un controller di archiviazione, ecc. Si desidera scrivere un driver di dispositivo in modo che le applicazioni generiche possano comunicare con il dispositivo senza dover modificare le applicazioni.

2. si desidera che un dispositivo sia utilizzabile da più applicazioni in esecuzione contemporaneamente. Il driver del dispositivo deve arbitrare l'utilizzo del dispositivo tra le applicazioni. Ciò significa in genere avere un livello più alto di comprensione del dispositivo rispetto al "flusso di byte".

3. La progettazione dell'hardware e / o del sistema operativo potrebbe semplicemente costringerti a farlo. Windows ha bisogno di un qualche tipo di driver associato a un dispositivo USB per poter funzionare, è possibile abusare del driver hid ma solo se l'hardware è impostato per richiedere di essere un dispositivo HID. È possibile utilizzare un driver di periferica USB-seriale esistente, ma solo se il dispositivo presenta e un'interfaccia simile a una porta seriale. Se il dispositivo si trova su un bus mappato in memoria con DMA diretto, è necessario che il proprio driver si trovi nel kernel per configurare correttamente le transazioni DMA.

Anche se ci sono ragioni per voler evitare di scrivere un driver di dispositivo, specialmente un driver di dispositivo in modalità kernel.

1. Scrivere il codice della modalità kernel è complicato / specialistico e se lo rovini, fai cadere tutto il sistema, non solo il tuo programma. Anche se il sistema operativo offre la possibilità di scrivere il tuo driver in modalità utente, potrebbe significare programmare in un linguaggio e in un ambiente non familiari.

2. La distribuzione è molto più dolorosa. Sul lato Windows, MS ha recentemente migliorato i requisiti di firma del driver. Sul lato Linux, le interfacce userland sono molto più stabili di quelle del kernel e i moduli del kernel devono essere ricostruiti per ogni nuova versione del kernel.

3. Se il tuo codice è suddiviso in un'applicazione e un driver, devi preoccuparti della situazione delle versioni miste di applicazioni / driver.

Si tratta quindi di un atto di bilanciamento il cui motivo è più convincente per un particolare dispositivo.

I driver di dispositivo sono un livello di astrazione. Permettono di parlare al dispositivo senza conoscere le meccaniche di basso livello del sistema operativo o le idiosincrasie specifiche del dispositivo. Offrono anche un'interfaccia ben nota e di alto livello al sistema operativo, un'interfaccia che è esattamente la stessa per dispositivi simili.

Senza un driver di dispositivo, dovresti essenzialmente scriverne uno da solo, e quel driver di dispositivo sarebbe completamente diverso per ogni modello di dispositivo. Al contrario, il produttore fornisce in genere un driver di dispositivo che si traduce dall'interfaccia specifica dell'hardware di quel dispositivo specifico alla ben nota interfaccia di alto livello per il sistema operativo.

Questa disposizione offre diversi vantaggi:

1. Il software scritto per questi dispositivi funzionerà con qualsiasi dispositivo nella classe di dispositivi (ad esempio le webcam), se è scritto sulla stessa interfaccia comune di alto livello.

2. Le caratteristiche specifiche del dispositivo come la tempistica, la gestione dei segnali e i protocolli di dati sono lontane dall'utente.

3. I driver di dispositivo forniscono un livello di sicurezza. Mentre il driver di periferica opera tipicamente nel kernel (dove i problemi possono mandare in crash il sistema operativo), l'applicazione utente in genere comunica con il driver di dispositivo nello spazio utente, dove un problema arresta semplicemente l'applicazione.

4. I driver di dispositivo hanno accesso a strumenti di gestione come il Pannello di controllo.

A volte, puoi allineare il tuo dispositivo con un'API come la specifica HID (Human Interface Device) e non hai nemmeno bisogno di installare un altro driver di periferica.

Non ho guardato il software OpenBCI in dettaglio, ma sospetto che sia effettivamente o abbia un driver di dispositivo. La maggior parte dei sistemi operativi moderni non ti permetterà nemmeno di parlare direttamente con le porte ; tu devi passare attraverso il sistema operativo.

Il motivo per cui è necessario installare il driver per la tua webcam, è perché la tua webcam è forse più recente del tuo sistema operativo, oi suoi driver non sono inclusi nel tuo sistema operativo. Molte webcam non richiedono l'installazione dei driver, in quanto molte webcam utilizzano piattaforme in circolazione da molto tempo e i relativi driver sono forniti con il sistema operativo. Trova una webcam logitech di 15 anni e collegala, e hai una buona possibilità di scoprire che puoi usarla senza installare nulla *

Le porte seriali hanno quasi sempre driver inclusi con il tuo sistema operativo, perché l'hardware per le porte seriali è stato essenzialmente la stessa cosa per 20 anni.

I due tipi di driver forniscono comunque accesso programmatico a diverse astrazioni di hardware diverso. Ecco perché non puoi, in userspace, parlare con una webcam tramite flussi di byte in entrata e in uscita. Invece, la webcam "parla" di DirectShow o Video4Linux o qualsiasi altra astrazione video utilizzata dal tuo sistema operativo *

Il contrario è di nuovo vero, la porta seriale "trasmette" solo flussi di byte, quindi non è possibile richiedere i frame video e ottenerli dal driver.

* Alcuni driver richiedono l'installazione di driver speciali, indipendentemente dall'età, per completamente utilizzare il dispositivo poiché a volte i dispositivi hanno funzionalità non supportate in DirectShow / etc, come le webcam che possono , inclinazione e zoom, o riconoscimento facciale o altro. Ma non pensarci troppo, perché sono casi speciali.

Diverse altre risposte hanno ottimi punti sui vantaggi della separazione dell'applicazione dall'interfaccia del dispositivo e dell'astrazione, ma ci sono due punti che non sono stati menzionati: performance e privilegi di accesso .

Prestazioni

I driver di dispositivo spesso siedono in attesa di un input o di un interrupt per dire loro di leggere un input, quindi quando scrivi il tuo codice dovrai fare uno di questi:

• Polling sul dispositivo il resto del codice deve assicurarsi che ciò accada abbastanza spesso
• Gestione degli interrupt questa è un'abilità specialistica e cosa succede se hai bisogno di parlare con più di un dispositivo
• Multi-threading o multi-processing di nuovo competenze specialistiche, non tutte le lingue hanno un buon supporto e se hai intenzione di dividere il tuo gestore di dispositivo in un thread separato sei più vicino a un driver di dispositivo

Privilegi di accesso

Su molti sistemi operativi, e persino in alcuni target bare metal di assemblaggio l'accesso all'hardware e alle posizioni di memoria assolute richiede privilegi elevati super utente, root, diritti di amministrazione - Non è una buona pratica per la tua Applicazione , e il suo utente, per richiedere tali diritti, ma se implementa le sue interfacce di dispositivo sarà < strong> devono avere loro.

Quando il tuo software è progettato per funzionare solo con un componente hardware specifico, non è necessario un driver di periferica aggiuntivo. Tuttavia, se ci fosse un altro hardware di lettore di onde cerebrali con diverse interfacce che si desidera supportare, sarebbe utile un driver di periferica aggiuntivo. Tutto dipende dallo scopo del tuo progetto. Per l'uso hobbista non è necessario creare un driver di periferica aggiuntivo.

Fondamentalmente la risposta è, quando non stai parlando con un driver di dispositivo, il tuo programma è il driver di dispositivo.

I driver di dispositivo semplificano la comunicazione con l'hardware, ma sono anche restrittivi: puoi solo fare ciò che offre il driver di dispositivo.

Ma in generale: Se hai bisogno di totale libertà, parli direttamente con un porto. Questo spesso rende il software intrecciato con l'hardware come in: funzionerà solo per il dispositivo specifico per cui lo hai realizzato.

Se non è disponibile un driver di dispositivo, è ovviamente necessario parlare direttamente al tuo hardware.

Se i driver di dispositivo disponibili non sono abbastanza buoni, parli direttamente con il tuo hardware.

Fondamentalmente in tutti gli altri casi si usa un driver di dispositivo. (ma ricorda che, anche se non usi un driver di dispositivo, lo usi ancora, lo fai da solo)

In realtà, ti manca un paio di blocchi importanti nel diagramma. Il "ricevitore RF (chiavetta USB)" non invia i dati a "porta seriale / USB". Innanzitutto, non esiste una "porta USB". Il dongle RF invia i dati USB in "USB pipe" in risposta alle richieste dell'host. L'host genera la richiesta tramite il driver USB del controller host, ehci.sys o qualcosa del genere. Il driver host forma i pacchetti USB e obbedisce al protocollo USB.

Il contenuto del pacchetto per il controller host, tuttavia, viene avviato da un driver generico della classe COM, un altro livello del software (anch'esso predefinito del sistema operativo). Questo è il "device driver", che emula una porta COM standard e mappa / converte le porte in lettura / scrittura in richieste USB in accordo con le definizioni / formati di classe. La parte della libreria Java, JSerialComm, è solo un'interfaccia simile a un flusso (bufferizzata) a questa porta COM virtuale emulata.

Come si può vedere, non c'è niente come "parlare direttamente con l'hardware" o "scrivere direttamente sulla porta COM", ci sono diversi livelli di porte virtuali. È impossibile generare un singolo interruttore sul bus USB senza impostare strutture dati enormi, molto specifiche e complicate (contesto dispositivo / slot, buffer dell'anello di trasferimento, anello di comando, anello di eventi, ecc.) Nella memoria principale e configurazione del controller host USB per collegamenti elenca l'elaborazione e quindi suona un registro campanello per avviare una transazione USB. Tutto questo è realizzato con due livelli di driver, controller host e dispositivo, con molte migliaia di righe di codice e una mezza dozzina di anni di sviluppo e debug. Per una migliore comprensione e apprezzamento di questo livello nascosto di servizi, controlla con Microsoft .

L'interfaccia per esportare i dati dallo spazio del kernel allo spazio utente non è molto espressiva. In particolare, non è tipizzato. Si ottiene una sequenza di byte e il programma spaziale dell'utente deve quindi convertire quei byte in qualcosa con un significato semantico. Quindi i driver di dispositivo sono generalmente associati a librerie di spazio utente.

Se hai aggiunto un driver di dispositivo OpenBCI dello spazio del kernel in cima al driver seriale generico, questo ti darebbe la possibilità di convertire un modo per ordinare i byte in un modo diverso per sequenziare i byte. Se potessi fare ciò, quale sequenza diversa sceglieresti? Se una sequenza diversa sarebbe migliore, perché non hai semplicemente costruito quella sequenza migliore nel firmware OpenBCI, in primo luogo?

Potresti avere motivi di prestazioni per scrivere un driver in modalità kernel specifico per dispositivo, o potresti dover tradurre per conformarsi a un'interfaccia esistente, ma altrimenti otterrai molto più valore dal creare uno spazio utente espressivo libreria come OpenBCI_Python anziché fare quello che equivarrebbe a un driver in modalità kernel molto anemico.