Requisitos del driver de la practica:

Requisitos del driver de la practica:
Propósito:
El driver sirve para comunicar un programa de usuario (aplicación) con un dispositivo ADC (conversor
analógico digital) con cuatro canales. La precisión de cada canal es de 8 bits.
Método de comunicación:
El driver comunica con el programa de aplicación utilizando la interrupción 61h.
Los parámetros de entrada son en los registros CL, AL y AH.
AH siempre señala la función que va a ejecutarse.
CL siempre es el número del canal de ADC utilizado (de 0 a 3).
AL sirve como complemento de AH.
Los resultados son en los registros AH, AL y CX.
En AH es el estatus de ejecución. Con una excepción el significado de AH es:
AH = 0 la función terminada con éxito.
AH = 1 error en los parámetros de la llamada.
AH = 2 parámetros de llamada fuera del rango permitido (ejemplo – pedir datos de canal 10).
AH = 3 dispositivo ocupado o error en el orden de la secuencia de comandos.
AH = 80h datos todavía no disponibles.
AH = 0FDh – canal no activo.
AH = 0FEh -- dispositivo no disponible.
AH = 0FFh – datos caducados (desbordamiento del buffer interno)
En AL se encuentran los datos del canal correspondiente.
En CX se encuentra en contador del reloj en respecto con el tiempo requerido de la transformación en us.
Descripción detallada de la interfaz del driver:
Funciones:
De servicio:
AH=0FFh – desinstalar el driver.
AL=0
-- sin salir del programa
AL=0FFh – con terminación del programa (int 21h/ 4c00h).
AH=0FEh – comprobar la presencia del driver.
Retorno: AX=055AAh – el driver esta instalado.
AH=4 – pedir parámetros del driver:
AL=0FFh
Salida:
AH – status
AL = b0 canal 0 ocupado, b1 canal 1 ocupado, b2 canal 2 ocupado etc.
CX – periodo de transformación.
De manejo del reloj:
AH=0 – Cambiar el periodo de petición de datos.
AL=0 – valor fijo y reservado.
CX
-- Periodo de petición de datos en us.
De manejo del dispositivo:
AH=2 – Activar el canal
AL=0 – sin borrado del buffer,
AL=1 – limpiando el buffer.
CL
-- número de canal 0…3.
AH=3 -- Desactivar el canal CL.
AL=0 – sin cambio del buffer,
AL=1 – limpiando el buffer del canal.
CL
-- número de canal.
AH=1 – pedir datos del canal CL.
CL
-- número canal.
Salida:
AH – status
AL – datos (si AH=0).
CX – tiempo transcurrido desde el tiempo en que debería hacerse la lectura de datos y el tiempo de
lectura de los datos en ciclos básicos del reloj (4.77MHz/4)
Funciones opcionales:
AH=10h – pedir el buffer DS:SI de DI datos, CL
-- número canal
DS:SI – el buffer destino de datos. Cada dato ocupa 3 bytes. Primer byte – el dato, segundo y tercer byte
– el tiempo de retraso del dato (skew). DI – número de datos pedidos.
Retorno:
AH – status
CX – número de datos leídos.
AH=0, AL=1, BL – canal, CX useg. – cambiar el periodo de pedido de datos para cada canal por
separado.
Estructura del driver:
El driver tendrá tres partes comunicando entre sí:
A. Parte de manejo del int 61h.
B. Parte de manejo del tiempo.
C. Parte de manejo de la interrupción del dispositivo (LPT1).
Además el driver tendrá una parte de instalación/desinstalación.
A. Int 61h:
Activación: Por llamadas de la aplicación.
Función: proporcionar interfaz de la aplicación y el driver.
La parte de int 61h controla las otras dos partes. Lee los datos de los buffers del driver y les proporciona
al usuario (la aplicación). También desinstala el driver, liberando TODOS los recursos ocupados.
B. Manejo del tiempo:
Activación: Periódica, del mismo reloj del sistema.
Función: Inicializa la petición de datos del primer canal que se va a leer.
La parte del manejo del tiempo controla el reloj del sistema con objetivo de pedir datos del ADC con un
periodo constante. Esta parte pide solo el primer dato. Los datos de los demás canales se piden en orden
consecutivo de la parte que maneja las interrupciones de LPT. Si el dispositivo no funciona y la parte que
maneja el tiempo recibe interrupciones consecutivas del reloj sin recibir ningún dato, se supone que el
dispositivo no esta instalado.
C. Manejo de la interrupción del puerto paralelo:
Activación: Por interrupciones del ADC.
Función: Guardar el dato recibido y el skew (el reloj) en el buffer.
Activar la petición del siguiente canal si precisa.
Si el buffer cíclico desborda, sobreescribir los datos mas antiguos y la situación se señala a la
aplicación con la siguiente petición de datos.
Métodos de comunicación entre los partes del driver:
A -> B Cambiando los parámetros del driver (memoria). También activando el periodo del reloj.
A -> C Cambiando los parámetros del driver (los canales que precisan de leer y los punteros de los
buffers de datos).
C -> A Buffers cíclicos de datos con correspondientes punteros.
B -> C Con los registros del dispositivo B arranca C, también al inicializar C se pone un flag que sirve
para señalar sí el dispositivo este presente.
C -> B No hay transfer de datos, salvo un flag que señala que se ha producido la recepción de datos.
Desarrollo en practicas 1, 2 y 3.
Practica 1:
El driver (simulador del dispositivo) se proporciona del profesor.
La aplicación se desarrolla en ensamblador y su propósito es de presentar los datos en modo texto en la
pantalla. La aplicación es interactiva y se desarrolla top-down. Las partes que no están por desarrollar
primero se sustituyen con dummies, después con stubs y finalmente con funciones de verdad.
Practica 2:
Se desarrolla el driver y el dispositivo. Al desarrollar el driver el dispositivo puede sustituirse con un
dispositivo dummy (un conductor entre ACK y INIT es suficiente). El método top-down no es lo mas útil
posible, por la dependencia del hardware. Es muy difícil para gente sin experiencia desarrollar todo a la
vez, porque cada error en la parte de las interrupciones de hardware para la maquina. Por tanto es
consejable la siguiente secuencia de desarrollo:
1.
2.
3.
4.
5.
6.
Utilizando debug o TASM animar el dispositivo, pidiendo los datos a mano o con programas muy
simples.
Desarrollar un programa en ensamblador sin utilizar las interrupciones que pide los datos del
dispositivo y les proporciona al usuario (en ensamblador).
Desarrollar un nivel falso de la interfaz del usuario (int 61h) que pide directamente del dispositivo un
dato con polling.
Utilizando las interrupciones del dispositivo (LPT) realizar el mismo funcionamiento como en el
punto anterior.
Desarrollar el manejo del tiempo utilizando la interrupción 1Ch (el tick mínimo será de 55 ms).
En este punto tendremos suficiente experiencia para desarrollar el driver entero.
En practica 2 la aplicación será escrita en ensamblador y es la misma como en la practica 1.
Practica 3:
El driver es el mismo como en practica 2.
La aplicación se desarrolla en parte en ensamblador y en parte en C. Es deseable la representación
gráfica de los datos del dispositivo. La parte de la aplicación escrita en ensamblador será la mínima
posible y sirve para interacción entre el driver y la aplicación. No están permitidas ejecuciones y capturas
de las interrupciones del reloj, del teclado o del LPT escritas en C.