ViejuLCD USB

Ya tengo el prototipo del ViejuLCD versión USB, he preparado el PCB y todo correcto a la primera. Ahora mandaré un par de ellos a un par de compas de vieju.net para que desarrollen software del lado del PC.

viejulcd-protousb-2La idea es hacer un servidor de datos al LCD, que implemente una cola y a la que las aplicaciones que quieran hablar con el LCD se conecten por sockets y dejen el stream de texto/comandos que quieran mandar. Asi no habra conflictos de bloqueo entre las aplicaciones si dos toman el control del puerto al mismo tiempo. Luego tenemos pensado desarrollar varios clientes,  para datos del sistema, notificaciones, etc.

En el lado XT, la idea de JoJo, es hacer un programa residente de DOS (TSR), que capture ciertas interrupciones para recabar datos del sistema y asi enviarla al LCD. Con esta técnica se podria incluso usar el LCD de pantalla externa, capturando las interrupciones necesarias.

Yo he estado haciendo un pequeño demo, para probar los comandos implementados en el firmware del LCD, y la verdad, ha sido un éxito.

Lo programé en ruby, toma el control directamente del puerto, y hace una serie de pruebas del firmware, texto, scroll, niveles de brillo, activacion/desactivación, etc.

Podeis ver un video del demo a continuación:

7 opiniones en “ViejuLCD USB”

  1. Me parece muy interesante le proyecto.

    He visto proyectos semejantes para controlar un display por RS232 pero el software estaba programado en PHP para incrustarlo en aplicaciones web, (por ejemplo, aunque se puede hacer en Ruby como bien demuestras).

    Incluso había pensado pillar un display Skytronic, pero para el (no)uso que le voy a dar en mi caso es tirar el dinero.

    Ánimo con el proyecto.

  2. Genial proyecto! Desconocía que os habíais metido a hacer algo así, mola un cojón! A demás estoy pensando en varias utilidades que podría dársele, y se me cae la baba :D

    Estaremos al tanto!

    PD: Vaya demo de pantalla más scener, ahí todo friki hasta con caracteres en japonés y muñequito bailingo xD

  3. ¿Ahora que lo pienso, no es un desperdicio hacerlo por sockets? ¿No se puede usar una tubería normal y corriente? De las de toda la vida.

    Vale si el demonio que gestiona el LCD está en una máquina y desde una aplicación le quieras mandar cosas para displayar, por ejemplo desde una web y tengas un display gigante en mitad de la Gran Vía con publicidad a medida (y de pago).

    Pero en una misma máquina una “pipa” de las de toda la vida es mucho más rápida que hacerlo con “soquetes”

  4. Mi idea es que más de una aplicación pueda acceder al servidor, se conecte, y el servidor lanze un thread, y en ese thread reciba el stream, que por medio de un buffer vaya pasando a una cola unica que va mandando datos al LCD, asi si por ejemplo una aplicación te quiere mandar un aviso, y hay otra aplicación usando el display, el mensaje no se pierda y cuando termine la tarea actual lo recibes.
    De hecho estaba pensando incluso establecer un sistema de prioridades en el protocolo, para que un stream pueda tomar control inmediato del LCD.
    Creo que va a ser el mejor diseño, además de que esto permitirá como dices conexiones por red desde otras máquinas.

  5. En resumen,un demonio gestiona una cola en la que se añaden mensajes. Ese demonio escucha en un lugar intentos de conexión, los valida y si son válidos los pasa a la cola.

    Un programa o una rutina va cogiendo el primer elemento de la cola y lo va displayando, espera el tiempo estimado que tenga que esperar y pasa al siguiente mensaje mientras que la cola tenga mensajes.

    La cola puede ser cualquier cosa que tu quieras, el clásico FIFO de UNIX (las tuberías que se crean con el comando mkfifo), una cola MQ o Spazio (si pagas las licencias, o lo que tú te hagas, (más barato y satisfactorio).

    ¿Algo más o menos así, verdad?

  6. Pingback: ladecadence.net

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *