Haz una pregunta
  Foros de Electrónica » Temas de Interés » PC Hardware
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

05/03/2006 #1


Comunicar dos microcontroladores a PC por RS485
hola quiero saber como hago un programa QUEme comunique a dos micontroladores a mi pc, la idea es QUE por el puerto serial de mi pc me conecto atreves de un interface QUE se convierte en un RS485 (ese harware ya lo tengo ) pero no se como hacer el codigo para comunincar mis microntroladores QUE envien y reciban datos desde mi pc y se muestren en pantalla les agredesco de ante mano por la ayuda
09/03/2006 #2

Avatar de EinSoldiatGott

En C por puerto paralelo sería primero leer el puerto

inportb variable
printf("%d", variable)

Es todo lo que te puedo decir ya que tus especificaciones de frecuencia de lectura o cuanto duran los datos en el puerto, etcétera no los especificas.

Saludos
12/03/2006 #3


com leo datos de un 485 en C
no lo QUE pasa es QUE tengo QUE leer mis datos en una red 485, se como configurar el puerto en C ese no es problema se como convertir de 232 a 485 pero esto tiene QUE ir a un microcontrolador pero estos tiene nivel de ttl lo QUE "NO SE" es como registro mis datos (es decir enviar y recepcionar datos )de los micros en mi pc si salgo con rs232 y lo convierto a DH485 la fecuencia de envio y recepcion lo hago por prgrama y eso es lo QUE me falta
12/03/2006 #4

Avatar de EinSoldiatGott

Re: com leo datos de un 485 en C
eca dijo:
no lo q pasa es q tengo q leer mis datos en una red 485, se como configurar el puerto en C ese no es problema se como convertir de 232 a 485 pero esto tiene q ir a un microcontrolador pero estos tiene nivel de ttl lo q "NO SE" es como registro mis datos (es decir enviar y recepcionar datos )de los micros en mi pc si salgo con rs232 y lo convierto a DH485 la fecuencia de envio y recepcion lo hago por prgrama y eso es lo q me falta
Compañero, estaba yo muy fuera de tema, creí que un 485 era el micrcontrolador, ahora se que no .

Entonces si mal no comprendo, su problema es de software, dentro de su pc, lamentablemente nunca estudié bases de datos, que es lo que creo que usted necesita, lo mejor será esperar a que algún informaciónrmático lea su post o consultar en google o en foros especializados en programación hay uno muy bueno de C mismo que no puedo mencionar pero seguro lo conoce.


Saludos y espero le vaya bien con su proyecto
11/04/2006 #5


Re: Comunicar dos microcontroladores a PC por RS485
eca dijo:
hola quiero saber como hago un programa q me comunique a dos micontroladores a mi pc, la idea es q por el puerto serial de mi pc me conecto atreves de un interface q se convierte en un RS485 (ese harware ya lo tengo ) pero no se como hacer el codigo para comunincar mis microntroladores q envien y reciban datos desde mi pc y se muestren en pantalla les agredesco de ante mano por la ayuda

Hoal, soy nuevo en esto, tal vez pueda ayudarte en algo si aclaras un poco el tema, en lo particular estoy terminando un desarrollo en el que una PC se comunica con hasta 32 microcontroladores via una red Rs-485.
Que microcontralador estas usando o usaras?
Espero tu respuesta, un abrazo
Rick
12/04/2006 #6


Hola amigo
Ya que tu mencionas el RS485 ,me gustaria saber todo acerca de ese tipo de protocolo,pues deseo trabajar con el ,deseo crear un tipo de cable basado en ese tipo de protocolo, y si pudieses ayudame con eso,,mira,necesito conectar una camara USB a mas de 20 metros y alguien me dijo que haciendo un tipo de cable asi lo podria lograr,,me gustaria que me asesoraras ya que veo que tu estas mas empapado del asunto.Desde ya te agradezco.
12/04/2006 #7


veran en realida les explico el proyecto:
este consiste en la conexion de 2 microcontrolaodres a una red 485 , QUE estaran conectados al puerto serial de mi pc QUE sera el maestro, (esto implica usar un interfase de 232 a 485).

Bueno los interfases (uso convertidores de max232 y max485)y los microcontrolaodres ya los tengo(estan echos en base al pic 16f873).
Uno de los micros sensara la temperatura de un ambiente y esta sera mostrada en un pantalla lcd QUE estar conectada al puerto paralelo de la pc . El otro microcontrolador movera un motor DC la velocidad de este ser a controlado por un potenciometro QUE tambien estara conectado al puerto paralelo del pc(impluica el uso de un ADC,QUE tambienlo tengo).

Ahora ustedes se pregusntaran y por QUE no lo haces si l tienes todo ,bueno es QUE es primera ves QUE trabajo ocn este protocolo,el lenguaje q uso es el C en modo DOS y com veran necesito saber como progarmar el RTS del puerto serial y saber com direcciono los datos a mis micros.
El tipo de comunicacion es half duplex y la velocidad de transmision es d 19200 pero eso es irrelevante.bueno si alguien me puede ayudar genial se lo agradecere de ante mano les prometoQUE una ves QUE lo termine lo cuelgo en el foro para QUE les sirva a alguien bueno gracias de nuevo suerte a todos .
para bryan
bueno amiguito haber en QUE te puedo ayudar parece q necesitas primero un interfase de para QUE uses el usb y trabajes conel 485 ya QUE este tiene niveles de voltaje QUE nno son tipo TTL ,ademas necesito saber QUE es lo QUE tienes QUE hacer exactamente .
Veras el 485 es un tipo de red industrial en el QUE se puede conectar 32 nodos es decir 32 estaciones y la distancia puede llegar a 1200 mt com maximo,tienes QUE tener en cuenta QUE la red485 trabaja con señales balancedasy QUE ambas sesñales son opuetas y complementarias ,bueno espero QUE me deje entender si no es asi me abisas y tratare de ser mas explicito bueno haber si me cuentas tambien QUE es lo QUE quieres hacer bye suerte y paciancia (se QUE falta pero hay qUE tenerla)
13/04/2006 #8


Porque no le das una mirada a este link, de seguro responde tus dudas.

http://www.forosdeelectronica.com/viewtopic.php?t=282

Saludos.
15/04/2006 #9


Hola Eca

Tal vez te puedas dar una idea bajando una demo de comunicacion serie de este link, http://www.compt.ru/, yo lo baje y me dio resultado.
Dese el colocaba datos en hexa para comunicarme con mi micro. El tema de RTS, yo todavia no lo tengo muy claro, pero lo hare en VB6, usando el MSCOM, que te brinda cantidad de elementos para trabajar con el puerto serie.
Respecto del link que te paso, lo estoy usando en mi desarrollo y me dio una gran mano, al menos hasta que llegue el momento de meterme con el soft de la PC.
Eso si no olvides que cada uno de tus micros, en realidad son estaciones o nodos conectados a una linea RS-485, debes darle si o si una direccion, d emodo que cuando el PC interrogue sepa quien debe responder, yo estoy trabajando bajo la forma Master / Eslave, en la que el Master interroga a los esclavos.
Recorda que RS-485 es un protocolo a nivel fisico, tu debes desarrollar el soft para tu aplicacion, es decir que el soft que corre en la PC, esta en concordancia con el soft de cada uno de los micros.
En cuanto a la maxima distancia de 1200 metros, es asi, pero eso tambien depende de la cantidad de nodos y de la velocidad seleccionada para trabajar. Hoy ya hay dispositivos capaces de permitir mas de 32 nodos en la linea.
Saludos.
19/11/2010 #10


Mensaje para Rick o para el que quiera contestarme:

Trabajo con un pic18f4550 y envio datos a un pc a traves de un max 232. Todo el circuito está integrado en una pcb. Como ahora van a haber más equipos, necesito que la comunicación sea a traves del 485. Los datos que envío son del estilo de temperatura, tensión, corriente, etc y mí pregunta es como enviar los datos, ya que hasta ahora me limitaba a hacer varios printf. También dispongo de un conversor 232-485 para adaptar los niveles de tensión.
Espero que alguien me responda o que me indique un lugar en el que pueda encontrar código en C.
Saludos.
07/02/2011 #11

Avatar de axe512

Hola a todos, les comento que estoy “desarrollando” una red con pic 16f876A usando sn 75176. Entre dos pic todo esta bien la comunicación entre ellos es buena la complicación surge cuando conecto el conversor rs232 a rs 485 y desde el pc quiero enviar datos a uno o al otro. Lo que tengo en mente pero no se como hacerla es una rutina en assembler que es el lenguaje que uso. Es para leer en el inicio del programa del pic un dipswitch de 4 teclas conectado a RC0, RC1, RC2, RC3 que me genere un número binario y almacenarlo en un registro del pic para identificar cada uno de ello, tiene que ser en esto pines porque los restantes del puerto C esta conectado el sn75176 y en el puerto A tengo pulsadores, encontre una rutina que leen todo el puerto completo pero no puedo usarla porque en mi proyecto RC4, RC5, tienen un dipswitch que cambian el estado de los pulsadores del puerto A a modo tecla y RC6, RC7 esta el sn75176. Les agradezco si alguien puede darme un empujoncito para armar una rutina que lea los 4 primeros pines sin afectar el funcionamiento de los restantes.
Saludos.
AXE512
04/03/2011 #12


Pienso que el problema al que muchos se refieren es COMO hacer para manejar el conversor 485 desde la PC. rs485 es una norma half-duplex, eso implica que hay que poder elegir en qué momento se transmite, en qué momento se recibe... O puesto en modo más científico, cuándo el transceiver 485 está en modo transmisión (cuando está en modo transmisión, no se puede recibir nada) y cuándo está en modo recepción.

La PC saca rs232, que es full-duplex. DE ahúi va a un conversor 485, que es half duplex. En el medio, hace falta algo que diga cuándo el conversor 485 debe transmitir, y cuándo debe de recibir.

Lo que usualmente se hace, es abusar de alguna línea auxiliar del puerto serie de la PC para indicar qué es lo que tiene que hacer. Usualmente, se usa la línea RTS, pero controlada por software.

La idea, es poner la línea a 0 (o a 1, dependiendo del adaptador rs485 usado!) para poner en modo transmisión el conversor 485, y en el estado inverso para ponerlo en modo recepción. Pero hay que advertir varios problemas acá:

No es posible conmutar RTS por cada byte transmitido (8 bits+ bit start + bit stop, usualmente), porque entre bytes, si ninguno de los tranceivers 485 que están conectados al bus está en modo TX, la linea queda "suelta" ... Es decir, el nivel que está en la línea es completamente indeterminado. Y como ningún transceiver la maneja, se nos meterá ruido.

Ese ruido, es captado por todos los transceivers que están en modo RX, que lo pueden llegar a interpretar como un bit de start, lo que les hace perder el sincronismo a las usarts que están conectadas al mismo.

Por eso, es importantísimo que RTS (que es la que controla el transceiver) se mantenga durante todos los bytes que componen un paquete y mientras se transmiten completamente todos ellos, en el modo correcto para que esté en modo TX el transceiver.

También es importante, de hecho, validar los paquetes recibidos... PAra asegurarse que el primer byte sea el inicio realmente de un paquete... para asegurarse de la integridad de los datos...

En líneas generales, para que un protocolo como el 485 sea explotable en forma correcta, los paquetes de información deberían ser del estilo

|MAGIC|ADDR|LEN| ...... |CKSUM|

donde MAGIC es un valor único poco probable que se dé en los paquetes, que indica el inicio de un paquete. Por ejemplo, yo uso 0x5A (=01011010)
ADDR = Dirección del nodo al que va destinado el mensaje
LEN = Largo del paquete en bytes, sin incluir MAGIC,ADDR,LEN y CKSUM
.... Representa una cantidad LEN de bytes a transmitir (sería el payload del paquete)
CKSUM = Un checksum de todo el paquete, sin incluir MAGIC ni CKSUM

Para transmitir este paquete, tendríamos que usar un algoritmo similar a éste:
1) Activar RTS para poner el transceiver en modo TX
2) Esperar al menos el tiempo de transmisión de un byte y medio al baudrate que usamos. Este tiempo es realmente necesario, para permitir la estabilización de los niveles de tensión de la línea 485, y además, resincronizar todas las UARTs que están conectadas al bus 485 de los nodos que están escuchando el bus. Usando un byte y medio de tiempo, nos aseguramos que si por un problema de ruido alguna UART estaba recibiendo basura, la termine de recibir completamente, y quede esperando correctamente el bit de start del MAGIC del paquete que vamos a enviar
3) Transmitir el paquete completo
4) ESPERAR a que realmente se termine de transmitir el {ultimo BIT del último BYTE del paquete. Esto es MUY importante, ya que muchas UARTs tienen un buffer de transmisión y transmiten en segundo plano. Por eso es tan importante ver la forma de esperar. La UART de PC tiene un bit que indica cuándo está IDLE, o sea, terminó de transmtir. Idem casi todas las UARTs que conozco. Y en el peor de los casos, usar una demora suficientemente grande
5) Sacar RTS para pasar a modo escucha el transceiver RS485

Para la rutina de recepción la idea es la siguiente
1) Leer un byte
2) Si no es MAGIC, volver a 1 (probablemente es ruido en la línea, o estamos mal sincronizados=
3) Leer ADDR -- Validar que esté en rango... Acá no se valida que sea la dirección de nuestro módulo, sólo que el valor sea un valor válido., Por ejemplo, con 32 módulos, ADDR debería ser siempre menor a 32. Si no lo es,volver a 1.
4) Leer LEN --- Validar que el largo sea menor o igual al máximo posible para el paquete con la longitud más larga. Si no lo es, volver a 1.
5) Leer los bytes del payload (LEN bytes)
6) Leer el checksum y verificar que coincide con el calculado para los datos. Si no coincide, volver a 1
7) Si llegamos acá, verificar ADDR para ver si se trata de un mensaje dirigido a este mmodulo. Si no lo es, volver a 1. El motivo de verificar ADDR acá es no perder el sincronismo en la comunicación. Así sea que el mensaje no fuera dirigido a nosotros, necesitamos saber cuándo mirar el bus para encontrar el próximo inicio de paquete (byte=MAGIC) para no perder el sincronismo en el flujo de paquetes.

Además de todo ésto, deberíamos pensar en algún mecanismo de reintento de la transmisión si un módulo no contesta, y en un mecanismo de timeout para la recepción de la respuesta, si el módulo direccionado no responde por alguna causa.

Para la implementación en la PC, el algoritmo de transmisión es el complicado de implementar, porque requiere tiempos relativamente exactos en el manejo de RTS. Lo primero que necesitamos es que el lenguaje que usemos para programar admita el control directo de RTS. La gran mayoría lo admite, pero no todos.
Lo segundo que se necesita, es saber cuándo se terminó de transmitir el {ultimo bit del {ultimo byte. Eso es más complejo, hay lenguajes que no nos permiten saber eso. Otros cuentan con una primitiva flush() que sirve para forzar que todos los bytes salgan, pero no garantiza que se haya transmitido el {ultimo bit... Y en otros, la primitiva flush() hace exactamente lo que necesitamos. Programando a bajo nivel (DOS) podemos leer el bit de la UART que nos da esa info, por lo que es implementable.
Y el tercer problema, que puede ser o no irresoluble, es qué tanto tiempo tarda el lenguaje usado en pasar el transceiver del modo TX al modo RX, desde el momento en que el último bit se transmitió. Eso es un problema, porque el módulo que responde a nuestra petición puede llegar a ser demasiado rápido en responder, y comenzar a transmitir la respuesta antes que el módulo que transmite libere el bus.
Para eso, las 2 {unicas posibles soluciones son, o usar un lenguaje más rápido para el que transmite, o colocar una demora antes de que el módulo que responde inicie la respuesta. Ambas pueden o no ser viables.

Enfin, espero que les haya dado una idea de los problemas y las soluciones necesarias, y el porqué de las mismas

Saludos
Eduardo
04/02/2013 #13


Hola como estan? Ando de foro en foro tratando de ver como solucionar el problema que se me planteo. Veras estoy haciendo mi tesis de grado.
Se los resumo: necesito conectar varios pics (14) a una PC, que la pc controle cuando reciba los datos . Hasta el momento (ignorante yo) estaba usando RS232 y creia que con este protocolo podia conectarlos, pero no lei que no admite redes multipunto como tengo yo.
Mi pregunta es : ¿Estoy en lo cierto? . Hay que cambiar algo en la programacion del USART del pic? o simplemente con un adaptador rs232-rs485 bastaria?
Desde ya muchas gracias!!!
19/04/2013 #14

Avatar de COARITES

http://picmania.garcia-cuervo.net/pr...ele485-628.php

http://www.neoteo.com/rs485-domotica...-tu-mano-15810

Yo estoy en lo mismo; si lo logro te aviso y si lo logras avisas.
20/04/2013 #15


Hola COARITES, al final pude por RS232, no se si te sirve. La idea se basa en enviar cada ciertos milisegundos, numeros del 1 al 10 a traves del bus ( lo hago por labview). El pic solo contesta si el numero que recibe es el que corresponde. Para ello en la programacion cuando se produce una interrupcion por puerto serie, tomo el valor que llega y si corresponde, envio los datos. Sino, envia el pic que corresponda. No se si entendiste la idea. Avisame
21/04/2013 #16

Avatar de COARITES

Si entendi, la logica que manejas es misma que la mia; en mi caso un microncontralador esclavo se encuentra a 100 metros; asi que solo puedo usar rs485, de momento me estoy haciendo mi interfaz de rs232 a rs485; y ademas decir que en ccs existe un libreria para enviar datos por rs485 con su respectivo ejemplo.

Asiq que si todo me sale bien, ya estare conpartiendo la informacion.
25/05/2013 #17


Hola COARITES ! . Finalmente me tuve que pasar a rs485. Estuve montando el circuito de cada PIC con un rs 485 y un conversor RS485 a rs232 para la comunicacion con la pc. Estoy hace mas de dos semanas sin recibir nada. De la unica forma qUE recibo algo en la compu, ( pero nada qUE ver con lo que mando, recibo siempre 00h) es cruzando A y B del bus. Vos pudiste lograr algo? SAlUdos
11/07/2013 #18

Avatar de COARITES

Existe un ejemplo en CCS es: ex_rs485.c se ve facil; pero siempre hay complicaciones jejeje...

Para la comunicacion entre pics tendrias que comprarte el sn75176 este es un integrado que convierte de rs232 a rs485.

Suerte!
Respuesta
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Buscar más temas sobre:
Lupa PC Hardware

Sección destinada a sistemas electrónicos utilizados en la informática.

Cerrar
Foros de Electrónica » Temas de Interés » PC Hardware

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.