Autor Tema: Interfaz USB-DMX basada en DMX4ALL.  (Leído 94279 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado hume_86

  • PIC10
  • *
  • Mensajes: 2
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #15 en: 01 de Octubre de 2009, 23:18:21 »
Hola jmorfeo, gracias por contestar, el problema de los archivos lo solucioné, el tema es que yo usaba el C18 para compilar y no encontraba los archivos, ya instale el CCS y los puede encontrar, ahora me esta dando otros errores al compilar, los cuales no me he puesto a solucionarlos por falta de tiempo  :?. Cualquier problema o solucion que surga comentalo que puede ser de gran ayuda.
Saludos

Desconectado jmorfeo

  • PIC10
  • *
  • Mensajes: 10
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #16 en: 02 de Octubre de 2009, 11:10:52 »
Yo ya pude hacerlo funcionar pero con la versión del CCS 3.249  :-/, perocon la 4.093 no hay forma  :?. Estuve planteando la consulta en el foro de CCS y todavía nadie responde. Debe haber habido un cambio en los drivers y eso afecta al compilador.
Por otro lado se me cuelga el DMXcontrol despues de usarlo la primera vez y eso que soy prolijo y lo desconecto antes de cortar la simulación pero se ve que tiene problemas el programa, voy a probar con Freestyler a ver si tengo más suerte.
Me gustaría mejorar el programa de Khrnos usando la máquina de estados que dan en el AN1076. Habría que traducirla a C y antes probar con una comunicación USB CDC que ande diez puntos, una vez que logramos comunicarnos le agregamos el código DMX de transmisión que hay que probar antes solo, mandando unos datos de potenciómetros por ejemplo.
Comentame tu opinión, Saludos

Desconectado Khronos_Nieto

  • Colaborador
  • PIC10
  • *****
  • Mensajes: 40
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #17 en: 06 de Octubre de 2009, 23:32:08 »
Buenas compañeros !

Me alegra el saber que les puede ser util el diseño presentado.

He tenido este proyecto un poco aparcado por cuestiones de trabajo y porque me atranqué un poco en el tema de las interferencias. Hace poco he vuelto a retormarlo, ahora dispongo de osciloscopio y he podido ver que la tensión 220 AC de mi casa es un auténtico caos de interferencias, bueno, más concretamente algunos tubos fluorescentes son los causantes, ya que en el encendido meten un ruido tremendo.

Siguiendo los consejos de Manolo y Rafael he optoacoplado las salidas DMX + y DMX -, incluso sospechando de que las interferencias vinieran por la masa común, he colocado un convertidor aislado de DC/DC, de forma que toda la etapa de salida queda aislada eléctricamente del PIC. También he usado cable bueno (apantallado) de tan solo 10 metros y un terminador al final del bus. Los problemas se han suavizado, ya no ocurren tan frecuentemente, puedo tenerlo horas funcionando sin problema. Pero si enciendo y a apago los famosos fluorescentes insistentemente al final logro que se cuelge.

Ya se lo que pensareis "pon reactancias y cebadores electrónicos a esos fluorescentes y problema resuelto" pues llevais razón, es lo que debo de hacer. Pero me gustaría tener la tranquilidad de poder llevar mi equipo de luces a casa de un amiguete y que funcionase decentemente sin importar los ruidos eléctricos que existan en ese sitio.


Como última opción en mis investigaciones, estoy convencido de que el PIC se resetea por algún motivo. Probando he forzado un reset (hardware) y el efecto es el mismo que el de las interferencias, DMXControl se cuelga. Asumiendo que el PIC se va a "resetear de vez en cuando", estoy tratando de conseguir que el programa retome la conexión USB con el PC y que no se pierda el puerto serie virtual.

Actualmente esto no ocurre y sospecho que es porque al inicio del programa tengo puesto un "usb_init()", y esto hace que se quede esperando la inicialización del USB sin éxito, ya que ésta negociación ya se hizo al conectar por primera vez el cable al PC.

Mis conocimientos de USB con PIC son básicos y principalmente se basan en los ejemplos del compañero RedPic. Creo que algún otro compañero del foro ya hizo algo parecido a modo de "conexión/desconexión en caliente" por lo que voy a investigar.

Jmorfeo, me alegro que al final pudieses hechar a andar la simulación, estoy totalmente de acuerdo contigo en lo de conseguir una sólida comunicación USB CDC antes hacer cualquier otra cosa. Creo que yo también voy a tirar por ese camino. De todas formas la parte del código que controla la transmisión DMX creo que vá perfectamente. Yo tengo hecho una mini-mesa DMX con un PIC, utilizando este trozo de código para enviar comandos y va de lujo. Me encantaría de que compartieras tus experiencias o cualquier avance con el proyecto.


Un saludo !!  :-/ :-/ :-/
"Camaradas, ni nuestro propio conocimiento conoce nuestro potencial"
- La caza del Octubre Rojo -

Desconectado jmorfeo

  • PIC10
  • *
  • Mensajes: 10
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #18 en: 09 de Octubre de 2009, 00:04:42 »
Hola Khonos!! Te cuento que recién compro el 18F2550, Estuve haciendo las pruebas en Proteus y le bajé la velocidad del micro  a 16Mhz para mi PC no se muera y funciona ok con Freestyler pero con DMXControl se me cuelga el DMXControl. Solo queda enviando datos, se ve que no obtiene respuesta del PIC pero este sigue funcionando.
En realidad estoy armando la interfaz para probar un Receptor DMX de un trabajo que estoy haciendo con un 16F883, que controla leds RGB por 3 canales DMX y por otros dos le voy a pasar los datos para dos motores PAP (PAN y TILT) tipo scanner... y cuando pongo todo junto en proteus porque no tenía el PIC, no logro la recepción de los datos. Si verifico que los recibe el 18F2550 pero cuando reviso la trama DMX veo en vez de tener los dos bits de Stop de 8 us tengo 12 us aunque el dato sigue siendo de 4 us. De todos modos tengo que hacer mas pruebas ya que es muy probable que la falla sea de mi programa...
Tengo un ASM que me anda en la realidad con el que controlo los leds solamente, con un PWM por soft de un 16F628 que lee un DIP-Switch para saber  el canal DMX del primer color. Voy a probarlo de nuevo...
Con respecto al USB-DMX me gustaría que enviara los 512 canales para hacerlo completo y funcional. Y para esa cantidad de datos el programa se pone lento para la recepción USB, me parece. Yo creo que se podría trabajar con una versión traducida a C del código del AN1076 de Microchip que pongo antes y recibir USB por interrupción o meterlo entre medio de la máquina de estados de la nota de aplicación. Y mejorar la comunicación USB pero recién estoy aprendiendo a usarla. Aunque anda bastante bien... con Freestyler... por lo menos
Me parece bien las modificaciones de las aislaciones que hiciste pero me parece que si se resetea el micro puede ser por problemas de tensión, o patas en el aire, falta de capacitores de filtro de alta frecuencia en la fuente o falta de capacitores en la alimentación del PIC de 100nF.
Sigo sin saber porque no me anda el USB con la versión del CCS 4.093... alguna idea??

Saludos  :D :D :D

Desconectado Khronos_Nieto

  • Colaborador
  • PIC10
  • *****
  • Mensajes: 40
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #19 en: 14 de Octubre de 2009, 22:13:49 »
Buenas...!

Jmorfeo, me alegro que continúes con las pruebas. A mi si me funciona con DMXControl, no sé donde puede estar el fallo. ¿Seleccionas la interfaz DMX4ALL? ¿Seleccionas el puerto COM correcto?. Despues de esto debería dar OK al darle a verificar. De todas formas voy a intentar comprobarlo cambiándole yo tambien el reloj a 16 MHz.

Me parece buena idea adaptar la nota de aplicacion AN1076 para la transmisión DMX, no lo he probado con 512 canales pero quizás lleves razón y se vuelva lenta la ejecución. Tal y como está diseñado el programa, una vez que se pone a transmitir permanece en ese proceso hasta que acaba, y entre tanto pueden estar llegando nuevas tramas por USB. Haber si saco un poco de tiempo y lo miramos.

Respecto a porqué no te va con el CCS 4.093 no te puedo ayudar, yo uso el 3.235 y parece que va bien. Es una idea al aire pero ¿quizás sea porque los drivers y archivos descriptores no valen de una version a otra? Me refiero a estos "usb_cdc.h" y "descriptor_usb_dmx.h".

Un saludo!!  :-/ :-/ :-/
"Camaradas, ni nuestro propio conocimiento conoce nuestro potencial"
- La caza del Octubre Rojo -

Desconectado luiscolo

  • PIC10
  • *
  • Mensajes: 6
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #20 en: 11 de Marzo de 2010, 00:18:35 »
Estimado Khronos:

hace algo mas de un año tengo una interfaz dmx bidireccional que funciona conectada a la pc,
para no sumergirme en el mundo usb (cosa q ya tendre q hacer) la hice rs232
y me compre un adaptador usb rs232 de esos de mercado libre
desde el principio LA HICE OPTOACOPLADA, con dos fuentes de alimentacion independientes
(es decir dos trafitos, dos puentes de diodos, etc etc etc) y tres opto, uno para transmitir,
uno para recibir y uno para cambiar el sentido del transceiver
desafortundadamente, cuando la uso con el adaptador usb-232, al conectar algo en la misma zapatilla
se cuelga el convertidor usb232, lo q me recuerda tu problema
nunca pude determinar si se cuelga el pic, pero lo dudo
las luminarias q le conecto (de leds) tambien las diseño yo y tienen exactamente el mismo esquema de aislacion
y nunca dejan de funcionar
la unica mejora casi promisoria la obtuve al dejar de usar los usb del frente del pc y usar los de atras
por otro lado, aunque nunca hice una prueba estadistica, no recuerdo haber tenido problemas usandola en rs232
por lo que adjudique todos los problemas a una mezcla entre el puerto usb de la pc y el convertidor

lo que nunca logre explicarme es como el ruido pasaba a traves de donde hacia donde, ya que todo esta optoacoplado
espero saber si pudiste resolver el tema del cuelgue, porque quiero empezar con el usb y no quisiera sufrir
las desventuras de conectar algo y q todo deje de andar, ya que uso mucho las luces en eventos, y la linea ahi
si que es un verdadero desastre, por ahi 40 kw en par 1000 conectados a dimmers, moviles, etc etc etc

te mando un saludo enorme y gracias por compartir la info!
Luis

Desconectado Khronos_Nieto

  • Colaborador
  • PIC10
  • *****
  • Mensajes: 40
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #21 en: 11 de Marzo de 2010, 23:53:43 »
Buenas Luis,

Lo primero darte la bienvenida al foro y agradecerte el compartir tus experiencias y conocimientos.

Según comentas tu diseño de interfaz DMX está muy bien estudiada y protegida contra el ruido. En mis investigaciones sobre los fallos puntuales que daba la interfaz fuí siguiendo los mismos pasos que tu describes. Con los optoacopladores mejoró bastante la cosa, pero aun así se colgaba de vez en cuando, por lo que empecé a sospechar de cualquier fuente de ruido.

¿Por donde se cuela el ruido?
En mi caso descarté el ruido radioeléctrico, es decir, el que viene por el aire. A modo de prueba envolví el diseño en papel de aluminio (creando una jaula de faraday) conectado a tierra, pero los problemas persistían. Por tanto el ruido circulaba por cable.
 
Ya que las lineas de datos están optoacopladas, el único vínculo entre mi circuito y el bus DMX de los focos es la masa común. Pues bién me hice de un conversor DC/DC aislado galvánicamente (Texas Instruments los envía como samples), de forma que la masa de mi circuito y la masa del cable DMX que va a los focos quedara separada. Esto mejoró bastante la situación, ya era bastante dificil provocar el cuelgue del conjunto PC-Interfaz. Incluso sospeché de la propia alimentación de la interfaz (a través de una fuente convencional de transformador, puente de diodos y un 7805), por lo que lo alimenté con una pila.

Con todas estas medidas logré erradicar casi completamente el problema. Digo casi porque rara vez se colgaba la interfaz. De momento he desistido porque no se me ocurren nuevas ideas pero con los comentarios y experiencias como la tuya y de otros compañeros, se ayuda mucho a seguir la investigación. Mi objetivo es que tenga suficiente fiabilidad y robustez como para usarlo en eventos y espectáculos.

De todas formas estoy convencido que las Interfaces USB-DMX comerciales se tienen que colgar también...  :mrgreen: :mrgreen: :mrgreen:, con la diferencia de que esas te cuestan 400$ . En algún foro he visto comentarios de gente quejándose precisamente de eso.

Bueno, perdona por una introducción tan extensa, en base a lo que ya sabemos se me ocurre lo siguiente:

1 - Estoy completamente de acuerdo contigo en que el PIC no se cuelga, no obstante se podría comprobar manteniendo un led encendido al inicio del programa.

2 - Quien se cuelga es el puerto serie "virtual" que crea el PIC o el adaptador RS232-USB en tu caso.

3 - Tiene que ser un cuelgue muy rápido porque si observas el Adminstrador de dispositivos de Windows, este puerto "virtual" sigue existiendo tras el cuelgue.

4 - Una posible solución sería arreglarlo mediante programación. En mi programa PIC una vez hecha la rutina de inicialización del USB, asumo que la conexion serie existe y me dedico a leer y escribir sin preguntar si realmente "sigue existiendo dicha conexión". Cuando por un espacio de tiempo ese puerto virtual "no exista" debido al impulso de ruido, cualquier intento de acceso fastidiará el asunto. El problema de esto es que la parte del PIC se podría solucionar, pero.....nuestro querido DMXControl solo comprueba el puerto en el arranque, despues se dedica a leer y escribir.

5 - Lo que comentas de los puertos USB delanteros y traseros de tu PC me ha hecho reflexionar. Tengo entendido que en un PC algunos puertos USB dan mas corriente que otros, casualmente los traseros dan más corriente. La prueba está en que algunos discos duros portátiles USB llevan dos conexiones USB, una de datos/alimentación y otra de solo alimentación. Dependiendo del PC o del puerto al que lo conectes es necesario enchufar solo el cable de datos/alimentación, o conectar los dos porque "le falta corriente" y necesita un apoyo.

Creo que aquí esta el quid de la cuestión, pudiera ser que la desaparición momentánea del puerto virtual fuese provocada por un "sobreconsumo" en el puerto. En esta situación el PC corta el suministro de corriente a este puerto para protegerse, y lo reestablece cuando cesa el sobreconsumo. Esto es exactamente lo mismo que desconectar el cable USB y volver a conectarlo!! Desaparece el puerto serie virtual y tiene que volver a ser creado, pidiendo descriptores... etc... y todo esto con el PIC y el DMXControl a su rollo pensando que no ha pasado nada...!!

¿Puede el ruido ocasionar ese sobre consumo? No lo se, pero quizás si que haga caer la tensión Vcc de 5v del USB lo suficiente. ¿Por donde se cuela? Pues no queda otra que a través del propio PC, cuesta creerlo porque si hace eso como va a seguir el microprocesador del PC tan tranquilo, pero no le encuentro otra explicación.

Mi siguiente paso va a ser poner un filtro de red al enchufe del PC.

Bueno, perdona de nuevo por el rollo, espero que mis comentarios te puedan ser de ayuda. Por último aclarar que no todo es tan negro, mi caso particular es bastante problemático ya que ese fluorescente que me provoca tantos problemas en mi casa es una auténtica factoría de ruido. Con decirte que si enchufo cualquiera de mis montajes justo en el enchufe que hay debajo del tubo fluorescente, cada vez que enciendo el tubo se cuelga el microcontrolador, sea cual sea...jejje  :lol: :lol:. No creo que esto sea muy normal en cualquier casa o local..!! Tengo mucho tubos a lo largo de mi casa y solo me pasa en ese.... es un caso muy extremo pero me niego a cambiarlo, es un auténtico laboratorio para el estudio de ruido  :mrgreen: :mrgreen: :mrgreen: :mrgreen:..

Espero sinceramente nos sigas comentando tus avances.

Un saludo compañeros.

"Camaradas, ni nuestro propio conocimiento conoce nuestro potencial"
- La caza del Octubre Rojo -

Desconectado stk500

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 4923
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #22 en: 12 de Marzo de 2010, 04:38:25 »
Muy buena vuestras informacion, pero hay algo que habeis olvidado y es las masa comun y la toma de tierra, porque una PC en este caso, tiene su masa directa a la toma de Tierra, yo recomiendo si va a comandar con este protocolo, recomiendo un DMX- BOOSTER, estos aparatos de compone de diferente entradas y Salidas de Bus con Optoa acopladores, osea un HUB, el caso comenta el amigo Khronos sobre lamparas florecente y los ruidos, es debido que todos florecente hacen ruidos y a veces es por laas conexiones interna del florecente,, algunos fabricante de lampara recomienda un cableados cubrirlo con metal, y toma de tierra que no falte nunca, ahora la pregunta de todos estos es,
ha revizado cada aparato de tu casa sobre fallos de impedancias? Habeis medidos la toma de tierra con el Diferencia?
pues todos esto hay que tener en cuenta cuando se usas un grupos de aparatos conectados a una Fase o diferente Fases, otros factor con el USB, si lo usan en un SHOW recomendar usar una alimentacion externa al USB, asi no sobrecargan el Bus USB de la PC.

Saludos

Desconectado luiscolo

  • PIC10
  • *
  • Mensajes: 6
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #23 en: 16 de Marzo de 2010, 01:28:27 »
Estimados Khronos y Rafael:
Aca les adjunto un esquema de la interface (si es que el foro me permite agregar una mas en este tema).
Disculpas por lo tonto del esquema, pero me parece que va a ser claro.

Una de las posibilidades de las que desconfio es de la caja metalica,
tengo muy presente que alguna interfaz comercial es bien de plastico.

Ya he construido una de plástico yo tambien, pero ahora que me decido a probarla,
al driver del conversor usb-rs232 se le dio por hacer que el windows muestre esa odiosa pantalla azul.

En cuanto logre hacerlo funcionar posteo los resultados, incluyendo puertos delanteros y traseros del cpu.

Por otro lado, he llegado a pensar en la posibilidad de pasarme a un puerto ethernet,
ya que no logro confiar ni el el puerto usb en si ni en los drivers de windows,
aunque hoy he pasado el dia consultando y veo q es una tarea algo... trabajosa!

Bueno, pronto posteo, un abrazo!
Luis

Desconectado todopic

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3495
    • http://www.todopicelectronica.com.ar
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #24 en: 16 de Marzo de 2010, 15:25:33 »
Hola Luiscolo, tienes conectada la resistencia de 100-120 ohm en la salida RS485?
Ademas, donde dices "la malla no esta conectada", tendrias que conectarla con una resistencia de unos 10 a 100 ohm

Suerte!

Norberto
Firmat - Santa Fe - Argentina

www.TodoPic.net

Solo se tiran piedras, al arbol que tiene frutos...

Desconectado luiscolo

  • PIC10
  • *
  • Mensajes: 6
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #25 en: 16 de Marzo de 2010, 22:26:56 »
Hola Norberto, gracias por tu aporte,
Si, el bus esta armado segun la especificacion 2.3, 2.4, 2.4.1, 2.5 y 2.5.1
del documento original de la ESTA para RDM (terminadores, biasing, etc)
Por otro lado el transmisor es asilado, por lo cual cae dentro del Anexo A.1
de documento original del USITT para DMX.
Esta decision es porque el riesgo de descarga electrica en un transmisor no aislado
es alto, sobre todo si el transmisor se conecta en una toma sin descarga a tierra;
y porque por otro lado, al estar conectado a la PC o la notebook, cualquier falla de asilacion
en cualquier dispositivo de la red terminaria conectando la masa de las compus
a uno de los dos polos del enchufe, (falla bastante habitual en muchos dimmers por cierto)
lo cual sumado a que la mayoria de los cables "dmx" no respetan la asilacion entre masa y carcaza
terminaria en una catastrofe (de esas que vez cuando te traen para reparar dimmer, splitter, consola
y moviles, todo de una sola vez)

Por otro lado, he probado el adaptador usb->rs232 en la interface con gabinete plástico,
y por cierto no me llevó mas de dos enchufadas al 220 para que deje de funcionar,
al igual q lo que explicabas Khronos, el puerto no se desmonta del administrador de dispositivos
pero la unica forma de poder volver a reconocerlo es desconectarlo y conectarlo nuevamente,
Por otro lado, y que he olvidado mencionar antes, el mouse usb (que esta en el enchude usb de al lado)
tambien se cuelga, aunque no tanto como el adaptador 232, y tambien es necesario desenchufarlo y volver a
enchufarlo para que ande nuevamente.

Finalmente, he probado con el puerto serie directamente y no he logrado que nada deje de funcionar,
lo cual sigue desalentandome a confiar en un usb para esta tarea; deberia consultar con algunos amigos si las
interfaces comerciales (esas de plastico azul traslucido muy bonitas) tienen este mismo problema;

por otro lado, ya he instalado el wireshark y he empezado a mirar las tramas ethernet,
no parece tan descabellado ni taaaan inalcanzable,
he llegado a imaginar un router con una interface y dos computadoras a la vez :D
al estilo de los nodos de la "mama grande" :D

Bueno esto es todo por ahora, y me alegra haber entrado al foro (es la primera q participo en uno)

Saludos, Luis

Desconectado Khronos_Nieto

  • Colaborador
  • PIC10
  • *****
  • Mensajes: 40
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #26 en: 24 de Marzo de 2010, 21:07:08 »
Buenas compañeros..!

Lo que comentas Luis de hacerlo a través de ethernet suena muy muy bien.!! Habría que estudiar el tema, mis conocimientos en ese área son muy limitados. Estaré atento a tus progresos. Por cierto, veo que estas padeciendo los mismos "cuelges" del puerto serie virtual que yo, es para volverse loco..! Sería muy interesante que tu que conoces gente del mundo del DMX y la iluminación espectacular, preguntaras lo de que tal van las interfaces USB comerciales. Por lo menos si también fallan, como decimos por aquí "mal de muchos, consuelo de tontos" :D :D :D

Estoy completamente de acuerdo con lo que comenta Rafael, se debe buscar al culpable de los ruidos, a veces por mucho que quieras protejer a tu circuito, es imposible hacerlo inmune a todo tipo de interferencias y hay que actuar sobre el "causante".

Un saludo.!
"Camaradas, ni nuestro propio conocimiento conoce nuestro potencial"
- La caza del Octubre Rojo -

Desconectado luiscolo

  • PIC10
  • *
  • Mensajes: 6
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #27 en: 26 de Marzo de 2010, 02:35:29 »
Buenas amigos!

Tema USB:
Justamente hoy he avanzado un poco en la experimentacion del malvado cable usb-serial:
la fuerza de la necesidad me llevo a lograr instalar un driver que funcione (sin pantalla azul) en mi compu de escritorio
y a instalarlo en la portatil ya que el lunes debo ir a programar a lo de unos clientes.

Ya que tenia todo funcionando, hice el ensayo en la portatil, y para mi sorpresa no logre colgar el puerto en la netbook,
he hecho casi un maremoto de conexion/desconexion y ni pestañeo! es decir, siguio funcionando perfectamente!
Agrego q es una netbook bastante... (emmmm low profile?) economica :) de esas q vende acer con pantalla de 11.6,
con lo cual no es que tengo la re calidad de hardware en esa maquinita, (o sera que si?)
Para colmo de males la portatil estaba con el cargador conectado y cargando,
y la alimentacion de la interface estaba tomada de un puerto usb de la maquina,
asique mucho optoacoplador pero la misma masa :D

Finalmente desenchufe y me vine a la pc de escritorio (los puertos del frente) y rapidamente logre que deje de funcionar.
Entre la frase anterior y esta que escribo ahora (2.10 am jeje) ensaye los puertos traseros de la pc de escritorio
(misma interace tomando los 5 V de la pc) y tuve varios resultados interesantes:
el primero es que nunca se colgo el puerto serie, es decir que nunca dejo de funcionar,
y el segundo es que recibia algunos caracteres extraños por el puerto durante las conexiones/desconexiones
cosa que para estas instancias no me parece tan grave, sobre todo tomando en cuenta que la fuente switching de los
leds hace unos chispazos bastante poderosos cuando la conecto!

Bueno hasta aca el tema usb por hoy, me resisto a descartar esos puertos (al menos aun!)

Pasando al tema Ethernet, tampoco soy un experto, mas bien soy menos que principiante;
ademas, asi como me reconozco muy buen programador en assembler, el C es casi un agujero negro para mi,
aunque me vengo entrenando porque ya veo que no tengo otra chance, pero me falta entrenar muuucho aun :)

Sin embargo he aprendido bien el protocolo ethernet y el ip, y algunas generalidades del arp y otras menudencias que andan por alli, ya que si buscas sobre ethernet nadie dice nada que no empiece con tci/ip, asique he leido todo lo q pude.

Parece ser que hay dos opciones:
la pila tcp/ip de microchip y los modulos de tibbo: aunque los primeros salen bastante menos y parece ser que
tambien hay que trabajar bastante mas, aun no me decido pero me gustaria saber que piensan ustedes.
Y por ultimo me pase del visual 6 al 2008 (previa discusion con windows de 6 horas para poder instalarlo)
ya que es una herramienta libre con lo cual no habra que esconderse para usarlo, y de hecho trae el mscomm y el winsock,
los que he probado y funcionan a la perfeccion (segun la define microsoft jeje), de hecho he podido enviar y recibir
paquetes tcp y udp entre las maquinas y he mirado todo el trafico con el wireshark y se comprende perfecto!

Debo admitir que el ethernet me tienta mas:
no necesita drivers, y se puede configurar el producto desde cualquier navegador (al estilo de los routers) con solo poner la direccion ip!

Bueno espero sus opiniones a ver que les parece, y perdon por el largo del post :D

Un abrazo!
Luis

Desconectado piovi

  • PIC10
  • *
  • Mensajes: 5
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #28 en: 19 de Junio de 2010, 18:28:28 »
Buenass!! he buscado muuucho un circuito como este y la verdad que esta muy bueno, quisiera saber si alguien lo hizo y funciona correctamente, sin ofender perdon...
y descargue de el link para bajar el proyecto que pusiste, pero no estan los valores de las resistencias ni de casi ningun componente en el esquema y realmente me gustaria mucho poder hacer este circuito! si alguien me puede contestar...   muchiiisimas gracias por todo este esfuerzo, Saludoss!

Desconectado Juanm

  • PIC10
  • *
  • Mensajes: 5
Re: Interfaz USB-DMX basada en DMX4ALL.
« Respuesta #29 en: 02 de Julio de 2010, 13:39:05 »
Buenass!! he buscado muuucho un circuito como este y la verdad que esta muy bueno, quisiera saber si alguien lo hizo y funciona correctamente....y descargue de el link para bajar el proyecto que pusiste, pero no estan los valores de las resistencias ni de casi ningun componente en el esquema....

funciona si, lo hice, tube que cambiar la parte del transiver, que use un SN75176BP, pero anda lo mas bien

las resistencias, meti una de 10k en el reset, y la parte de los led no la arme, pero se calcula por ley de ohm teniendo en cuenta que los leds comunes tienen de 2 a 2.8v de caida, y una corriente de 25 a 30mA, asi que con 5V maximos que le puede suministrar el pic (el voltaje USB es de 5v, por eso digo que son 5v max) te queda entre 3 y 2.2V que tiene que haber en la resistencia por lo que dijo el viejo kirchoff, asi que quedaria R=2.5V/0,025A (redondeo a 2.5V y tomo la Iminima que es 25mA o 0.025A) tonces quedan resistencias de 100 ohm, para trabajar en lo seguro ponele una de 220 o mas (tampoco tanto que si no ni prende)

los capacitores que van al lado del cristal son de 22pF o 33pF (es lo que puse yo) para estabilizarlo, si no se ponen funciona igual (mejor ponerlos)




ahora pregunto yo



lo quiero modificar para 512 canales, no se programacion (estoy aprendiendo lo basico pero en pascal)

segun estube viendo, hay que modificar en la parte del codigo que dice esto:
Código: [Seleccionar]
/************************************************************************
*                          RUTINA PROCESA                               *
************************************************************************/
void Procesa(){

Envia_Break();
Envia_Start();

indiceTX = 0;

while (indiceTX < 16){                // En este bucle se envían los 16 canales de datos
   if (TXIF==1){
      TXREG = TramaDMX[indiceTX];
      while (TRMT == 0){}
      indiceTX=indiceTX + 1;
   }
}


while (indiceTX < 100){             // En este bucle se envían el resto de canales, forzados a 0.
   if (TXIF==1){                    // No es obligatorio enviar los 512 canales que dice el protocolo,
      TXREG = 0x00;                 // nosotros solo utilizamos 16, sin embargo existe un tiempo mínimo entre
      while (TRMT == 0){}           // el comienzo de una trama y el comienzo de otraq ue hay que cumplir.
      indiceTX=indiceTX + 1;            // A efectos prácticos, se podrían enviar tramas de tan solo 24 canales (no menos),
   }                                // con lo que se conseguiría un refresco mas rápido.
}                                   // En nuestro caso enviaremos tramas de 100 canales para ir sobre seguro.
                                    // De estos 100 canales, 16 tendrán datos válidos recibidos por USB y los restantes se fuerzan a 0.
delay_us(100);


}


si lo cambio a esto:

Código: [Seleccionar]
/************************************************************************
*                          RUTINA PROCESA                               *
************************************************************************/
void Procesa(){

Envia_Break();
Envia_Start();

indiceTX = 0;

while (indiceTX < 512){                // En este bucle se envían los 16 canales de datos
   if (TXIF==1){
      TXREG = TramaDMX[indiceTX];
      while (TRMT == 0){}
      indiceTX=indiceTX + 1;
   }
}


//while (indiceTX < 100){             // En este bucle se envían el resto de canales, forzados a 0.
//   if (TXIF==1){                    // No es obligatorio enviar los 512 canales que dice el protocolo,
//      TXREG = 0x00;                 // nosotros solo utilizamos 16, sin embargo existe un tiempo mínimo entre
//      while (TRMT == 0){}           // el comienzo de una trama y el comienzo de otraq ue hay que cumplir.
//      indiceTX=indiceTX + 1;            // A efectos prácticos, se podrían enviar tramas de tan solo 24 canales (no menos),
//   }                                // con lo que se conseguiría un refresco mas rápido.
//}                                   // En nuestro caso enviaremos tramas de 100 canales para ir sobre seguro.
//                                    // De estos 100 canales, 16 tendrán datos válidos recibidos por USB y los restantes se fuerzan a 0.
delay_us(100);


}


funcionarian todos los canales?? (los 512)
o hay que modificar algo mas??


vi en una parte que decia
Código: [Seleccionar]
/************************************************************************
*                         RUTINA DE INCIALIZACIÓN                       *
************************************************************************/
void Inicia(){

// Inicia variables.

for (aux=0;aux<16;aux++){
   TramaDMX[aux]= 0x00;

ese aux<16 tengo que cambiarlo tambien?? y en algun otro lado???


perdon por todas las preguntas, y espero alguien me pueda responder


saludos y gracias desde ya



Edit: aca subo 2 imagenes, de la parte de las pistas y una superior con los componentes, se puede hacer de distinta forma y mas chico, pero lo hago a mano y me da pereza hacer las pistas mas chicas :P



« Última modificación: 02 de Julio de 2010, 13:56:33 por Juanm »