Autor Tema: Quien conoce este protocolo serie o similar?  (Leído 4108 veces)

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

Desconectado Lupin

  • PIC12
  • **
  • Mensajes: 81
Quien conoce este protocolo serie o similar?
« en: 13 de Marzo de 2007, 22:56:26 »
Hola,

Hace un tiempo me encontre con la necesidad de intercomunicar distintas placas de equipos que diseñe en distintas epocas y con distintos microcontroladores, claro que estas placas no estaban previstas para dicho fin, la mayoria no tiene ni RS232 y los pines del I2C estan usados para otras funciones.
Lo unico que encontre en comun en todas las placas fue un conector de 4 pines donde tengo +5V,GND y dos pines directo del pic (estos conectores suelo ponerlos para dejar acceso a los pines que me sobran, para futuras aplicaciones).

Por esto es que decidi "embeber" algun tipo de comunicacion serie bidireccional por dos pines, pero despues de ver algunos estandar, no me convencio ninguno por motivos de no querer agregar interrupciones de soft en algunas placas o tener que gastar muchos recursos del pic para atender esta comunicacion.

Aprovechando que no necesito mucha transferencia de datos entre placas, apunte a que la comunicacion pueda ser lo suficientemente versatil para agregarla a todos los pic (diferentes modelos y familias usando las mismas rutinas) y que se pueda iniciar la comunicacion o recibir un dato por "pulling", o desatender el puerto por intervalos largos de tiempo sin perder datos.

En definitiva, arme un sistema de comunicacion con estas caracteristicas que me funciono muy bien y ahora voy a detallarlo con la intencion de que si alguien lo conoce o conoce alguno similar me avise, ya que es muy probable que haya perdido el tiempo haciendo algo que ya existe!!

El tema es asi, los cables necesarios son GND, una linea llamada SCL (para que suene familiar) y otra llamada SDA (tambien muy conocida).
Ambas lineas estan conectadas al positivo por una resistencia de pull-up en una o ambas placas.
En standby SDA y SCL estan en 5V.
Si el Pic_1 quiere enviar un dato, pone en bajo SCL y espera la respuesta del Pic_2.
La respuesta del pic_2 consiste en poner en bajo SDA antes de un tiempo maximo de espera (yo estoy usando 500ms para que pic_2 no tenga que apurarse en contestar y desatender lo que esta haciendo).
La respuesta de pic_2 dura 100uSeg en bajo y despues libera SDA (se pone en alto).
En este momento Pic_1 pone el primer Bit de dato en SDA y 50uSeg despues pone en alto el SCL para que pic_2 lea el valor de SDA.
50uSeg despues pic_1 pone en bajo SCL, pone el bit 2 en SDA y repite el paso anterior.
Despues de pasar 8 bits, SCL queda en alto, por lo tanto si inmediatamente se inicia la comunicacion de un nuevo BYTE, esta es "enganchada" inmediatamente por pic_2.

De esta forma tenemos que la comunicacion puede tardar hasta 500ms para iniciarse, este es un tiempo maximo antes de cancelar, lo normal es que la comunicacion se inicie rapido (depende del tiempo del loop en caso de usar pooling o inmediatamente si se usan interrupciones). A partir del segundo BYTE del paquete enviado, al estar ya enganchados los pic, cada byte tarda 900uSeg, por lo que tenemos mas de 1000 BYTES por segundo que para muchos casos es mas que suficiente.
Todos los tiempos se pueden modificar, logrando velocidades muchisimo mas altas, pero perdiendo flexibilidad en la interaccion con equipos ya diseñados, perdiendo longitud en los cables de interconexion, etc.



Para transmitir desde pic_2 a pic_1 es exactamente igual, pero pic_2 inicia la comunicacion.

Se pueden "colgar" del mismo bus de datos muchos pics simultaneamente.

Vuelvo a repetir, si ya existe algo identico a esto y tiene nombre me gustaria saberlo, por el momento lo sigo llamando "El protocolo SOM".

Saludos y gracias.

« Última modificación: 15 de Marzo de 2007, 00:01:41 por Lupin »

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17909
    • MicroPIC
Re: Quien conoce este protocolo serie o similar?
« Respuesta #1 en: 14 de Marzo de 2007, 02:21:56 »
Pues no me atrevería a asegurar que sea idéntico, pero el SPI se parece bastante.
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Deimos

  • Visitante
Re: Quien conoce este protocolo serie o similar?
« Respuesta #2 en: 14 de Marzo de 2007, 06:10:34 »
No es un SPI manolo, sino un I2C.

Lupin lo que buscas se llama protocolo I2C y el foro está plagado de hilos con respecto al tema. Usa el buscador y verás que es un tema que hemos tratado en infinidad de ocasiones.

El I2C utiliza dos cables y tramas para determinar el nodo. El SPI usa 4 cables y utiliza chip selects para elegir a que nodo comunica.

Salu2!!!!

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17909
    • MicroPIC
Re: Quien conoce este protocolo serie o similar?
« Respuesta #3 en: 14 de Marzo de 2007, 06:34:38 »
En realidad sería una mezcla, porque el I2C incorpora la dirección del destinatario en la comunicación.
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Deimos

  • Visitante
Re: Quien conoce este protocolo serie o similar?
« Respuesta #4 en: 14 de Marzo de 2007, 07:25:37 »
En realidad sería una mezcla, porque el I2C incorpora la dirección del destinatario en la comunicación.

Parte de razon tienes, ya que la comunicacion es tipo P2P, pero el bus en sí está hecho por dos cables, que se llamas igual que en I2C, el SDA serial data y el SCL serial clock. Es decir, está haciendo un I2C si la parte de la trama que indica dirección o comando de lectura/escritura. Se entiende que hay un master y un slave, como el SPI, es eso lo que quieres decir manolo?

Con este protocolo Lupin dudo que puedas pinchar varios pics al bus, a no ser que quieras que todos reciban lo mismo. Si pretendes discriminar, con el protocolo tal y como lo tienes........ no se puede, ya que en tus tramas no mandas ni direcciones ni comandos, solo datos.

Dews!!!!

Desconectado Lupin

  • PIC12
  • **
  • Mensajes: 81
Re: Quien conoce este protocolo serie o similar?
« Respuesta #5 en: 14 de Marzo de 2007, 10:18:45 »
hola,

Si no me equivoco, en el I2C la comunicacion la inicia y termina un pic sin saber si alguien lo esta "escuchando", solamente comienza con el bit de inicio y termina con el bit de stop, pero nunca espera un ACK para comenzar a transmitir, (supone que los pics conectados al bus son lo suficientemente rapidos para atender la comunicacion).
Con respecto a colgar varios pic del bus, lo que yo hago es mandar esa informacion en el paquete de datos, asi como tambien los controles de error.
Por esto es que siempre mando solo 8 bits, la informacion real se forma al completar la recepcion completa de un paquete de bytes.

Por ahora lo unico que tengo claro es que no es ni I2C ni SPI (a simple vista se parece bastante a cualquiera) pero ni el I2C ni el SPI cumplen con las necesidades que mencione en el primer mensaje (claro esta que el I2C o el SPI son totalmente superiores a este en otros aspectos).

Quiero aclarar que no hay un pic que siempre transmite y otro que siempre recibe, cualquiera que este conectado en el bus puede iniciar una comunicacion en cualquier momento (fijandose que SDA y SCL esten en alto) con cualquier otro.

Saludos y gracias por las opiniones.

Desconectado Renatox_

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 541
    • máquinas cnc
Re: Quien conoce este protocolo serie o similar?
« Respuesta #6 en: 14 de Marzo de 2007, 12:48:47 »
 Hola, y si usas el I2C pero sacándolos por esos dos pines que tienes libre, osea asi como la USART se puede sacar por otros pines que no sean RC6 ni RC7, podrías hacer lo mismo con esos pines, el CCS creo que permite hacer eso. Corregirme si me equivoco,
control de movimiento

Deimos

  • Visitante
Re: Quien conoce este protocolo serie o similar?
« Respuesta #7 en: 14 de Marzo de 2007, 14:03:55 »
Lupin en i2c no hay bit de start o de stop, sino que es una combinación entre la linea de clock y la de datos. Lo bueno de ese sistema es que con el start avisas a todo el bus, pero siempre es necesaria la señal de ACK para seguir con la comunicacion.

En el i2c puedes mandar solo tramas de 8 bits, y como bien dices, en el nodo de recepcion montas los words tan largos como te sean necesarios, pero, en el i2c las primeras partes de la trama son direccion y palabra de comando, es decir lectura o escritura. Con tu sistema mandas datos pero no sabes a donde van a parar, ni tampoco si el dato es de lectura o escritura, o pertenece a una dirección. Supongo que esto te lo montas con un diccionario interno en el nodo de recepción, pero personalmente no me parece una solución demasiado acertada.

Si es i2c las tramas están incompletas, y si es SPI falta en el cronograma de la linea de chip select para indicarle al nodo que en ese momento se le va a hacer trabajar.

No puedes pinchar en el bus (tal y como lo tienes planteado) más de dos nodos (master y slave), ya que el primero que entre ocupará el bus. En i2c no hay problema ya que la trama la reciben todos los nodos, pero solo responde el que reconozca la dirección de nodo, pero solo uno, no pueden responder varios nodos a la vez. En SPI no puedes tener más de un nodo por bus, ya que la selección se hace a través del CS. Con tu sistema los nodos se estrellarían, ya que todos tendrian el CS activado, y todos se pondrían a mandar datos a través del bus, con lo que colisionan. En un bus SPI, lo normal es tener activo solo un nodo esclavo, y activado por CS. Si quieres poner más elementos en el bus SPI los has de ir multiplexando con sus respectivos CS, pero solo puede haber un esclavo activado.

Renatox

Dentro del Mplab hay unas librerias que empiezan con sw (ej: sw_i2c.h, sw_spi.h, ...) que son precisamente para lo que comentas, para simular un puerto digital I/O con módulo asociado (i2c, spui, usart, etc...). Puedes crear puertos como los mencionados con pines I/O de propósito general. El problema que veo yo aquí, es que como ni es i2c ni spi, es posible que ninguna libreria le acabe de servir. En CCS no sé si tienen estas librerias, es un lenguaje que no practico.

Salu2!!!!


Desconectado Renatox_

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 541
    • máquinas cnc
Re: Quien conoce este protocolo serie o similar?
« Respuesta #8 en: 14 de Marzo de 2007, 14:28:28 »
 Hola Deimos, tengo una duda con el SPI, se pueden manejar varios dispositivos esclavos, desactivando los esclavos que no se usan con el SS o CS, eso impiden que estos esclavos puedan mandar datos por el bus y malograr la comunicación, pero no impide que estos esclavos escuchen la conversación entre el master y el esclavo activo.

 Entonces cuando se selecciona otro esclavo, este tiene un dato basura que está en su buffer de recepicón SPI, debido a la escucha de la comunicación anterior, entocnes el primer dato que lee el esclavo no es el primer dato que le envía el master si no un dato incorrecto, esto es cierto..? y si es cierto como solucionarlo.
control de movimiento

Deimos

  • Visitante
Re: Quien conoce este protocolo serie o similar?
« Respuesta #9 en: 14 de Marzo de 2007, 14:56:22 »
Hola Deimos, tengo una duda con el SPI, se pueden manejar varios dispositivos esclavos, desactivando los esclavos que no se usan con el SS o CS, eso impiden que estos esclavos puedan mandar datos por el bus y malograr la comunicación, pero no impide que estos esclavos escuchen la conversación entre el master y el esclavo activo.

 Entonces cuando se selecciona otro esclavo, este tiene un dato basura que está en su buffer de recepicón SPI, debido a la escucha de la comunicación anterior, entocnes el primer dato que lee el esclavo no es el primer dato que le envía el master si no un dato incorrecto, esto es cierto..? y si es cierto como solucionarlo.

Hola Renatox. No es correcto lo que dices, ya que si un nodo tiene el CS desactivado, no almacena ni escucha nada. Para que el nodo se entere que van a trabajar con él ha de ver un flanco en su entrada de chip select (normalmente negada, aunque los hay de selección por positivo). Mientras el CS no sufra un cambio de nivel, el buffer de recepción y el de transmisión (en caso que tenga dos) del nodo se mantiene inalterable. El problema básicamente se da cuando varios esclavos mandan tramas al maestro, entonces si que ha colisión en el bus.

Resumiendo, sin cambio de CS no hay peligro de dato basura, como tu lo has definido.

Espero haberte sido de ayuda.

Dews!!!!!

Desconectado Renatox_

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 541
    • máquinas cnc
Re: Quien conoce este protocolo serie o similar?
« Respuesta #10 en: 14 de Marzo de 2007, 15:21:39 »
 Excelente, gracias.
control de movimiento

Deimos

  • Visitante
Re: Quien conoce este protocolo serie o similar?
« Respuesta #11 en: 14 de Marzo de 2007, 15:58:48 »
No hay de que.

Dews!!!!!

Desconectado Lupin

  • PIC12
  • **
  • Mensajes: 81
Re: Quien conoce este protocolo serie o similar?
« Respuesta #12 en: 14 de Marzo de 2007, 22:58:51 »
Hola, y si usas el I2C pero sacándolos por esos dos pines que tienes libre, osea asi como la USART se puede sacar por otros pines que no sean RC6 ni RC7, podrías hacer lo mismo con esos pines, el CCS creo que permite hacer eso. Corregirme si me equivoco,

Renatox, el problema mio no es implementar un I2C en pines distintos al que vienen en el pic, mi problema es que la comunicacion I2C no me sirve para lo que comente al abrir este tema.

Igualmente gracias por tu aporte.

Desconectado Lupin

  • PIC12
  • **
  • Mensajes: 81
Re: Quien conoce este protocolo serie o similar?
« Respuesta #13 en: 15 de Marzo de 2007, 00:01:02 »
Lupin en i2c no hay bit de start o de stop, sino que es una combinación entre la linea de clock y la de datos. Lo bueno de ese sistema es que con el start avisas a todo el bus, pero siempre es necesaria la señal de ACK para seguir con la comunicacion.

Ok, yo le llamo "bit de start" al "start condition" y "bit de stop" al "stop condition"
El problema si uso I2C es que mientras estoy enviando la direccion del equipo con el cual me quiero comunicar, lo mas probable es que estos bits se pierdan ya que el modulo que deberia recibirlos todabia no esta listo (minimos recursos usados en la comunicacion, incluso sin interrupciones).

En el i2c puedes mandar solo tramas de 8 bits, y como bien dices, en el nodo de recepcion montas los words tan largos como te sean necesarios, pero, en el i2c las primeras partes de la trama son direccion y palabra de comando, es decir lectura o escritura. Con tu sistema mandas datos pero no sabes a donde van a parar, ni tampoco si el dato es de lectura o escritura, o pertenece a una dirección. Supongo que esto te lo montas con un diccionario interno en el nodo de recepción, pero personalmente no me parece una solución demasiado acertada.

Explique la comunicacion entre dos pics, pero no di ningun detalle de la comunicacion con muchos modulos conectados al mismo bus, por eso la confusion...

Cuando hay varios pics colgados del mismo bus (yo uso 5) uso un ACK mas prolongado para lograr lo siguiente:

Supongamos que el pic_3 quiere mandar un dato al resto..
Pic_3 pone en bajo SCL..
Pic_2 (por ejemplo) es el primero en engancharse y pone en bajo SDA (ACK de pic_2)..
Mientras dura este ACK, el pic_5 (por ejemplo) se engancha a la comunicacion y pone en bajo a SDA (que ya estaba en bajo) extendiendo su duracion..
Despues pic_4 (por ejemplo) hace lo mismo ...
Y finalmente Pic_1 que estaba terminando de resolver algo, ve que SCL esta en bajo.. y se engancha a la comunicacion prolongando SDA en bajo.
Cuando termine el ACK del pic_1 es cuando SDA vuelve al estado alto.. en este momento los 5 pics estan sincronizados esperando los datos de quien inicio la comunicacion.
Cuando se termina de transmitir el Byte completo, el ciclo se repite hasta transmitir todo el paquete.

Al terminarse de transmitir el paquete de bytes, cada pic interpreta la informacion recibida para ignorarla o actuar en concecuencia (si queremos, mas de un pic puede hacerse cargo y actuar segun cierto mensaje recibido).


Si es i2c las tramas están incompletas, y si es SPI falta en el cronograma de la linea de chip select para indicarle al nodo que en ese momento se le va a hacer trabajar.
No puedes pinchar en el bus (tal y como lo tienes planteado) más de dos nodos (master y slave), ya que el primero que entre ocupará el bus. En i2c no hay problema ya que la trama la reciben todos los nodos, pero solo responde el que reconozca la dirección de nodo, pero solo uno, no pueden responder varios nodos a la vez. En SPI no puedes tener más de un nodo por bus, ya que la selección se hace a través del CS. Con tu sistema los nodos se estrellarían, ya que todos tendrian el CS activado, y todos se pondrían a mandar datos a través del bus, con lo que colisionan. En un bus SPI, lo normal es tener activo solo un nodo esclavo, y activado por CS. Si quieres poner más elementos en el bus SPI los has de ir multiplexando con sus respectivos CS, pero solo puede haber un esclavo activado.

Como ya explique no es I2C, no es SPI, no tengo posibilidad de agregar ningun CS (tengo solo 2 cables), no puedo mandar una direccion antes de recibir el ACK.

Renatox
Dentro del Mplab hay unas librerias que empiezan con sw (ej: sw_i2c.h, sw_spi.h, ...) que son precisamente para lo que comentas, para simular un puerto digital I/O con módulo asociado (i2c, spui, usart, etc...). Puedes crear puertos como los mencionados con pines I/O de propósito general. El problema que veo yo aquí, es que como ni es i2c ni spi, es posible que ninguna libreria le acabe de servir. En CCS no sé si tienen estas librerias, es un lenguaje que no practico.

Que no sea ni I2C ni SPI no es el problema, ya que a proposito lo hice diferente para que cumpla con las necesidades del proyecto, mi consulta inicial era si hay algo estandar (que no es el I2C ni tampoco el SPI) que sea casi identico o que cumpla con los requerimientos, para poder usarlo en lugar de este sistema "casero" y (un poco improvisado), aunque los resultados hasta ahora fueron excelentes (y las rutinas muy simples).

En este momento estoy comunicando de esta manera todo un "rejunte" de placas de distintos equipos (modificando minimamente los soft).. un teclado matricial (pic 16f84A), un display LCD (pic 16f873A), una CPU (pic 18f452), una placa de control de 10 reles (pic 16f873A), otra cpu (pic 16f873A) y un transmisor/receptor infrarrojo (pic 12f675)... (ahora que me fijo bien, son 6 modulos no 5 como dije en el ejemplo).
Cuando se me acaben todos estos modulos ya armados, seguramente reducire a este "franskestein" en una sola CPU (con un solo pic), pero por ahora el protocolo SOM me viene salvando.

Sigo escuchando sujerencias, modificaciones, criticas, etc.

saludos

Deimos

  • Visitante
Re: Quien conoce este protocolo serie o similar?
« Respuesta #14 en: 15 de Marzo de 2007, 16:13:42 »
Este sistema que utilizas para controlar las colisiones me recuerda mucho al protocolo CAN, pero solo el sistema de colisiones, por lo demás me sigue recordando a I2C o SPI.

Con respecto a lo que dices de usar I2C y que los bits se pierdan...... no veo el porqué se van a perder. Lo que puedes hacer (aunque no lo veo necesario) es enviar una trama con la direccion, y si no recibes nada volver a enviar hasta 5 o 10 veces, si no recibes absolutamente nada entonces dictaminas que el nodo está K.O.



 

anything