Sugerencia para comunicación entre microcontroladores.

[manwenwe]

Si tienes pines de sobra también puedes poner un serializador: hacerte un SPI de 8 hilos (sin chip select) son unas cuantas líneas de código. Y lo pasarías todo por dos cables como en CAN e igual de robusto. Pasas dirección (que incluya w/r) + datos y arreglado. En cada esclavo un deserializador.

Saludos.

[Jorge555]

¿Qué problema tiene el I2C?

Que hay que controlar la capacitancia del bus que por norma no pueden exceder los 400 pF en I2C (si recuerdo bien) ni 1 us el tiempo de subida en SMBUS. La salidas son el colector abierto a través de una R de pull-up, y si metes pistas muy largas, muchos dispositivos o cables, la capacitancia del bus se va a incrementar haciendo que los tiempos de subida de las señales sean largos y por tanto reduciendo la frecuencia máxima de la señal de reloj.

Se puede usar I2C con cables, siempre que el cable no sea muy largo, y lo suyo es añadir un buffer, página 8: http://www.nxp.com/documents/data_sheet/PCA9517A.pdf

Con 30 cm de cables y viendo la capacitancia que tiene éste pues hay que ver si es viable.

Otro motivo es la velocidad del reloj, en I2C son 400 KHz la máxima. Ventajas, solo dos cables más referencia, multimaster y es fácil de implementar.

[Picuino]

También hay que tener en cuenta que una cosa es el protocolo físico y otra el lógico y no tienen por qué ser iguales.
Si quieres puedes implementar un protocolo con cableado SPI a varios Mbaudios, con drivers físicos RS485, sobre cable ethernet RJ45, con protocolo lógico CAN.
Las combinaciones son infinitas. Depende de la aplicación.

Una buena combinación podría ser RS232 (UART) (sencillo, rápido, muy extendido) con algún driver físico CAN que haga las comunicaciones más inmunes al ruido y el cableado que tu quieras (puedes llegar a trenzar el hilo de datos con un hilo de masa).
Las líneas Tx y Rx van sobre un mismo hilo, por lo que tienes que definir tú mismo el protocolo, por ejemplo el RS485.

Un saludo.

[juaperser1]

por lo que tienes que definir tú mismo el protocolo, por ejemplo el RS485.

Pero picuino, rs485 no es un protocolo, es un estándar de comunicación bus , es decir, un módelo de capa fisica, un protocolo se puede programar sobre un rs485, pero este en si no es un protocolo.

Un saludo

[DominusDRR]

¿Qué problema tiene el I2C?

El no poseer señal de reloj y la baja velocidad hace que sea menos confiable, creo yo.

La señal scl es la del reloj, también mientras mas baja sea la velocidad mejor para evitar fallos. Depende de la velocidad que necesites utiliza siempre la mas baja que te permita tu aplicación, es como el uso de la frecuencia, utiliza la menor para tu aplicación, así tu micro no trabaja en valde y metes menos ruido por la mas alta frecuencia de funcionamiento a otras partes del hardware

Tienes razón, la I2C si posee señal de reloj. Se me han cruzado los cables. "Errare humanorum est" 

[DominusDRR]

Muchas gracias a todos por las sugerencias y comentarios, sin embargo desearía conocer si alguien ha intentado hacer dicho proyecto con SPI entre microcontroladores con cables.

[elgarbe]

Yo estoy haciendo un cartel RGB. El micro saca los datos por el bus SPI (solo escrive, no lee). Voy a trabajar a un par de MHz. Los cables miden unos 30cm. Para asegurar un poco de inmunidad ante ruido externo me habían sugerido intercalar un cable de GND entre cada señal (yo uso cable plano) y esos GND conectarlos en un solo extremo. O sea, mi cable plano es GND - CLK - GND - MOSI - GND - LAT - GND - BLANK - GND....
con esas premisas no tenes que tener problemas con 30cm de cable.

[elgarbe]

por cierto, picuino puso este interesante post http://www.todopic.com.ar/foros/index.php?topic=44966.0, en él encontré en su momento esta AN que puede servirte:

https://www.fairchildsemi.com/application-notes/AN/AN-393.pdf

saludos

[DominusDRR]

 

[elgarbe]

Esta claro que esas son las aplicaciones típicas, o la aplicacion para la cual se desarrollo. Lo que no quita que se pueda utilizar en otro contexto.

Por cierto, el lugar donde van a trabajar las placas, está lleno de ruido eléctrico?

sds.

[DominusDRR]

Esta claro que esas son las aplicaciones típicas, o la aplicacion para la cual se desarrollo. Lo que no quita que se pueda utilizar en otro contexto.

Por cierto, el lugar donde van a trabajar las placas, está lleno de ruido eléctrico?

sds.

Si, es por eso que se debería usar transceivers como el  SN65C1167.

Es un horno de inducción de con 4 bobinas independendintes.

[Picuino]

Yo he unido placas con I2C con cables relativamente largos y sin apantallar y sin ningún problema. Casi todo funciona bien en casa.

En ambiente industrial la cosa es distinta. Yo iría a por una solución ya probada y desarrollada.
Los dos estándares industriales son CAN bus (DeviceNet de Rockwell - Allen-Bradley) y RS485 (Profibus Siemens).
También puedes echar un vistazo al estandar AS-I
Fieldbus, basado en ethernet, es otro a tener en cuenta.

Hay muchos componentes en el mercado. No son baratos, pero desarrollar todo tú desde cero tampoco lo es.

Un saludo.

[DominusDRR]

Yo he unido placas con I2C con cables relativamente largos y sin apantallar y sin ningún problema. Casi todo funciona bien en casa.

En ambiente industrial la cosa es distinta. Yo iría a por una solución ya probada y desarrollada.
Los dos estándares industriales son CAN bus (DeviceNet de Rockwell - Allen-Bradley) y RS485 (Profibus Siemens).
También puedes echar un vistazo al estandar AS-I
Fieldbus, basado en ethernet, es otro a tener en cuenta.

Hay muchos componentes en el mercado. No son baratos, pero desarrollar todo tú desde cero tampoco lo es.

Un saludo.

Gracias por la sugerencia. He tomado la decisión de utilizar RS485, quería ahorrarme la utilización de transceivers, pero como dice el dicho "lo barato sale caro". Prefiero que mi sistema de comunicación sea robusto.

Respecto al desarrollo del firmware desde cero, no es un problema para mí. Gracias de nuevo. 

[elgarbe]

Esta claro que esas son las aplicaciones típicas, o la aplicacion para la cual se desarrollo. Lo que no quita que se pueda utilizar en otro contexto.

Por cierto, el lugar donde van a trabajar las placas, está lleno de ruido eléctrico?

sds.

Si, es por eso que se debería usar transceivers como el  SN65C1167.

Es un horno de inducción de con 4 bobinas independendintes.

bueno, creo que con esos transeiver se soluciona todo. El cableado sería par diferencial...

sds.

[elgarbe]

por cierto, si el proyecto no es comercial puedes mirar estos que tienen muestras gratis:

http://www.ti.com/product/SN75LBC176/samplebuy

saludos