¿Cuál fue su primer proyecto de controlador de dispositivo y cómo lo hizo?

¡Esto probablemente no te va a ayudar!

Cuando estaba en la universidad en 1976, quería hacer un software de gráficos y se me dio acceso a un PDP11 / 20 y un plotter de lápiz antiguo, pero no había un controlador de dispositivo para ello.

¡Así que obtuve el código fuente del controlador para una impresora y (con una gran ayuda de mi tutor) lo modifiqué para manejar el trazador de lápiz de la manera más cruda imaginable! El plotter estaba conectado desde un puerto paralelo y tenía 5 cables más tierra. El trazador se movería un pequeño paso hacia el norte, sur, este u oeste si tirara de uno de los primeros cuatro cables hacia abajo y luego hacia arriba, y levantaría o bajaría el bolígrafo dependiendo del estado del quinto cable.

Puede ordenarle que vaya (por ejemplo) al norte y al este al mismo tiempo para mover el bolígrafo diagonalmente, pero se le advirtió en los términos más enérgicos que no intente moverlo al norte y al sur al mismo tiempo porque freiría alguna pieza de circuitos internos (¡el equipo era más simple en aquel entonces!). Debías asegurarte de no enviar un nuevo comando antes de que se completara el anterior, por lo que necesitaba una interrupción del temporizador para manejarlo, y un buen búfer circular de 512 bytes para que pudieras enviarle un montón de comandos de movimiento seguidos sin que el programa de espacio de usuario se bloquee.

Como no quería pensar en nada demasiado complicado, le envié números ASCII para decirle qué hacer, así que si imagina el teclado numérico en un teclado, le enviaría un 1,2,3,4 , 6,7,8,9 para moverlo un paso en las 8 direcciones disponibles o un 6 para bajar el lápiz y un cero para elevarlo. Todos los demás caracteres enviados al conductor simplemente se ignoraron.

Eventualmente lo puse a trabajar, y con la repetición de teclas en el teclado, puedes manejarlo a mano. Pero luego escribí una biblioteca de gráficos de espacio de usuario que podía hacer líneas, rectángulos, arcos de círculos y texto simple. El trazador eventualmente se volvió bastante útil más allá del trabajo básico que hice.

Fue un proyecto estupendo para alguien que nunca antes había estado tan cerca del hardware.

¡Pero la principal lección para llevar es COMENZAR CON UN CONDUCTOR EXISTENTE Y MODIFICARLO! Esto hace que todas las cosas de kernel-ish de ikky funcionen correctamente desde el principio, y esa es generalmente la parte difícil.

El problema que la mayoría de las personas encuentran al tratar de aprender la programación del controlador del dispositivo es la falta de dispositivos hw con los que jugar que tengan buenas descripciones de registro interno y lo suficientemente simple como para usar como un proyecto inicial.

Como muchas personas terminan programando algún tipo de controlador de hardware psuedo.

Mi primer ‘controlador de dispositivo’ fue esencialmente similar en su naturaleza. Fue un controlador que intentó implementar el mecanismo de IPC entre 2 o más procesos sin usar memoria compartida, sockets u otros mecanismos de comunicación entre procesos comúnmente disponibles.

Este proyecto me permitió aprender sobre métodos de comunicación entre aplicaciones y controladores, cómo manejar páginas, cómo mapear páginas en el espacio de procesos, cómo manejar colas de trabajo, cómo detectar la muerte de procesos y las limpiezas asociadas con eso, etc.

El controlador real basado en hardware no se materializó para mí hasta que comencé un trabajo real en el campo de la programación integrada y ese fue un controlador de pantalla.

No es realmente un controlador de dispositivo, pero tenía el mismo código que encontraría en un controlador de dispositivo de disco duro. Accedió directamente al archivo de tareas del disco duro. Sería el tipo de código de controlador que probablemente encontrarás en el BIOS.

Fue para el software de recuperación de datos que había escrito. Originalmente escrito para MFM, pero fue capaz de IDEar unidades. Dejé de desarrollarlo cuando NTFS comenzó a ser frecuente.

En realidad, acabo de recordar que derivaba mucho de ese código del código del archivo de tareas de la unidad de disquete que había escrito anteriormente.

En lenguaje ensamblador.

¿Cuál fue su primer proyecto de controlador de dispositivo y cómo lo hizo?

El problema al responder esto es que cuando estaba escribiendo mi primer disco de dispositivo, estaba escribiendo un sistema operativo desde cero. Así que utilicé el primer controlador (puerto serie) como vehículo para diseñar la interfaz de controlador de dispositivo muy tosca del sistema operativo. Fue un proceso iterativo: escribir un poco de código, tratar de generalizarlo para muchos dispositivos, ajustar la especificación de la interfaz, repetir. Eso significa que mi experiencia no es realmente relevante para cualquier sistema operativo que esté considerando ahora.

El consejo que puedo dar es solo familiarizarse lo más posible con la interfaz del controlador de dispositivo de su sistema operativo y con las capacidades de hardware de su dispositivo. Estos representan los dos extremos de su viaje. Ahora, como un satélite que traza una ruta para su viaje, debe unirse a los dos. Lo que significa probar algunas direcciones, elegir la que se vea mejor, seguirla de alguna manera y repetir. Mientras está dispuesto a volcar esa ruta y comenzar de nuevo con una dirección diferente si parece encontrarse con un pantano.

Si bien debe comprender los detalles de la API del controlador y de los registros del dispositivo, creo que es importante que comprenda el modelo en la mente de los diseñadores sobre cómo se utilizarían sus creaciones. Y, por lo tanto, cómo los usuarios del controlador modelarán el dispositivo en sus mentes cuando lo llamen. Un controlador es un mapeo de un modelo de hardware en un modelo de controlador. Se necesita código para implementar, pero lo importante es un mapeo natural, que es algo que debe resolver antes de escribir una línea de código.