El otro día me encontré con un problema, estaba utilizando un programa que no sabía que hacía (y el código empeoraba más la situación) y necesitaba conocer los protocolos de comunicación que estaba usando para comunicarse (por puerto serie). La solución más sencilla hubiera sido la de pinchar en otro puerto serie y abrir el hyperterminal para espiar la comunicación, pero me encontraba con un problema, sólo tenía un puerto COM. No me quedó más remedio que agenciarme otro PC y trabajar en paralelo con los dos (un engorro).
Claro pero si en vez de una comunicación serie hubiera tenido una paralelo, o un I2C o un SPI o incluso un USB no habría podido interpretar los datos de forma sencilla (ver las señales si porque tenemos un osciloscopio de señal mixta que para estas cosas va genial). Así que añadí a la lista de proyectos por hacer un Analizador lógico que además pueda interpretar protocolos.
Para esto voy a hacer un hardware dedicado que recoja las señales y las envíe al PC y un software que las visualice y las interprete.
En este caso la dificultad del proyecto radica más en dónde poner el límite, me explico, el proceso de funcionamiento es sencillo de entender, cuando hay un evento (generalmente una señal de trigger) se inicia una captura de muestras mediante un reloj externo o interno.
El método más sencillo de implementar esto es mediante un microcontrolador al que se le inyecta las señales directamente (bueno, directamente no que primero hay que adaptar los niveles de tensión)... pero aquí empiezan los problemas.
Si usamos con un PIC18F4550 (por coger un micro sencillo y rápido con comunicación USB y muchos puertos para leer) podríamos usar la interrupción de teclado (KIB) como reloj externo, y las interrupciones exteriores (INT0, INT1 e INT2) como disparadores. Podríamos usar la velocidad máxima del micro 12MIPS (a 48MHz), para leer y su 2K de RAM para guardar los datos.
Pero claro, cada interrupción consume como mínimo 10 ciclos de reloj más las operaciones de lectura de cada puerto puerto son 2 ciclos más, que en total por 4 puertos (el puerto C no lo contamos) son 2*4+10 = 18 ciclos lo cual nos deja una velocidad de captura de tan sólo 660kHz (12Mciclos/s / 18ciclos = 666666.66Hz aprox 660kHz), suficiente para el puerto serie, pero insuficiente para un I2C o un SPI. Eso sí tendríamos 26 señales de lectura de las cuales 4 podrían ser clocks y 3 disparadores con el clock interno (si usamos sólo el puerto B y el D tendríamos 16 señales a 850kHz también insuficientes).
Por otro lado el micro tiene 2Kb de RAM para guardar datos, si las usamos capturando únicamente los puertos B y D (2 bytes) a 660kHz obtendremos que hemos capturado únicamente 1.5ms (2Kb * 1captura/2bytes * 1s/660kcapturas = 1.5515e-3s aprox 1.5ms). Además los 2Kb de RAM no se van a usar exclusivamente para la captura de señales, también hay datos de programa que guardar, variables, etc.
La solución en sí no es mala (para alguien que sólo va a capturar señales lentas y cortas), simplemente que se aparta de las expectativas que yo tenía.
La opción cara sería señales de entrada optoacopladas, pudiéndose elegir los niveles de comparación para la decisión de un nivel alto y uno bajo, con una memória generosa, muestreo rápido y 32 señales de entrada cada una pudiéndose elegir como señal normal, disparador(trigger) o clock externo (lo que es un analizador lógico comercial).
Entre estas dos opciones hay para elegir una buena cantidad...
S2
Ranganok Schahzaman
No hay comentarios:
Publicar un comentario