TODOPIC
FORO TÉCNICO => Foro Técnico => Mensaje iniciado por: DominusDRR en 11 de Noviembre de 2015, 17:14:59
-
Saludos.
Tenemos en mente un proyecto el cual consiste en varias tarjetas electrónicas similares y una principal.
Es decir por decirlo así 4 PCBs “esclavos” y una principal o master.
Cada PCB tiene un microcontrolador.
La idea es que la tarjeta principal, envía órdenes hacia las tarjetas esclavo.
Nuestra intención es que dicha comunicación es mediante cables eléctricos con una longitud máxima de 30 cm.
El primer tipo de comunicación que se me viene a la mente es utilizar RS485, de esa manera mediante un solo bus de datos se comunican los microcontroladores.
La segunda idea es utilizar SPI. Tengo entendido que este tipo de comunicación es útil a cortas distancias entre los dispositivos y que están en el mismo PCB.
Mis preguntas son:
¿Alguien ha utilizado la comunicación SPI mediante cables eléctricos a poca distancia con buenos resultados?
¿Alguna otra idea o sugerencia?
Gracias
-
Si la comunicación es en anillo no te recomiendo ni SPI ni I2C. Yo usaría CAN.
Saludos!
-
Si la comunicación es en anillo no te recomiendo ni SPI ni I2C. Yo usaría CAN.
Saludos!
También se debe considerar lo más económico. Pienso yo que CAN sería de mayor costo, seguido de R485 y finalmente SPI.
Además CAN no es algo común en todos los microcontroladores, es decir tendría que usar micros que posean dicho tipo de comunicación.
-
Encontré un artículo interesante:
http://www.ti.com/lit/an/slyt441/slyt441.pdf (http://www.ti.com/lit/an/slyt441/slyt441.pdf)
-
SPI es para usarlo en la misma placa, si lo quieres usar a distancia deberias unir las masas y alimentaciones, vamos que al final te juntas con demasiados cables. Lo ideal para lo que quieres es RS485. El SPI le afectara cualquier fuente de ruido y no funcionara bien.
-
SPI es para usarlo en la misma placa, si lo quieres usar a distancia deberias unir las masas y alimentaciones, vamos que al final te juntas con demasiados cables. Lo ideal para lo que quieres es RS485. El SPI le afectara cualquier fuente de ruido y no funcionara bien.
Como mencioné antes, no es en la misma placa, es con cables y me parece una buena idea utilizar el SN65C1167 de TI.
-
CAN llevan muchos pics y el transcreiver no es nada caro....
-
Lo ideal para lo que quieres es RS485. El SPI le afectara cualquier fuente de ruido y no funcionara bien.
Creo que tienes razón, RS485 es lo mejor.
-
CAN llevan muchos pics y el transcreiver no es nada caro....
Los PICs que estamos pensamos utilizar no tienen CAN, como mencioné antes, creo RS485 es la mejor opción para no complicarme con los cables como sugiere MerLiNz.
-
¿Qué problema tiene el I2C?
-
Yo estoy entre I2C y RS485.
CAN es tambien una opcion pero si no posee micros con CAN ya se vuelve algo menos viable, y por solo 30cm ... Tambien hay que ver el ruido.
I2C ya posee una forma de direccionar los datos, mientras que RS485 vas a tener que implementar el protocolo.
-
Yo, claramente, si se quieren hacer las cosas bien para esta aplicación bus can, muy robusto y es para una distancia no muy corta, ni muy larga. En mi opinión es claramente el mejor bus para este caso, además hay pic18 con can, no es nada inusual.
Si fuera mas larga rs485, y si fuera en el mismo hardware o mediante conector directo, i2c.
Con lo dicho anteriormente, que no se quiere can, con el rs485 habría que desarrollar el protocolo, además de mas hardware,... entre el spi y en i2c me quedo con i2c con el spi tienes que tirar mas cables. Con I2C maximo 4 cables ,si además llevas el positivo, cosa que es mas que recomendable ya que hay que polarizar el bus y si no llevas el positivo debes polarizarlo en todas la placas y si es asi, contando la distancia y la poca diferencia entre referencias de tensión en las masas que exista, sumado a la tolerancia de los reguladores de cada placa, puede dar lugar a ruido.
-
¿Qué problema tiene el I2C?
El no poseer señal de reloj y la baja velocidad hace que sea menos confiable, creo yo.
-
Para mi, realizar un protocolo de comunicación no es problema alguno. Respecto a la I2C, es más simple y sencilla a nivel de hardware, pero me parece que es menos confiable y no tan eficaz frente al ruido.
-
¿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
El spi es mas robusto pero por cada periférico tienes que lanzar un cable mas, con i2c 4 cables y tienes 255 dispositivos, en esta aplicación no creo que notes la diferencia entre spi o i2c en tema de errores.
Si no te preocupa el cableado y van a ir conectados todos a una placa central, usa spi, si quieres un bus que se pueda conectar en estrella o en triangulo ( me refiero conectar todos a uno central o poder conectarlos entre ellos) usa i2c.
-
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.
-
¿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.
-
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.
-
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
-
¿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" :lol:
-
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.
-
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.
-
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
-
((:-))
(https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-xfa1/v/t1.0-9/12249788_10153740432012342_7486188506701994748_n.jpg?oh=e75029a8b66a6e60f98a658580307c2b&oe=56BCB8C6&__gda__=1454346539_2a8b013263fa9d815b99e7e07cc7dbfd)
-
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.
-
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.
-
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 (https://es.wikipedia.org/wiki/AS-interface)
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.
-
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 (https://es.wikipedia.org/wiki/AS-interface)
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. :-/
-
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.
-
por cierto, si el proyecto no es comercial puedes mirar estos que tienen muestras gratis:
http://www.ti.com/product/SN75LBC176/samplebuy
saludos