rs485 a rs232

[carlos cabas]

Hola compañeros estoy realizando un proyecto para comunicar los protocolos rs485 con rs232, en la imagen adjunta esta la forma de onda de la señal convertida de diferencial a ttl, pero no logro decodificar qué información es, pues al no tener un reloj para observar cuantos bits son y el estado de los mismos.

Si conocen algo del tema por favor les agradezco cualquier ayuda, todas las opiniones son bien recibidas.

Gracias.

[Alfredo Siárez]

Hola Carlos
Podrías dar mas información?, lo que muestra el osciloscopio es lo que
envía algún equipo comercial?,
salvo que tenga alguna codificación como NRZ o algo raro, el bit time
debería ser el de los pulsos mas delgados, cuánto vale ese tiempo? Antes
de las transiciones la señal está en cero un tiempo largo; cuánto es ese
tiempo? antes está en uno? Cuando terminan las transiciones la señal queda
en uno? si es así cuanto tiempo?Esa señal es demasiado corta como para
poder descifrar algo, pero si nos pasas los tiempos tal vez se pueda hacer
algo.

Atentamente. Alfredo

En Wed, 09 Oct 2013 17:21:38 -0300, carlos cabas
<ing.car...@gmail.com> escribió:

--
Usando el novísimo cliente de correo de Opera: http://www.opera.com/mail/

[Fernando Lichtschein]

Coincido con Alfredo, creo que apunta para empezar, a determinar si la transmisión es sincrónica o asincrónica. En el segundo caso, la señal debería permanecer en 1 lógico entre caracteres. No se ve bien (o soy chicato) la base de tiempo de la medición.

¿Es de un equipo comercial? Esto también ayudaría.

Saludos,

Fernando

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Edgardo de avila]

Oh, Ingeniero Carlos Cabas un placer saludarlo, en mi tesis de pregrado utilice el protocolo RS485, este utiliza una trama de la siguiente manera:
DESTINO | FUENTE | LONGITUD-DATOS | DATO[1] | DATO[2] | ... | DATO[LONGITUD-DATOS] | CHECKSUM.
esta trama solo puede ser enviada por un nodo a la vez ya que todos estan conectados al mismo par de cables.
cada dato tiene una longitud de  9 bits, el noveno bit se utiliza para indicar dirección y los restantes 8 son informacion, asi por ejemplo si alguien quiere enviar datos coloca el noveno bit de DESTINO en '1'  y en los restantes datos coloca el noveno bit en '0'. Esto se realiza por que cada nodo en la red tiene un identificador unico y si DESTINO coincide con dicho identificador el continua recibiendo el mensaje, en caso contrario no recibe mas datos hasta que vuelva a encontrar un bit de direccion en '1'.
Te adjunto un diagrama de flujo de la recepcion que fue implementada en la rutina de interrupcion por recepcion de  la USART.

Cualquier cosa me comentas, saludos desde Santa Marta, Colombia

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a embebidos32...@googlegroups.com.

[Fernando Lichtschein]

Estimados,

En realidad RS-485 no es un protocolo si no una norma de interfaz. A diferencia de RS-232, utiliza transmisión diferencial y como los receptores pueden ponerse en alta impedancia puede utilizarse en conexiones multipunto (hasta 32 si se utilizan cargas standard). También permite mayores distancias, 4000 pies contra 50 de RS-232 (según la norma).

El formato de los datos se define en las capas superiores.

Saludos.

[Guillermo Enrique VIDES]

Correcto. Y por lo tanto con un conversor simple, por ejemplo MAX485 podes convertirlo en rs232, ajustar la velocidad del programa de comunicaciones segun el ancho de pulso que se ve en el osciloscopio y ya esta, ves los datos en la pc.

saludos
Guillermo

---

Date: Thu, 10 Oct 2013 17:45:59 -0300
Subject: Re: [embeb32] rs485 a rs232
From: flicht...@ort.edu.ar
To: embeb...@googlegroups.com

[Alfredo Siárez]

Por RS232 se suele recibir en los integrados de PC hasta 8 bits, se pueden
recibir 9 si uno se pone a jugar con el bit de paridad, pero eso requiere
manipular el software de recepción. Sin embargo existen implementaciones
seriales en RS485 que codifican la información en tramas de mayor longitud
de bits por lo que a veces hay que poner lógica intermedia entre la
interfaz RS485 y la interfaz RS232 para que el sistema que recibe RS232
pueda interpretar los datos correctamente.

Por ejemplo si lo que quiere visualizar Carlos es CanBus que está
implementado mediante RS485, los frames tienen una longitud de datos de
hasta 107 bits con campos de 1, 6, 11 bits.... y encima cuando hay muchos
ceros seguidos el emisor agrega un bit "1" de sincronismo extra (si hay
muchos unos agrega un bit cero) que el receptor tiene que descartar y sólo
utilizarlo para actualizar la sincronización.

En Thu, 10 Oct 2013 22:33:23 -0300, Guillermo Enrique VIDES
<gev...@hotmail.com> escribió:

>
> Correcto. Y por lo tanto con un conversor simple, por ejemplo MAX485
> podes convertirlo en rs232, ajustar la velocidad del programa de
> comunicaciones segun el ancho de pulso que se ve en el osciloscopio y ya
> esta, ves los datos en la pc.
> saludos
> Guillermo

> Date: Thu, 10 Oct 2013 17:45:59 -0300
> Subject: Re: [embeb32] rs485 a rs232
> From: flicht...@ort.edu.ar
> To: embeb...@googlegroups.com
>

[Fernando Lichtschein]

Estimados,

Tanto RS-485 como RS-232 definen la interfaz física, no el formato de los datos. Estamos acostumbrados a ver las interfaces RS-232 de las PCs que son asincrónicas y de tamaño de palabra limitado, pero también se usa para comunicaciones sincrónicas (en las PCs no porque las UARTs no lo soportan y además en el conector DB9 que no es standard no están las patas de reloj).

No me suena CAN sobre RS-485 porque maneja en concepto de bits dominantes y recesivos para detectar las colisiones y eso necesita circuitos tipo colector abierto o "wired or" para que el la salida con el bit dominante le "gane" a las de bit recesivo. En RS-485, pese a que se puede utilizar en multipunto, solamente una de las salidas puede estar activa, eso es, no en alta impedancia, a la vez. Esto obliga a utilizar métodos de acceso con interrogación que no son los que usa CAN.

Saludos,

Fernando

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

[carlos cabas]

Buenos dias compañeros, analizando sus comentarios:

Es un equipo comercial, al que se le dañó uno de sus terminales y por el actual problema de importación aqui en argentina se ha complicado importar dicho terminal, el terminal como tal, solo informa si ha ocurrido un evento, la imagen que adjunté es la respuesta a uno de esos eventos. el tema de como funciona RS485 es claro, lo que no es claro es que como comenta Fernando sobre el bus se puede enviar cualquier cantidad de bits a una velocidad cualquiera (con limites), entonces es dificil observar cuantos bits son en realidad al no contar con una base de tiempo clara.

La señal permanece en 1 cuando ocurre el evento realiza la transmision del dato y luego vuelve a 1 (1 ----- dato de n bits a x bps ----- 1)

Lo que comentó guillermo, fué lo primero que hice pero se me es complicado hallar la velocidad de transmisión al no saber en realidad cuantos bits se estan enviando, en el puerto COM he configurado todas las velocidades posibles pero solo observo  caracteres aleatorios sin identificar algún patrón.

no sé que mas probrar.

alguna otra idea ?? o si con esta información les hes mas facil ???

Gracias a todos por sus comentarios u opiniones, son de gran ayuda.

 

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a embebidos32...@googlegroups.com.

Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

--
Cordialmente;

Carlos Eduardo Cabas Meriño
Ingeniero Electrónico
Técnico Profesional en Contabilidad y Finanzas

[Alfredo Siárez]

No entiendo porque dice que los bps son variables. El bit time debería ser fijo, salvo que la primer parte de la trama de bits sea  siempre el mismo patrón para que el receptor al analizarla determine el bit time. Me falta preguntar si lo que se observa en la foto es lo que envía un solo dispositivo o si es el bus cuando hay varios dispositivos que se comunican entre si.

Por el RS232 de la PC no se puede recibir porque la UART de la PC espera un start bit, maximo  8 bits de datos y 1 bit de stop (uno y medio o dos) y la trama de la señal que Ud necesita decodificar tiene una configuración distinta a esa

.

En este punto me parece que habría dos formas de encarar la solución:

La primera es conseguirse un analizador lógico parecido a este  que tiene un software asociado de decodificación de múltiples protocolos.

La otra forma sería el "Analizador Lógico del Hombre Pobre"; poner un microcontrolador que haga la recepción serial no por UART hardware, sinó por UART software y transmita el byte a la PC por puerto paralelo (también se podría usar un shift register y un par de integrados de lógica para el handshaking).  Luego la pesada tarea de decodificar a mano buscando los campos de longitud de datos (que informa la cantidad de bytes transmitidos como dato, no la longitud total de la trama) y el campo checksum. 

Suerte con la tarea!!.

[Fernando Lichtschein]

Carlos,

Si la línea queda siempre en "1" y después de transmitir vuelve a "1" es muy probable que sea asincrónico y el primer bit "0" es el de arranque. Como comentaron, es difícil determinar la tasa de bits sin conocer un poco más sobre lo que se está transmitiendo, como por ejemplo la cantidad de bits por palabra y si se utiliza paridad o no. Si es asincrónico como suponemos, cada palabra va a estar delimitada por un bit "0" que es el de arranque y al menos un bit "1" de parada, si se encuentra ese tipo de patrón después se puede analizar qué es lo que pasa en el medio y sacar alguna conclusión.

Yo uso este analizador lógico que no es caro y se consigue en Bs. As:

http://dangerousprototypes.com/open-logic-sniffer/

Si te interesa te puedo pasar los datos de dónde lo compré.

Saludos,

Fernando

--

[Mirko Leonardo Serra Labán]

Si se hace UART por "software", te queda la UART de hardware para transmitir a la PC y evitar el tedioso-odioso puerto paralelo.