Autor Tema: Longitud cable I2C  (Leído 13781 veces)

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

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Longitud cable I2C
« Respuesta #15 en: 31 de Marzo de 2010, 15:44:27 »
Es un buen dato Mano.

Yo estoy tambien necesitando implementar algo parecido, pero todavia no he decidido qué protocolo usar.
Mis principales candidatos son: el SPI o el CAN. Hasta ahora va a ser el SPI porque tengo muchos esclavos y me resultaria bastante costoso comprar PICs que posean CAN incorporado...Además, mi aplicación requiere de un tráfico de datos bastante elevado(1kBps por esclavo) y el CAN de los PICs es el de baja velocidad(125kbps) por lo que podría con el SPI intentar llegar a velocidades más altas(si la capa física me lo permite).

Obviamente voy a transformar el SPI en unidireccional y diferencial(al menos sus pines CLK y SDO). Estoy viendo si vale la pena incorporar un tercer par diferencial para la linea CS, de manera de tener que interrumpir sólo a los esclavos cuando envío la ID del destinatario del mensaje, ya que usando SPI debo hacerme cargo de la selección de paquetes según el ID del destinatario...

Si el tema da para ello, por ahí estaría bueno abrir un hilo e ir colgando todas las distintas configuraciones de protocolo usado/ capa fisica usada / cantidad de dispositivos conectados/ longitud entre ellos/ ruido del ambiente para que a otros les sirva como referencia...
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado stk500

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4874
Re: Longitud cable I2C
« Respuesta #16 en: 31 de Marzo de 2010, 16:41:47 »
Quizas este diciendo burrada, pero lo mejor para eso es Wireless un Xbee o una Rede con sensores, ya que he visto en lugares de maquinarias Sensores de todos tipo montados wireless y controlados por Redes.
aqui vea que miniatura son http://webs.cs.berkeley.edu/800demo/

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7881
Re: Longitud cable I2C
« Respuesta #17 en: 31 de Marzo de 2010, 22:33:31 »

Mis principales candidatos son: el SPI o el CAN. Hasta ahora va a ser el SPI porque tengo muchos esclavos y me resultaria bastante costoso comprar PICs que posean CAN incorporado...Además, mi aplicación requiere de un tráfico de datos bastante elevado(1kBps por esclavo) y el CAN de los PICs es el de baja velocidad(125kbps) por lo que podría con el SPI intentar llegar a velocidades más altas(si la capa física me lo permite).


Algo esta mal leido o interpretado.
El CAN en los PICs llega a la maxima velocidad sin problema alguno, salvo que uses un PIC que no soporte mas de 20 Mhz de clock, todos los que lo tienen soportan 1 Mbit de velocidad (esa si es la maxima).
Comparemoslo con SPI, ya que I2C no puede llegar a participar en la contienda... :mrgreen: :mrgreen:

Ventajas sobre SPI:
  • Admite 128 nodos por norma, pero si el trafico de datos es menor, con direccionamiento de 29 bits creo que vas a tener los nodos que quieras, no??
  • La mayor parte del protocolo la resuelve el hardware, admite filtrado de IDs, por lo cual se puede armar una red con diferentes niveles de relacion que es improbable hacer en SPI   8)
  • Usa solo dos cables sin importar la cantidad de nodos (en SPI necesitas los tres hilos mas el pin de seleccion.. ;-) ;-)  Hagamos una cuenta simple, preciso 32 nodos, son 3 pines de comunicacion mas...  32 pines CS!!!  Preciso nada mas y nada menos que 35 pines, y bueno pongo un PIC de 100 patillas, total!!  :shock:
  • Cualquier nodo puede ser Master en un momento dado, enviar o requerir informacion de otro sin molestarse por las colisiones que son resueltas otra vez `por el hardware. Esto permite enviar un reporte por excepcion, por ejemplo, una temperatura alcanzo un valor de setpoint, el nodo la transmite a uno, a varios, o a quien lo quiere escuchar.  Esa tecnica se llama productor/consumidor y realmente permite hacer cosas espectaculares!!

Desventajas respecto a SPI:
Salvo la velocidad, que podrias llegar a mas de 1 Mbit con bastante esfuerzo, otras no encuentro.

PD: No estoy en ultra defensor del CAN, solo es un analisis objetivo. :mrgreen:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Longitud cable I2C
« Respuesta #18 en: 01 de Abril de 2010, 00:40:22 »

Mis principales candidatos son: el SPI o el CAN. Hasta ahora va a ser el SPI porque tengo muchos esclavos y me resultaria bastante costoso comprar PICs que posean CAN incorporado...Además, mi aplicación requiere de un tráfico de datos bastante elevado(1kBps por esclavo) y el CAN de los PICs es el de baja velocidad(125kbps) por lo que podría con el SPI intentar llegar a velocidades más altas(si la capa física me lo permite).


Algo esta mal leido o interpretado.
El CAN en los PICs llega a la maxima velocidad sin problema alguno, salvo que uses un PIC que no soporte mas de 20 Mhz de clock, todos los que lo tienen soportan 1 Mbit de velocidad (esa si es la maxima).

Si. Es verdad. Parece que trabajan en 1mbps. Mea culpa.

Comparemoslo con SPI, ya que I2C no puede llegar a participar en la contienda... :mrgreen: :mrgreen:

Ventajas sobre SPI:
  • Admite 128 nodos por norma, pero si el trafico de datos es menor, con direccionamiento de 29 bits creo que vas a tener los nodos que quieras, no??
  • La mayor parte del protocolo la resuelve el hardware, admite filtrado de IDs, por lo cual se puede armar una red con diferentes niveles de relacion que es improbable hacer en SPI   
    8)
  • Usa solo dos cables sin importar la cantidad de nodos (en SPI necesitas los tres hilos mas el pin de seleccion.. ;-) ;-)  Hagamos una cuenta simple, preciso 32 nodos, son 3 pines de comunicacion mas...  32 pines CS!!!  Preciso nada mas y nada menos que 35 pines, y bueno pongo un PIC de 100 patillas, total!!  :shock:

No, no es necesariamente asi:
1) Como dije arriba, solo necesito comunicacion unidireccional. Del maestro a los esclavos. Por lo que puedo obviar la senial SDI;
2) El CS es OPCIONAL. Si te las rebuscas un poco no necesitas un CS por esclavo...Podes implementar un solo CS para todos. Cuando ese CS se activa, es porque estas por enviar el ID que vas a usar para identificar al esclavo que queres mensajear. Todos escuchan entonces el ID y si no es el suyo ignoran todo el trafico hasta que el CS vuelva a activarse. Es similar a lo que hace el CAN con su ID y flags para filtrar mensajes, solo que por software;
 

  • Cualquier nodo puede ser Master en un momento dado, enviar o requerir informacion de otro sin molestarse por las colisiones que son resueltas otra vez `por el hardware. Esto permite enviar un reporte por excepcion, por ejemplo, una temperatura alcanzo un valor de setpoint, el nodo la transmite a uno, a varios, o a quien lo quiere escuchar.  Esa tecnica se llama productor/consumidor y realmente permite hacer cosas espectaculares!!
Como dije, no necesito bidireccionalidad...

Desventajas respecto a SPI:
Salvo la velocidad, que podrias llegar a mas de 1 Mbit con bastante esfuerzo, otras no encuentro.

A eso sumale que un uC con CAN no baja de 10 dolares en Argentina, mientras que uno completito con SPI para lo que yo quiero esta menos de 4 dolares(16F887)...y supongo, bien o mal, que necesitas otro integrado para acomodar los niveles a los que exige el protocolo CAN, asi que tenes unos dolares mas ahi por "nodo".

PD: No estoy en ultra defensor del CAN, solo es un analisis objetivo. :mrgreen:

No se noto en absoluto... :lol: :lol:

Yo no digo que no sea mejor, pero la relacion costo/beneficio para mi proyecto me parece que no lo merece.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7881
Re: Longitud cable I2C
« Respuesta #19 en: 01 de Abril de 2010, 08:40:23 »
Vuelvo a la carga, porque esta vez cometes un error grosero en el analisis....

Cuando dices esto:

Citar
    * Usa solo dos cables sin importar la cantidad de nodos (en SPI necesitas los tres hilos mas el pin de seleccion.. wink wink  Hagamos una cuenta simple, preciso 32 nodos, son 3 pines de comunicacion mas...  32 pines CS!!!  Preciso nada mas y nada menos que 35 pines, y bueno pongo un PIC de 100 patillas, total!!  Shocked


No, no es necesariamente asi:
1) Como dije arriba, solo necesito comunicacion unidireccional. Del maestro a los esclavos. Por lo que puedo obviar la senial SDI;
2) El CS es OPCIONAL. Si te las rebuscas un poco no necesitas un CS por esclavo...Podes implementar un solo CS para todos. Cuando ese CS se activa, es porque estas por enviar el ID que vas a usar para identificar al esclavo que queres mensajear. Todos escuchan entonces el ID y si no es el suyo ignoran todo el trafico hasta que el CS vuelva a activarse. Es similar a lo que hace el CAN con su ID y flags para filtrar mensajes, solo que por software;

Salvo que vayas a crear un protocolo SPI-BRUNOF, estas muy equivocado, el direccionamiento de esclavos NO EXISTE en SPI, solo hay habilitaciones de uno u otro chip, que lo hacen las diferentes lineas CS, que podras hacerlas afuera con un chip multiplexor, eso es seguro, pero si quieres respetar el protocolo deberas usarlas.
Por otro lado al no haber direccionamientos por software, es donde saca una importante relacion de velocidad. :mrgreen: :mrgreen:

Referencias del Bus SPI en Wikipedia:
http://es.wikipedia.org/wiki/Serial_Peripheral_Interface
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado Suky

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 6758
Re: Longitud cable I2C
« Respuesta #20 en: 01 de Abril de 2010, 10:45:23 »
Marcos, que tiene de malo poner a escuchar a todos los esclavos? Todos los dispositivos conectados "saben" que el primer byte enviado es un identificador, y si no les corresponde no les afecta. No lo veo difícil de implementar ese protocolo SPI-BRUNOF  :mrgreen:
No contesto mensajes privados, las consultas en el foro

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7881
Re: Longitud cable I2C
« Respuesta #21 en: 01 de Abril de 2010, 10:49:05 »
No hay problema, sabiendo que se sale del estandar y ya no es mas SPI, ni se lograran las tasas de transferencia que promete el estandar.

Entendi que se estaba hablando de comparacion entre buses y por ende yo compare sobre sus estandar, cualquier cambio en su funcionamiento sale del estandar, no es asi?? :lol: :lol:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado Suky

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 6758
Re: Longitud cable I2C
« Respuesta #22 en: 01 de Abril de 2010, 11:11:39 »
No hay problema, sabiendo que se sale del estandar y ya no es mas SPI, ni se lograran las tasas de transferencia que promete el estandar.

Entendi que se estaba hablando de comparacion entre buses y por ende yo compare sobre sus estandar, cualquier cambio en su funcionamiento sale del estandar, no es asi?? :lol: :lol:


Aaaa! Yo creo que la idea es implementar algo rápido y económico, por eso se piensa (Bruno) en implementar el SPI sacándolo del estándar.  ;-)
No contesto mensajes privados, las consultas en el foro

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7881
Re: Longitud cable I2C
« Respuesta #23 en: 01 de Abril de 2010, 12:12:21 »
Va a tener que hacer todo a pulso, porque no le funcionan de ese modo ni las instrucciones por software ni por hardware del compilador...
Menos mal que es barata la hora de programacion aqui, porque de otro modo no hay economia realmente...
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.


 

anything