¿Cuándo se necesita un controlador de dispositivo y cuándo está bien leer / escribir directamente en el puerto?

Me resulta difícil entender cuándo se necesitan controladores de dispositivo y cuándo está bien hablar directamente con un controlador de puerto a través del puerto serie / paralelo / USB / etc. provisto por el sistema operativo. conductor.

Por ejemplo, Ejemplo 1 : tomemos OpenBCI , un hardware de código abierto BCI que le permite leer lecturas de EEG + EKG ("brainwave"). El auricular OpenBCI envía señales de RF a una unidad USB conectada a su máquina, y luego puede escribir su propio software para leer los datos que ingresan a ese puerto; por lo tanto, le permite leer sus propias ondas cerebrales e interpretar los datos de las ondas cerebrales en la capa de la aplicación. Muy genial. Para leer sus datos de ondas cerebrales de "transmisión", no solo debe leer desde su puerto serie (utilizando el controlador serie proporcionado por el sistema operativo), sino que debe interpretar los datos de acuerdo con las especificaciones de OpenBCI . Entonces la pila se ve así:

Pero en ninguna parte aquí tenemos un "controlador de dispositivo" específico para los auriculares OpenBCI. Solo el controlador serial necesario para leer bytes de datos, y luego debe interpretar qué significan esos bytes desde dentro de su aplicación. Entonces, por ejemplo, si quisiera una aplicación Java para interpretar datos de ondas cerebrales, podría usar JSerialComm para leer los datos de mi puerto COM local (o cualquier USB que esté en el sistema local). Entonces dependería de mi aplicación interpretar esos datos según las especificaciones enumeradas anteriormente.

Ahora, Ejemplo 2 : una cámara web USB Logitech como esta . Aquí, debe instalar los controladores de dispositivo de la cámara web en su máquina para poder usarla. Me pregunto por qué. Supongamos (solo presione el botón " ¡Creo! " Por un momento) que el pinout para esta cámara web fue estúpidamente simple:

PIN #       Meaning
===================
1           Power
2           Ground
3           Send data (if 1 then the camera will start "streaming" its video data over data pins)
4           Data pin 1
5           Data pin 2

Este es un dispositivo USB, al igual que OpenBCI. Entonces, ¿por qué no podría escribir una aplicación (en cualquier idioma) que también solo lea / escriba directamente en el puerto USB / serie (nuevamente, tal vez usando JSerialComm o similar)? Cuando quiero que la aplicación comience a capturar datos de video de la cámara web, envío bytes al puerto serie ( nuevamente a través de JSerialComm, etc.) que activan / activan el Pin # 3, y que luego comienzan a leer los datos de video de los Pines 4 y 5.

Supongo que no entiendo por qué OpenBCI no tiene o no necesita un controlador de dispositivo, mientras que la cámara web (o cualquier otro dispositivo USB estándar como una impresora, mouse, teclado, etc.) sí. ¡Gracias por adelantado!

Hay varias razones por las que es posible que desee / necesite escribir un controlador de dispositivo.

1. está creando un dispositivo que se ajusta a una categoría genérica. Una impresora, un escáner, una cámara web, un controlador de almacenamiento, etc. Desea escribir un controlador de dispositivo para que las aplicaciones genéricas puedan comunicarse con su dispositivo sin tener que modificar las aplicaciones.

2. desea que un dispositivo pueda ser utilizado por varias aplicaciones que se ejecutan al mismo tiempo. El controlador del dispositivo debe arbitrar el uso del dispositivo entre las aplicaciones. Eso generalmente significa tener un mayor nivel de comprensión del dispositivo que el "flujo de bytes".

3. El diseño del hardware y / o sistema operativo puede simplemente obligarlo a hacerlo. Windows necesita algún tipo de controlador conectado a un dispositivo USB para que funcione, puede abusar del controlador oculto, pero solo si el hardware está configurado para afirmar que es un dispositivo HID. Posiblemente puede usar un controlador de dispositivo USB a serie existente, pero solo si su dispositivo presenta una interfaz que se parece a un puerto serie. Si su dispositivo está en un bus mapeado de memoria con DMA directo, entonces necesita que su controlador esté en el núcleo para configurar correctamente las transacciones de DMA.

Del mismo modo, hay razones para querer evitar escribir un controlador de dispositivo, especialmente un controlador de dispositivo en modo kernel.

1. Escribir código de modo kernel es complicado / especialista y si lo arruinas, derribas todo el sistema, no solo tu programa. Incluso si el sistema operativo ofrece la capacidad de escribir su controlador en modo de usuario, puede significar programar en un lenguaje y entorno desconocido.

2. El despliegue es mucho más doloroso. En el lado de Windows, MS ha estado aumentando los requisitos de firma del controlador recientemente. En el lado de Linux, las interfaces de usuario son mucho más estables que las del lado del kernel y los módulos del kernel tienen que reconstruirse para cada nueva versión del kernel.

3. Si su código se divide en una aplicación y un controlador, debe preocuparse por la situación de las versiones mixtas de aplicación / controlador.

Luego se reduce a un acto de equilibrio cuyas razones son más convincentes para un dispositivo en particular.

Los controladores de dispositivo son una capa de abstracción. Le permiten hablar con el dispositivo sin conocer la mecánica del sistema operativo de bajo nivel o las idiosincrasias específicas del dispositivo. También proporcionan una interfaz de alto nivel conocida para el sistema operativo, una interfaz que es exactamente la misma para dispositivos similares.

Sin un controlador de dispositivo, esencialmente necesitaría escribir uno usted mismo, y ese controlador de dispositivo sería completamente diferente para cada modelo de dispositivo. En cambio, el fabricante generalmente proporciona un controlador de dispositivo para usted que se traduce desde la interfaz específica de hardware de ese dispositivo específico a la conocida interfaz de alto nivel para el sistema operativo.

Este arreglo proporciona varios beneficios:

1. El software escrito para estos dispositivos funcionará con cualquier dispositivo en la clase de dispositivo (por ejemplo, cámaras web), si está escrito en la misma interfaz común de alto nivel.

2. Las características específicas del dispositivo, como la sincronización, el manejo de la señal y los protocolos de datos, se abstraen del usuario.

3. Los controladores de dispositivos proporcionan una capa de seguridad. Si bien el controlador del dispositivo generalmente opera en el núcleo (donde los problemas pueden bloquear el sistema operativo), la aplicación del usuario generalmente se comunica con el controlador del dispositivo en el espacio del usuario, donde un problema simplemente bloqueará la aplicación.

4. Los controladores de dispositivos tienen acceso a herramientas de administración como el Panel de control.

A veces, puede alinear su dispositivo con una API como la especificación HID (Dispositivo de interfaz humana), y ni siquiera necesita instalar otro controlador de dispositivo.

No he visto el software OpenBCI en detalle, pero sospecho que en realidad es o tiene un controlador de dispositivo. La mayoría de los sistemas operativos modernos ni siquiera le permitirán hablar directamente con los puertos; que debe pasar por el sistema operativo.

La razón por la que necesita instalar el controlador para su cámara web es porque su cámara web es posiblemente más nueva que su sistema operativo, o sus controladores no están incluidos con su sistema operativo. Muchas cámaras web no requieren que instales controladores, ya que muchas usan plataformas que han existido durante mucho tiempo, y los controladores para ellas vienen con tu sistema operativo. Encuentre una cámara web Logitech de 15 años y conéctela, y tiene una buena oportunidad de descubrir que puede usarla sin instalar nada *

Los puertos serie casi siempre tienen controladores incluidos con su sistema operativo, porque el hardware para los puertos serie ha sido esencialmente lo mismo durante 20 años.

Sin embargo, los dos tipos de controladores proporcionan acceso programático a diferentes abstracciones de hardware diferente. Es por eso que no puede, en el espacio de usuario, hablar con una cámara web a través de secuencias de bytes de entrada y salida. En cambio, la cámara web "habla" DirectShow o Video4Linux o cualquier abstracción de video que esté usando su sistema operativo *

Lo contrario es cierto nuevamente, el puerto serie solo 'habla' secuencias de bytes, por lo que no puede solicitar cuadros de video y obtenerlos del controlador.

* Algunos controladores requieren que instales controladores especiales, independientemente de la edad, para usar completamente el dispositivo, ya que a veces los dispositivos tienen capacidades que no son compatibles con DirectShow / etc., como cámaras web que pueden moverse, inclinarse y hacer zoom, o hacer reconocimiento facial, u otras cosas Pero no pienses demasiado en eso, ya que son casos especiales.

Varias de las otras respuestas tienen muy buenos puntos sobre los beneficios de separar su aplicación de la interfaz del dispositivo y de la abstracción, pero hay dos puntos que no se han mencionado: el rendimiento y los privilegios de acceso .

Actuación

Los controladores de dispositivos a menudo se sientan a la espera de una entrada o una interrupción para decirles que lean una entrada, por lo que cuando escriba su propio código deberá realizar una de las siguientes acciones:

• Al sondear el dispositivo, el resto del código debe asegurarse de que esto suceda con la frecuencia suficiente.
• Manejar interrupciones es una habilidad especializada y qué pasa si necesita hablar con más de un dispositivo
• Multi-threading o Multi-Processing nuevamente habilidades especializadas, no todos los idiomas tienen un buen soporte y si vas a dividir el controlador de tu dispositivo en un hilo separado, estás en la mayoría de los casos en un controlador de dispositivo

Privilegios de acceso

En muchos sistemas operativos, e incluso en algunos de los objetivos de metal desnudo ensamblaje nivel del acceso al hardware y ubicaciones de memoria absolutas requiere privilegios elevados de superusuario, raíz, derechos de administrador - No es una buena práctica para su aplicación , y su usuario, para requerir tales derechos, pero si implementa sus propias interfaces de dispositivo, tendrá que tenerlas.

Cuando su software solo está diseñado para funcionar con una pieza específica de hardware, entonces no necesita un controlador de dispositivo adicional. Sin embargo, si hubiera otro hardware de lector de ondas cerebrales con diferentes interfaces que quisiera admitir, entonces sería útil un controlador de dispositivo adicional. Todo depende del alcance de su proyecto. Para el uso de aficionados, no es necesario crear un controlador de dispositivo adicional.

Básicamente, la respuesta es, cuando no está hablando con un controlador de dispositivo, su programa ES el controlador del dispositivo.

Los controladores de dispositivo facilitan hablar con el hardware, pero también son restrictivos: solo puede hacer las cosas que ofrece el controlador de dispositivo.

Pero en general: si necesita total libertad, hable directamente con un puerto. Esto a menudo hace que su software esté entrelazado con el hardware como en: solo funcionará para el dispositivo específico para el que lo creó.

Si no hay un controlador de dispositivo disponible, obviamente necesita hablar directamente con su hardware.

Si los controladores de dispositivo disponibles no son lo suficientemente buenos, hable directamente con su hardware.

Básicamente, en todos los demás casos, utiliza un controlador de dispositivo. (pero recuerde, incluso si no usa un controlador de dispositivo, todavía lo usa, solo lo hizo usted mismo)

En realidad, te faltan un par de bloques importantes en el diagrama. El "receptor RF (memoria USB)" no envía los datos al "puerto serie / USB". Primero, no hay un "puerto USB". El dongle de RF envía datos USB a un "conducto USB" en respuesta a las solicitudes del host. El host genera una solicitud a través del controlador USB del controlador del host, ehci.sys o algo así. El controlador del host forma paquetes USB y obedece el protocolo USB.

Sin embargo, el contenido del paquete para el controlador host lo inicia un controlador genérico de clase COM, otra capa de software (también un valor predeterminado del sistema operativo). Este es el "controlador de dispositivo", que emula un puerto COM estándar y asigna / convierte las lecturas / escrituras del puerto en solicitudes USB de acuerdo con las definiciones / formatos de clase. La pieza de la biblioteca de Java, JSerialComm, es solo una interfaz de flujo (buffer) para este puerto COM virtual emulado.

Como se puede ver, no hay nada como "hablar directamente con su hardware" o "escribir directamente en el puerto COM", hay varias capas de puertos virtuales. Es imposible generar una sola palanca en el bus USB sin establecer estructuras de datos enormes, muy específicas y complicadas (contexto de dispositivo / ranura, buffers de anillo de transferencia, anillo de comando, anillo de eventos, etc.) en la memoria principal y configurar el controlador host USB para enlaces procesamiento de la lista, y luego sonar un registro de timbre para iniciar una transacción USB. Todo esto se logra con dos capas de controladores, controlador de host y dispositivo, con miles de líneas de código y media docena de años de desarrollo y depuración. Para una mejor comprensión y apreciación de esta capa oculta de servicios, consulte con Microsoft .

La interfaz para exportar datos del espacio del kernel al espacio del usuario no es muy expresiva. En particular, no está tipificado. Obtiene una secuencia de bytes y su programa de espacio de usuario tiene que convertir esos bytes en algo con significado semántico. Por lo tanto, los controladores de dispositivos generalmente se combinan con bibliotecas de espacio de usuario.

Si agrega un controlador de dispositivo OpenBCI de espacio de kernel encima del controlador serial genérico, eso básicamente le daría la capacidad de convertir una forma de secuenciar los bytes en una forma diferente de secuenciar los bytes. Si pudieras hacer esto, ¿qué secuencia diferente elegirías? Si una secuencia diferente sería mejor, ¿por qué no construiste esa secuencia mejor en el firmware OpenBCI en primer lugar?

Es posible que tenga razones de rendimiento para escribir un controlador de modo de kernel específico del dispositivo, o puede que necesite traducir para ajustarse a una interfaz existente, pero de lo contrario obtendrá mucho más valor al crear una biblioteca expresiva de espacio de usuario como OpenBCI_Python que hacer lo que equivaldría a un controlador de modo kernel muy anémico.