Muchas gracias por los comentarios compañeros, se agradecen sinceraménte.
He estado testeando el interfaz durante varios días y he encontrado dos problemas que hacen que no funcione correctamente.
Problema 1:El primer problema es que no funciona con el programa de DMX, FreeStyler 512. Aunque dicho programa te permite seleccionarla interfaz DMX4ALL, la mi circuito no envía tramas DMX. He estado "espiando" las tramas que envíaeste programa y resulta que son completamente distintas que las que envía DMXControl. ¿Como es posible?
Estuve navegando y entré en la página oficial de DMX4ALL:
http://www.dmx4all.de/, que resulta ser puramente una tienda en internet. Pues bien, para mi sorpresa ví que está disponible la documentación que explica el protocolo de comunicación y los comandos aceptados por DMX4ALL. ¡Bien! ¡¡Y yo aqui montando puentes entre puertos COM para espiar lo que envían los programas, cuando resulta que está todo en la página oficial!!
La documentación se puede encontrar aqui
http://www.dmx4all.de/media/manuals_en/DMX412_Mini-USB-DMX_en.pdfTras revisarla y hacer unas pequeñas pruebas, concluí que el formato de datos que usa FreeStyler 512 es el mismo quese explica en la página oficial DMX4ALL, por tanto es el auténtico, y el formato que usa DMXControl es otro distinto, aunque en el programa se llame DMX4ALL.
Aunque se explica en la documentación, a modo de resumen la trama "original" DMX4ALL (la que usa FreeStyler 512), tiene la siguiente forma:
//Byte: 0 1 2 3 4 5 6 7
// " 43 31 34 30 4C 30 31 31 "
//
// Donde:
// - El byte 0 es el byte de inicio de trama, siempre es 0x43.
// - Los bytes 1, 2 y 3 son el canal seleccionado, en formato ASCII, de mayor a menor peso.
// - El byte 4 es un separador y siempre es 0x4C.
// - Los bytes 5, 6 y 7 son el valor a asignar, en formato ASCII, de mayor a menor peso.
//
// En el ejemplo anterior se envia el valor "11" (30-31-31), al canal 140 (31-34-30).
Espiando los envíos de FreeStyler se podemos comprobar que las tramas son así.
He modificado el programa del PIC y ahora soporta también este protocolo. Las tramas de DMXControl y FreeStyler son completamente distintas por lo que uso dos rutinas de decodificación distintas. ¿como distinguir en que programa estamos para usar una u otra? Pues sencillo, al arranque de cada programa se envía una trama de 2 bytes a modo de reconocimiento. Estas tramas son distintas, para el caso de DMXControl es:
0x63 - 0x3F y para FreeStyler:
0x53 - 0x32.
Según la que reciba, conmuto a un modo u otro.
Es cierto que en la documentación del protocolo se explican distintos comandos ante los cuales la interfaz tiene la obligación de responder con un ACK (0x47), pero en mis pruebas con FreeStyler ví que él, no exige nunca una respuesta, de hecho ni siquiera al establecer comunicacion por primera vez (como ocurre con DMXControl). FreeStyler es menos exigente, en cuanto arranca (y siempre que exista el puerto COM asignado) comienza a enviar tramas ante los cambios de los potenciómetros virtuales, no exige ninguna respuesta, por lo que le da igual lo que haya conectado al otro lado de la línea, el manda tramas sin parar.
Por este motivo yo solo he implementado la parte de decodificación de la trama, y funciona, aunque queda "pendiente de hacer" proximamente.
Modifico el primer post, adjuntando el nuevo código modificado. Comprueben en la simulación que ya funciona con FreeStyler.
Problema 2:El segundo problema es mas preocupante, durante las pruebas a la interfaz hechas con DMXControl (me sigue gustando más que FreeStyler), he comprobado que funciona durante 2 o 3 minutos correctamente y luego se cuelga. Los focos se quedan en el último estado que envié, y el software se queda medio colgado, no responde a los comandos y tengo que cerrarlo. Entonces, sin desconectar la interfaz, vuelvo a arrancar DMXControl, pero ahora me salta con un mensaje de "Puerto COM no disponible". Sin embargo me voy al administrador de dispositivos y puedo ver que el puerto COM virtual sigue presente, y windows no indica que exista ningún problema de hardware. Vuelvo a cerrar DMXControl y abro el programa de comunicación serie Siow (el que trae CCS), y tampoco me deja abrir dicho puerto serie.
Todo esto me ocurre a los 2 o 3 minutos de funcionamiento correcto de DMXControl. Otra cosa que he intentado cuando dá este fallo es desconectar y conectar la interfaz sin cerrar DMXControl, pero tampoco se soluciona. La única forma es apagando el programa, desconectar y conectar la interfaz, y volviendo a arrancar el programa, entonces todo va perfecto durante otros 2 o 3 minutos.
Creo que el problema reside en que en algún momento se pierde la comunicación serie, lo suficiente como para que se cuelgue DMXControl. En el código del PIC he cambiado la forma de control del USB de la siguiente forma,
Este es el código original:
usb_init(); // Inicializo USB
usb_cdc_init(); // Inicializo como dispositivo serie virtual CDC
while(!usb_cdc_connected()) {} // Espero hasta la conexión USB
for(;;){
if (usb_enumerated()) { // Espero que el dispositivo sea reconocido como emulador serie CDC
if (usb_cdc_kbhit()){ // Compruebo si hay recepción USB
-------
-------
-------
}
}
}Y este el modificado:
usb_init(); // Inicializo USB
usb_cdc_init(); // Inicializo como dispositivo serie virtual CDC
while(!usb_cdc_connected()) {} // Espero hasta la conexión USB
for(;;){
if (usb_cdc_kbhit()){ // Compruebo si hay recepción USB
}
}
La diferencia es que ahora no pregunto contínuamente si el dispositivo está enumerado, asumo que sí. Con esta modificación he conseguido que el interfaz no se cuelgue cada 2 o 3 minutos. Conecto todo, arranco el programa y lo pongo a funcionar, ahora funciona correctamente todo el tiempo.
Pero me ocurre una cosa aún peor, estando funcionando todo correctamente, me levanto de la silla y me dirigo a la habitación de al lado y le doy al interruptor de la luz para encender los tubos fluorescentes ¡¡ y el muy cabr.... se cuelga!!
¡Tengo un problema serio de ruido electromagnético! Pero no me explico como puede provocar estos efectos. Creo que no se trata de Windows XP, ni de DMXControl, ni problema de drivers ni nada, creo que el problema lo causa el PIC, que se resetea. De hecho le he provocado reseteos voluntarios y ocurre exactamente lo mismo. Tengo montado el circuito exactamente como se muestra en el esquema que adjunté, pero he de aclarar que utilizo un cable DMX de 10 metros hasta el primer foco, y otro de 15 metros desde éste hasta el segundo. Imagino que esto constituye una antena gigante para captar ruido eléctrico, y entendería que los focos no respondieran bién a los comandos, pero ¿colgarse el PIC?.
Según tengo entendido la unica forma de resetear el PIC es cuando cae la tensión de alimentación, ¿entonces cae la alimentación del puerto USB? ¿Puede ser por un exceso de consumo por parte de mi circuito, justo en el momento de encender los tubos fluorescentes? En ese caso el puerto USB cortaría la alimentación para autoprotegerse, y podría explicar el problema. Pero la verdad es que no quisiera alimentar externamente mi circuito, y más sabiendo que existen interfaces USB-DMX comerciales que se alimentan del USB y funcionan perfectamente.
He tomado varias medidas:
- conectar el chasis del conector USB al chasis del conector DMX
- soldar un cable entre masa y el cuerpo del cristal de 12 MHz
- colocar ferritas en el cable USB y justo a la salida del cable DMX
Pero sigue ocurriendo lo mismo, cuando enciendo las luces fluorescentes de la habitación de al lado, falla el circuito. Me queda por aislar el PIC, de la parte DMX, es decir, del MAX488. Según he visto en algunos esquemas utilizan optoacopladores en la línea de datos entre el PIC y el MAX488. Incluso para un mejor aislamiento llegan a utilizar convertidores DC/DC, para la alimentación del MAX488. No lo he probado todavía por no tener optoacopladores tan rápidos (250 Kbaudios).
Òjala esto solventase mi problema, aunque me parece una solución demasiado drástica, y mas bién orientada a la protección de los puertos USB de nuestro querido PC, que a evitar cuelgues del microcontrolador.
Con todo esto quizás no vaya por el camino correcto para encontrar la solución, a lo mejor solo se trata de un problema en el firmware del PIC.
Ya finalizo con 2 preguntas, disculpen la extensión del post, espero que no se les haga aburrido.
La primera pregunta es respecto al ruido, ¿como puedo protejer correctamente el circuito? Las medidas que he adoptado han sido un poco por intuición propia, y sin criterio alguno. Me gustaría conocer el consejo de algún compañero experto.
Y la segunda pregunta va dirigida a los compañeros del foro curtidos en USB: asumiendo que el PIC se va a resetear "de vez en cuando", ¿habría alguna forma de que el PIC retomara las comunicaciones como si no pasara nada
?, es decir, que no hubiera que reestablecer la comunicación USB, inicializar, enviar descriptores... etc, y ¿como le sentaría esto al PC, suponiendo que es un corte de pocos milisegundos?
Muchas gracias compañeros por la paciencia para leer esto, gracias de antemano y un saludo
!!!
