TODOPIC
Microcontroladores PIC => Lenguaje C para microcontroladores PIC => Mensaje iniciado por: redep en 17 de Octubre de 2008, 16:34:10
-
Hola, estoy haciendo un proyecto en el cual una serie de variables cogidas por un pic son enviadas a traves de rs485 a un pic este las recoge, almacena y las vas mandando a un pc(rs232) mi problema llega en este segundo pic los pines de la usart deben ser los mismo para el max485 que para el 232 como puedo diferenciar entre las dos comunicaciones, perdonar mi ignoracia.
Hasta luego y gracias
-
Puedes usar una USART para el RS485 y otra para el RS232 para el PC, aunque podrias tambien declarar al PC como maestro en la RS485 y pedir directamente los datos desde ahi.
Saludos
-
Por lo que entiendo, el segundo PIC sólo tiene un puerto USART, es decir solo las terminales RX que viene de tu primer PIC (en RS485) y TX que va a la PC (en RS232). Si en el segundo PIC todo el tiempo estás solamente recibiendo con RS485, y todo el tiempo estás solamente transmitiendo con RS232, además de usar la misma velocidad en baudios para transmitir y recibir no le veo en donde está el problema. ¿para qué necesitas diferenciar las comunicaciones, o si puedes ser más específico en lo que intentas hacer?
Un saludo.
-
Yo hice eso con una sola USART conmutando los pines TX-RX TTL de la USART del PIC con un CD4053.
(http://publi.garcia-cuervo.net/USART_CD4054.jpg)
-
muy interesante arreglo redpic, nos queda descifrarlo (al menos yo no lo entiendo a primera :mrgreen: )
-
Hola.
Creo que es un multiplexor analogico
-
Si las condiciones siempre van a ser las mismas (recepción por RS485 y envío por RS232) no veo dónde estaría el problema de conectar el Rx del PIC al MAX485 y el Tx del PIC al MAX232, sin multiplexar nada.
-
Perdon por responder tan tarde mis pic´s son el 18f4550, como habeis entendido el rs385 tan solo iria en una direccion pero por otro lado el el rs232 conectado al ordenador ademas de recibir datos del pic tambien podra mandar ordenes, como por ejemplo (resetear el reloj), pedir un volcado total de la memoria.Ya que no siempre estara conectado al ordenador.
gracias por las repuestas.
-
En ese caso yo emularía una USART por software y no complicaría el hardware.
-
En ese caso yo emularía una USART por software y no complicaría el hardware.
Coincido pero yo le agregaría además un control de flujo por hardware con las señales RTS y CTS o DSR/DTR. El tema es que una usart por software, por lo general, no se implementan con timers e interrupciones y por ende, puede ocurrir que el PC quiera enviar algo y el PIC esté atendiendo otra cosa en ese momento (el RS485 u otra cosa).
-
El tema es que una usart por software, por lo general, no se implementan con timers e interrupciones y por ende, puede ocurrir que el PC quiera enviar algo y el PIC esté atendiendo otra cosa en ese momento (el RS485 u otra cosa).
Se puede implementar la USART por soft sobre RB0 u otra interrupcion para el pin de Rx, y asi quedarian las dos USART (hard y soft) cpn interrupcion de recepcion.
Saludos
-
El tema es que una usart por software, por lo general, no se implementan con timers e interrupciones y por ende, puede ocurrir que el PC quiera enviar algo y el PIC esté atendiendo otra cosa en ese momento (el RS485 u otra cosa).
Se puede implementar la USART por soft sobre RB0 u otra interrupcion para el pin de Rx, y asi quedarian las dos USART (hard y soft) cpn interrupcion de recepcion.
Saludos
No he dicho que no se pueda, por supuesto que hay formas, pero las usart por software implementadas en los compiladores no lo suelen hacerlo así, es más ni un timer siquiera usan. Incluso una vez recibido ese evento de start, hay que saber qué hacer, y allí de nuevo a usar un timer, apagar la interrupción del pin (para que no se vuelva a activar) y un sinfin de cosas que se simplifican si no se hace uso de eso.
Además, ni bien recibes un byte, debes prestar atención estricta a la comunicación por ende dejar de lado el rs485 ya que el sucesivo envío de bytes te obliga a ello.
Por otra parte, si el pic está procesando información del rs485, que debiera hacer, cortar la comunicación con el rs485 para atender algo más urgente como la comunicación con la pc? y si no es así? deberá la pc esperar y al rato volver a intentar?
El punto es que la complejidad aumenta y el usar una señalización por hardware agiliza la operación, simplifica el software, evita lidiar con la prioridad, etc.
Dado el contexto me pareció mejor proponerle a redep algo así, no digo que sea una regla de oro.
-
Haber maunix, estoy comenzando con esto de las comunicaciones asi que lo que pasa es que en cuanto se complica un poco me pierdo, segun algunos de vosotros monitorizando RTS y CTS o DSR/DTR, que son como flags para detectar si hay una comunicacion en proceso o si se esta listo se podra lograr un trafico ordenado no?.
Perdon por mi ignorancia y gracias a todos de nuevo.
-
Haber maunix, estoy comenzando con esto de las comunicaciones asi que lo que pasa es que en cuanto se complica un poco me pierdo, segun algunos de vosotros monitorizando RTS y CTS o DSR/DTR, que son como flags para detectar si hay una comunicacion en proceso o si se esta listo se podra lograr un trafico ordenado no?.
Si, sería eso. Luego tu defines una ventana de tiempo por ejemplo, el pic hace sus cosas por el rs485 o donde sea, y a partir de ahi cuando está libre se queda por ejemplo 100 mseg con el pin de DSR encendido. Si la pc lo lee (las pc son lentas para leer los puertos, si lo activas/desactivas en 10useg el puerto del pc es casi seguro que no lo leerá).
Entonces, al PC leer esa señal activada, responde con una señal similar (el DTR por ejemplo). En ese caso el pic lo lee de inmediato y sabe que no debe volver a monitorear todo el resto sino que esperará (un tiempo prudencial) si viene algún nuevo comando de parte de la PC.
Espero se haya entendido.
-
gracias, si ha quedao entendido espero que a la hora de la practica no me atranque.
-
bueno haciendolo ayer me surgio una duda, yo lo he conectado de la forma en la que aparece en el dibujo, entonces me pasa lo siguiente yo puedo determinar el valor de los pin de salida DTR y RTS para despues monitorizarlos pero las señales , DSR, CTS son de entrada para el pc como logro monitorizarlas en visualbasic.
gracias
-
Con MSCOMM existe el evento OnComm que se puede dispara cuando cambian esas señales, con comEvCTS y comEvDSR. O también puede revisar su estado con CTSHolding y DSRHolding.
-
gracias por todo
-
Hola a todos, soy nuevo en este foro y me gustaría retomar este tema, para empezar decir que es un placer estar aquí, y no me refiero en el sofá de mi casa ;)
muchas búsquedas del pasado finalizaron en este foro, y hoy necesito cerrar este hilo ya sea con la ayuda de alguien o con mi cabezoneria en lograr lo que busco.
Como este tema es antiguo me pregunto si es mejor contestar o crear uno nuevo, mi sentido común me dice que es mejor responder para no abrir hilos parecidos, de no ser así disculpas.
Necesito conectar una UART a un max232 y max485, de echo tengo dos UART pero cada una tiene de controlar su max232 y max485, y tanto TX como RX.
Tengo una electrónica en mi mesa que lo hace y después de mucho analizarla he logrado ver que los pines TX del PIC van en paralelo al RX del MAx232 y max485 sin mas, pero los pines de rx los pasan por un inversor not, y seguidamente por una puerta NAND donde una entrada va al TX del max232 y la otra al TX del max485 (ojo me refiero tx de los MAX es decir RX del PIC)
Y de esta manera funciona sin multiplexar ni jumpers.
Entiendo que la puerta NAND suma las señales y las nega, y después la vuelven a negar para que queden sumadas y sin negar.
Así que con una única puerta AND quizás se pueda hacer, el lunes haré pruebas y comento nuevamente.
Gracias