Protocolo para RS485

[ales]

Hola amigos, gracias a la información encontrada en el Foro pude lograr el HW y SW de un protocolo para la comunicación RS485.
 Aqui se las paso, el SW con CCS y HW con Proteus 7.2.
No les explico nada porque no se si a alguien le hará falta, en caso que si, bueno me preguntan y les doy los detalles.

Gracias a todos por su ayuda y espero que lo aprovechen.

saludos.

[Cryn]

esta muy completo, gracias pro el aporte, podrias explicarnos en qeu consistia mas o menos todo el proyecto?? para que tengamos una idea de como va y donde se lo puede aplicar

te ha quedado mbien

y tb una pregunta, porque usaste ese micro? simple gusto o tiene algo que lo hace indispensable

un saludo, muy buen aporte

[ales]

El protocolo RS485 que tuve que hacer formará parte de mi trabajo de diploma de la universidad, verás que la identificación (o sea la dirección) de los esclavos es por hardware, esto es necesario porque todos los PIC Slaves tendrán el mismo Software, ellas serán las encargadas de recoger información de sensores que tendrán conectadas por la otra UART del PIC. Por eso fue que escogí este PIC porque tiene dos UART por HW y por SW es un dolor de cabeza la simulación de UART que hace el CCS.
El Master también en un momento determinado se conectará via serie con una PC para recibir toda la configuración necesaria para el funcionamiento.
Y toda la información que le vaya pidiendo a los esclavos la procesará y almacenará en una MMC.

Entonces el protocolo como tal:
-El Master envía en un byte la dirección del esclavo con el que quiere comunicarse y en el bit LSB de este mismo byte con 0 informa que va a escribir y con 1 que va a leer (tipo I2C)
-El esclavo con esa ID envía su propia ID hacia el Master como respuesta de que está recibiendo la información (o sea: ACK).
-Y en caso que el Master vaya a escribir en el Esclavo envía ahora la Cant. de bytes que va a transferir al Esclavo.
- El esclavo espera esta cantidad y la envía de nuevo al Master como Ack, y así se comprueba que llegó bien la información.
-Después el Master comienza la transferencia de los bytes.
Si el Master quiere leer al Esclavo, entonces despues de enviar la ID lo que hace es esperar del Esclavo la cantidad de bytes que este vaya a transferirle y como Ack el Master envía dicha cantidad de nuevo al esclavo.
-Después el Esclavo comienza la transferencia.
-Cualquiera de los dos que esté transfiriendo, nada más termine el otro envía el byte 0xFF para que el otro conozca que ya fue recibido el paquete.

 En caso que en la espera de algún Ack se desbordara la INT TIMER0 que se activa cuando se espera el ACK se retorna ERROR en la escritura o lectura porque han pasado 1.6 segundos y creo que es suficiente como para considerar un problema, de todas formas podemos varias este tiempo.

Saludos Cryn.

[Cryn]

gracias por lso detallles

ahora si esta claro

y ya lo implementaste?? cuanndta distancia puede aguantar??

muy buen trabajo, felicidades

[ales]

Hola Cryn, aún no lo he implementado, porque no he terminado pero en un futuro quizás no muy lejano pueda.

Sobre la distancia, supongo que soporte los 1200 metros del RS485, yo solo lo necesito para unos 50 metros como máximo pero en un ambiente muy ruidoso por ello la necesidad del rs485, el sistema ira instalado en una intercepción semafórica.

gracias por las felicitaciones, no eran necesarias.

saludos.

[cheapekt]

Enhorabuena Cryn, yo estoy trabajando en algo parecido a lo tuyo pero más simple, tengo que transferir datos desde un pic al pc,... el pc interrumpe cada hora al pic para que vuelque una tabla que tendrá guardada el pic, he pensado en usar el bus usb en el ordenador porque quiero que se pueda usar en los ordenadores portátiles, para ello he de  comprar un adaptador usb-rs232 para luego añadir un max485 que saque la señal mediante esa capa física. ¿Crees que hago lo correcto?

O existe otra opción más eficaz?

[maunix]

Enhorabuena Cryn, yo estoy trabajando en algo parecido a lo tuyo pero más simple, tengo que transferir datos desde un pic al pc,... el pc interrumpe cada hora al pic para que vuelque una tabla que tendrá guardada el pic, he pensado en usar el bus usb en el ordenador porque quiero que se pueda usar en los ordenadores portátiles, para ello he de  comprar un adaptador usb-rs232 para luego añadir un max485 que saque la señal mediante esa capa física. ¿Crees que hago lo correcto?

O existe otra opción más eficaz?

cheapekt si usarás un adaptador usb-rs232 entonces tu interfaz es RS232.  Lo del adaptador será obligatorio para todo que quiera usar tu aplicación.

Si además le agregas un RS485, lo haces aún más específico.

Si piensas usar directamente RS485, te sugiero compres un adaptador USB-RS485 y asunto solucionado.

La otra alternativa, aunque requiere de instalación del lado de la pc, es que hagas todo via USB. 

[Cryn]

Enhorabuena Cryn

 

  pero si yo ni hice nada 

jejeje

el de los derechos de autor aqui es ales

[cheapekt]

Jejejee....

Lo siento ales,   entonces todo el merito es tuyo!!!
BUeno y el de los compañeros, muchas gracias

Saludos!

[ales]

Hola cheapekt, te acabo de enviar un mensaje preguntando a que protocolo te referias y bueno ahora acabo de ver este tema y me doy cuenta a que te referias.

Pues cualquier cosa aqui estoy....

saludos.

[cheapekt]

yo estoy trabajando en algo parecido a lo tuyo pero más simple, tengo que transferir datos desde un pic al pc,... el pc interrumpe cada hora al pic para que vuelque una tabla que tendrá guardada el pic, he pensado en usar el bus usb en el ordenador porque quiero que se pueda usar en los ordenadores portátiles, para ello he de  comprar un adaptador usb-rs232 para luego añadir un max485 que saque la señal mediante esa capa física. ¿Crees que hago lo correcto?



¿Hablando del tema, es posible que programe esto mediante TCP/IP,  con sockets? o es un disparate lo que he dicho.

Muchas gracias, saludos

[ales]

Yo nunca he trabajado con usb y las pic, lo tengo en mente para futuros proyectos, pero te recomiendo que leas el datasheet del conversor usb-rs485 y debe aclararte algunas dudas.

Hablas del puerto RS323 del PIC, y el PIC no tiene RS232 el tiene salida TTL, o sea 0 y 5V oara su comunicación serie y la PC si tiene RS232 por lo que para comunicar la PIC con la PC por puerto serie necesitas un MAX232 para convertir TTL/RS232 y viceversa. Pero si el Conversor te da USB/RS485  conectas este RS485 a otro que iria al PIC.
O sea, PC conectada por USB al USB/RS485 y este a un RS485/TTL a la PIC.

Cuando te digo RS485 me refiero a un MAX485.
Y estoy seguro que desde la PIC se envía serie al MAX485 porque eso es lo que el recibe ahora la información a enviarle para que se envíe después por USB depende de los comandos que leas en el datasheet del conversor y del funcionamiento por USB en la PC con respecto a esto que no tengo idea.

Saludos.

[zagoaristides]

El protocolo RS485 que tuve que hacer formará parte de mi trabajo de diploma de la universidad, verás que la identificación (o sea la dirección) de los esclavos es por hardware, esto es necesario porque todos los PIC Slaves tendrán el mismo Software, ellas serán las encargadas de recoger información de sensores que tendrán conectadas por la otra UART del PIC. Por eso fue que escogí este PIC porque tiene dos UART por HW y por SW es un dolor de cabeza la simulación de UART que hace el CCS.
El Master también en un momento determinado se conectará via serie con una PC para recibir toda la configuración necesaria para el funcionamiento.
Y toda la información que le vaya pidiendo a los esclavos la procesará y almacenará en una MMC.

Entonces el protocolo como tal:
-El Master envía en un byte la dirección del esclavo con el que quiere comunicarse y en el bit LSB de este mismo byte con 0 informa que va a escribir y con 1 que va a leer (tipo I2C)
-El esclavo con esa ID envía su propia ID hacia el Master como respuesta de que está recibiendo la información (o sea: ACK).
-Y en caso que el Master vaya a escribir en el Esclavo envía ahora la Cant. de bytes que va a transferir al Esclavo.
- El esclavo espera esta cantidad y la envía de nuevo al Master como Ack, y así se comprueba que llegó bien la información.
-Después el Master comienza la transferencia de los bytes.
Si el Master quiere leer al Esclavo, entonces despues de enviar la ID lo que hace es esperar del Esclavo la cantidad de bytes que este vaya a transferirle y como Ack el Master envía dicha cantidad de nuevo al esclavo.
-Después el Esclavo comienza la transferencia.
-Cualquiera de los dos que esté transfiriendo, nada más termine el otro envía el byte 0xFF para que el otro conozca que ya fue recibido el paquete.

 En caso que en la espera de algún Ack se desbordara la INT TIMER0 que se activa cuando se espera el ACK se retorna ERROR en la escritura o lectura porque han pasado 1.6 segundos y creo que es suficiente como para considerar un problema, de todas formas podemos varias este tiempo.

Saludos Cryn.

Genial el código ya lo analicé todo y eso que odio leer código de otro, pero me gusta la claridad aunque le hubiera puesto más comentarios para los que son foráneos como yo.

Ahora mi pregunta, de esta parte del código, fijate que la comenté para ir entendiéndola y no volver a pensar tanto digamos jeje. Está bien lo que pienso?

Esta parte de Código 

   //este que sigue sería un case especial cuando myCOM.cntRx o sea la cuenta de bytes recibidos
   if ((myCOM.cntRx > 2) && (myCOM.reading == true)) // Si recibimos más de de 2 bytes y estamos leyendo
   {
      if (myCOM.Slave_Active == true)
         myCOM.Buffer[myCOM.cntRx - 3] = dato;  // Este es el buffer que guardará los bytes recibidos y es - 3 
                                                // porque empezamos con myCOM.cntRx en 3 o sea queda dde. 0
      if ((myCOM.cntRx - 2) == myCOM.cnt_a_Rx)  // Acá probamos si ya llegamos al final del buffer. En este caso
                                                // cuando lleguemos al dato 20 myCOM.cntRx será 22
                                                // 20 + 1 de Dir+R/W + 1 de Cant. de Bytes a recibir
      {
         myCOM.cntRx = 0;                       // Reseteamos para una nueva comunicación
         myCOM.cnt_a_Rx = 0;                   
         
         if (myCOM.Slave_Active == true)       
         {                                      // Reseteamos las variables para una nueva comunicación
             myCOM.tramaLista = true;
             myCOM.tramaProcesada = false;
             myCOM.reading = false;
             myCOM.Slave_Active = false;
             myCOM.cnt_a_Tx = 0;
             write1byte_master(0xFF);     // Comando de Recepcion buena de bloque de datos
         }
      }
   }

Mil Gracias

[ales]

Zagoaristides, este protocolo lo realicé hace como 6 meses para la tesis de ingeniería, por lo que la verdad que no recuerdo bien, pero estoy casi seguro que es como dices,  jjjaaaja, resulta que en estos momentos entiendes mejor el código que yo.
Pero recuerdo que después le agregué además código CRC y quedó mejor implementado, si tienes interés en utilizarlo me dices y lo busco para enviartelo.

Saludos, Ales.

[Cryn]

creo que un CRC nos vendría muy bien a todos

un saludo y gracias