Idioma:
English
Digicam
weeCam
Interno
Principio
Sensor
Protocolo
Analizador
Programa
Pruebas
Temas:
Vuelo 2(bis)
Vuelo 3(bis)
Vuelo 4
Teoría
Otros globeros
Hice algo de trabajo preliminar espiando el funcionamiento de los drivers de Windows, esperando ahorrarme algo de tiempo, pero aparentemente Alaris no confia en Microsoft, ya que hace su propio manejo del puerto paralelo, puenteando dos drivers del sistema operativo. Intenté desensamblando el código, pero perdí la paciencia cuando vi todo el código duplicado que tenian los drivers.
Próxima parada, intentar de capturar el flujo de datos por hardware. En un primer intento, traté de insertar otra computadora entre la PC y la cámara, simulando un puerto ECP 'lento', y manipulando las líneas de control para frenar la velocidad. Funcionó solamente parcialmente. Algún límite de tiempo en el driver no me permitió de capturar suficiente información.
Entonces, el último recurso: diseñé un circuito capturado con memoria propia (32 kB para líneas de control y 32 kB para los datos). Una vez adquiridos los datos, se descargaban a otra máquina. Una suerte de analizador de estados lógicos de bajo presupuesto. Fue un circuito bastante espectacular.
Este método finalmente dió resultado. Aunque no me fué posible de adquirir imágenes completas del tamaño mas grande, recolecté suficiente info como para deducir la parte mas grande del protocolo. Por lo menos tanto como para permitirme escribir un programa simple para controlar la weeCam y bajar imágenes.
Al iniciarse, la computadora - mas correctamente, el sistema operativo - interroga al puerto paralelo con una combinación de señales que únicamente reconocen los artefactos capaces de procesar la norma IEEE-1284. Entre la información intercambiado en esta faz de configuración, se intercambian varios datos, entre los cuales, una cadena de letras que constituye una identificación del periférica hacia la computadora. Además, el mismo periférico le comunica a la PC, si es capaz de trabajar en los modos EPP y/o ECP, y si será capaz de enviar datos en forma comprimido (norma RLL).
La norma IEEE también prevé la posibilidad de hacer cadenas de equipos conectados en 'serie' al mismo puerto, como fue popular en la época inicial de los scanners.
Entonces, si un sistema operativo tiene capacidad para la IEEE-1284, sera capaz de reconocer los artefactos conectados, aún si no tiene los drivers o el programa de aplicación instalado.
Nota para los desarrolladores: la librería libieee1284 (ver referencias) es una herramienta invaluable para acelerar el desarrollo de programas para el puerto paralelo en modo IEEE1284, ocultando efectivamente todos los detalles del acceso de bajo nivel.
Este no es el lugar para describir detalladamente el protocolo ECP.
Cualquier navegador le llevará seguramente a lugares con mejor
información sobre el tema. Lo incluyo nada mas que para hacer mas
estructurada la descripción del protocolo.
En el modo ECP hay cuatro posibles situaciones de transferencia de datos. Las entidades que se comunican pueden ser ó Datos o Comandos. Además tenemos dos direcciones de comunicación: 'Forward' de la PC al periférico, y 'Reverse' del periférico a la PC.
Son las combinaciones de las cuatro líneas HClk y PClk (relojes) y HAck y PAck (confirmación) que determinan el tipo de información que se está transfiriendo y la dirección. Las señales 'H' son generadas por el 'Host' (la PC), las 'P' vienen del periférico.
|
Considere el primer gráfico (los otros son similares): Si el host
(la PC) quiere enviar datos, debe ponerlos en las líneas de datos,
y activar la línea HClk (con HAck en 1). El periférico confirma la
recepción activando PAck, lo que permite al host de desactivar HClk.
PAck desaparece, y el ciclo reinicia.
Normalmente, no es tarea del programador, el manejar estas líneas, sino de los drivers del sistema operativo. Pero si desea conectar la cámara a un microcontrolador, tendrá que generar estas secuencias 'manualmente'. |
| (c) John Coppens ON6JC/LW3HAZ | correo |