Cómo funcionan los controladores de dispositivos

¿Alguien puede explicar cómo funcionan los controladores de dispositivos? He visto Arduino y otras placas de desarrollo comunicándose con el puerto USB de la PC con la ayuda de un chip FTDI. Esto se puede hacer funcionar después de instalar el controlador del dispositivo. Entonces, ¿cuál es el papel del chip FTDI y el controlador aquí? ¿Por qué no podemos hacer este trabajo sin un chip FTDI, conectando directamente la MCU Atmel (he trabajado solo con MCU AVR) y teniendo un controlador adecuado para ello?

Respuestas (2)

El chip FTDI se conecta por un lado a través de una interfaz USB a una PC, y por el otro presenta una interfaz UART al microcontrolador; para este último parece como si se hubiera conectado un cable RS232 al dispositivo a través de un cambiador de nivel RS232-UART.

Esto tiene dos ventajas. En el lado de la PC, la interfaz USB se convierte en un puerto COM virtual, lo que facilita que los programas se comuniquen con él, ya que no necesitan pasar por un controlador USB especial, solo tienen que hablar con el puerto COM, y, por lo tanto, ni siquiera saben que hay un puerto USB involucrado y no necesitan tener un código para comunicarse con un controlador USB especial.

Normalmente, no es necesario instalar el controlador para el chip FTDI; dado que hay tantos dispositivos que usan variaciones del chip FTDI, las versiones más nuevas de Windows y Linux vienen con un controlador USB/FTDI ya incorporado.

En el lado del microcontrolador, lo mismo es cierto: en lugar de tener que escribir software para que funcione como un dispositivo USB (suponiendo que el microcontrolador tenga un puerto USB), el programa de firmware en el microcontrolador solo tiene que lidiar con la interfaz con el UART que es mucho más fácil Entonces, en ambos extremos, la PC y el microcontrolador, el software cree que hay un cable RS232 entre la PC y la placa, y no se da cuenta de que hay un cable USB en su lugar.

Si no se utiliza un chip FTDI y el microcontrolador tiene una interfaz USB, se puede conectar un cable USB directamente entre el cable del microcontrolador y la PC. Luego se puede escribir firmware en el microcontrolador para presentar una interfaz de "dispositivo" USB a la PC. (Esto contrasta con la interfaz USB "host", que se usaría, por ejemplo, si un dispositivo USB, como una tarjeta de memoria o un mouse, se conectara al microcontrolador).

Si es posible, los programadores que escriben este tipo de firmware intentan utilizar la interfaz HID (dispositivo de interfaz humana), que inicialmente estaba destinada a ser utilizada por dispositivos como teclados y ratones. Sin embargo, dado que el controlador USB HID siempre se incluye en el sistema operativo (¡de lo contrario, su teclado no funcionaría al arrancar!), nunca necesita cargarse y es relativamente fácil escribir software en la PC para interactuar con él.

La situación más difícil es cuando se necesita un protocolo USB especial. Esto hace que la vida sea mucho más complicada tanto para los implementadores del firmware (lado del microcontrolador) como del software (lado de la PC). Cuando el dispositivo USB está conectado y enumerado, el sistema operativo (Windows o Linux, etc.) no podrá encontrar un controlador integrado para él. Por lo tanto, el software del dispositivo debe incluir un controlador USB especial, que el usuario deberá instalar antes de utilizar el dispositivo.

¿Qué quiere decir con protocolo USB especial? Y también si el teclado usa la interfaz HID para conectarse a la PC, ¿por qué cada vez que conectamos un nuevo teclado, la PC comienza a instalar un nuevo controlador?
¿El programador USBasp es uno de esos que usa un protocolo USB especial? En el administrador de dispositivos no se agrupan como dispositivos USB.
@Bishal con respecto a su primera pregunta, un protocolo USB especial es uno que no es uno de los controladores USB incorporados, como Audio, CDC, HID, almacenamiento masivo, etc. Cuando agrega un nuevo dispositivo, sí, dirá que lo es. instalar un nuevo controlador, pero en el caso de HID y otros similares, el controlador ya estará incluido en el sistema operativo. Pero el sistema operativo aún necesita asociar el teclado con el controlador.
@Bishal Según esta página, USBasp requiere un controlador especial para Windows. USBasp utiliza una implementación solo de firmware de USB 1.1 en un AVR llamado V-USB . El controlador del lado de la PC se llama libusb-Win32 .

Eso se debe a que las computadoras domésticas usan ciertos estándares para comunicarse. Está el puerto serie, puerto paralelo (obsoleto), USB cualquier versión, ethernet, fibra óptica tal vez, (e-)sata y así sucesivamente.

Un microcontrolador suele utilizar diferentes estándares como I2C o SPI, la única interfaz común es el enlace serie (RS232).

Cada una de estas interfaces tiene sus ventajas y desventajas: la serial es fácil de implementar pero lenta, la ethernet es buena para cables muy largos, la sata se usa para dispositivos de almacenamiento masivo y es muy rápida... Cada interfaz suele necesitar un hardware dedicado, y por eso tu microcontrolador no tiene puerto sata: eso es algo que pocos diseñadores usarían así que no vale la pena ponerlo en cada chip, subiendo los costos.

¡Pero, por supuesto, puede emular el hardware a través del software! Eso es bastante complicado, probablemente necesite algún nivel de cambio fuera de su chip porque generalmente los voltajes difieren de una interfaz a otra, pero puede hacerlo. Entonces, si su chip no tiene HW dedicado I2C, puede escribir su propio código y emularlo. Eso, por supuesto, usa mucha CPU y, a veces, eso no es posible. El chip FTDI hace este trabajo por usted: se ocupa de los niveles de la señal (el usb es un enlace LVDS) y probablemente proporciona algunos marcos o lo que sea. Y probablemente tenga una interfaz I2C. Usar I2C es mucho más fácil que USB. Del lado del microcontrolador, solo tiene que hablar con el chip FTDI de la manera I2C, su micro probablemente tenga una interfaz I2C HW, y está listo para comenzar.

Del lado de la computadora, el problema es que este chip FTDI no es un dispositivo estándar como un mouse o un gamepad, probablemente pueda emular varios dispositivos y puede elegir cuál indicándolo a través de I2C. El punto es que necesita algunos controladores. Un controlador es una pieza de software que interactúa con una pieza de hardware: en este caso, el nivel está un poco por encima: el lado de la computadora del controlador USB tiene su propio controlador, pero la forma de comunicarse con el chip FTDI es personalizada. Tal vez necesite algunos paquetes extraños al principio para inicializarse correctamente, tal vez tenga una velocidad máxima que sea mucho más baja que la que considera el estándar USB... Piense en el controlador como una pieza de código que el lado del software expone dos búferes: data_in y data_out , mientras que el lado del hardware se encarga de cómo enviar estos búferes a su dispositivo personalizado.

Es como lo que está haciendo en el lado del microcontrolador: inicia la comunicación I2C, configura algunos registros, comienza a enviar datos.

Podría hacer el trabajo sin ningún chip de interfaz, como sugiere, pero eso sería mucho más difícil. Tendría que encontrar una manera de conectarse a una interfaz de bajo nivel de su PC, eso significa encontrar un puerto I2C libre, si lo hay, y conectar su MCU allí. O otra interfaz de bajo nivel, por supuesto. Está intercambiando toneladas de velocidad, tiempo, confiabilidad y reutilización por algunos centavos ahorrados en un FTDI.