¿Cuál es el bus serie integrado más popular? [cerrado]


8

Estoy diseñando un dispositivo integrado que me gustaría hacer interoperable con periféricos de terceros a través de un bus serie. ¿Debo elegir SPI, I²C o algún otro autobús?

Los periféricos tendrán un ancho de banda bastante bajo (algunos sensores que se comunican a través del bus, sondeados periódicamente) y probablemente dentro de un metro o menos del controlador. La única tarea del controlador es recopilar los datos del sensor, empaquetarlos de alguna manera y luego enviarlos a un módulo inalámbrico a través de otro bus (aunque el bus del sensor también podría reutilizarse para esto).


3
Depende de los periféricos con los que desee interoperar, a qué voltajes, a qué velocidades y a qué distancia.
Toby Jaffey


1
No puedo creer que UART no haya sido mencionado en absoluto ... Solo digo.
vicatcu

Corrígeme si me equivoco, pero no pensé que UART fuera un autobús. Pensé que era solo comunicación en serie entre dos dispositivos.
pfyon

¿Entonces un bus no es para comunicación serial entre dos dispositivos? ¿Lo estás descartando porque a veces solo se usa punto a punto? PCIe, SATA, HT son generalmente punto a punto. En cualquier caso, la mayoría de los periféricos UART se pueden usar para RS-422, RS-485 o LIN, que son multipunto.
Nick T

Respuestas:


12

Si no está seguro, y sus requisitos son bastante vagos, elegiría I²C.

La principal diferencia entre SPI e I²C es que SPI requiere una línea de selección de chip para cada periférico. I²C emite una dirección periférica al comienzo de la comunicación, por lo que no necesita líneas de selección de chip. Las líneas de selección de chip se vuelven engorrosas después de las primeras.

Por otro lado, SPI es probablemente más fácil de implementar y depurar. Podría ser el ganador si solo quieres conectarte a un par de dispositivos.

Descartaría USB a menos que necesite altas velocidades de datos en distancias relativamente largas (m en lugar de cm). También descartaría RS-232 a menos que todavía sea 1976 y sus periféricos necesiten una señal masiva para distinguir un poco del ruido.

Puede considerar Dallas 1 cable, pero sospecho que no es tan común como I²C, y un autobús de "1 cable" que necesita 2 cables para funcionar siempre me ha parecido un poco sospechoso.


1
Creo que si tiene un controlador muy simple y necesita usar bit-banging (básicamente operando manualmente el reloj), es mucho más fácil implementar SPI en 4 puertos sobrantes de GPIO.
Wouter Simons

1
Creo que tienes razón acerca de que es más fácil bitbang SPI que I2C. Sin embargo, espero que no se reduzca a golpes.
pfyon

3
+1 para el carácter sospechoso del sistema de 2 cables comercializado como "1 cable".
semaj

Y para empeorar las cosas, muchos chips que implementan el sistema de 1 cable (+ tierra) requieren un tercer pin, Vcc, ¡porque no pueden funcionar con energía parasitaria! Cuando pienso en un bus de 1 cable, estoy imaginando una configuración acoplada capacitivamente, con un rectificador de puente limitado por corriente y un código de línea de auto reloj; No 2 o 3 cables.
Kevin Vermeer

"1-wire" debería haberse llamado "1-data-wire", ya que eso es más lo que es. Los cables adicionales son GND y (a veces) una línea de alimentación estable.
Johan

3

Como dijiste que sería de poco ancho de banda, asignaría suficiente IO para manejar tanto SPI como I2C. Si fuera posible, también tendría líneas CS adicionales para que pueda ejecutar múltiples dispositivos SPI. Tampoco olvides ver cómo vas a alimentar el periférico. Si se está quedando sin batería para obtener una vida útil máxima, debe poner el dispositivo en modo de bajo consumo o desconectarlo cuando no esté en uso. Utilice también el módulo de controlador serie de los controladores si es posible, muchos controladores mux SPI, I2C y serie. Si puede y separe la conexión inalámbrica del sensor, esto hace que sea más fácil apagar los dispositivos cuando no estén en uso. Además, algunos sensores tienen una línea que le indicará al controlador cuándo deben ser reparados, por lo que también querrá tener un IO adicional en un pin, idealmente desde el que pueda generar una interrupción.


2

La pregunta es un poco problemática debido a problemas de definición.

La comunicación serializada es básicamente lo que necesita si desea comunicarse con algún periférico externo sin usar innumerables puertos en su controlador. Básicamente, cada método de comunicación en serie necesita un reloj y una configuración sobre cómo manejar las conexiones de datos.

SPI es un bus de 4 hilos. I2C es un bus de 2 cables.

Cada uno tiene características diferentes. Lo que debe responder es qué tan rápida debe ser su comunicación, qué tan confiable debe ser, qué opciones ofrece su microcontrolador, etc.

Este artículo de wikipedia y este sitio de referencia explican mucho más claramente que yo, ¡también siga las referencias para aprender aún más!


2

Básicamente, debe elegir entre I2C y SPI.

Independientemente del bus que use, debe considerar el nivel de voltaje de sus sensores y periféricos de terceros. Puede hacer esto haciendo su propio convertidor con dos MOSFETS (solo va en una dirección: recoger / no cambiar o bajar / no cambiar; solo es un problema si necesita ejecutar sus sensores a 3.3 e interactuar con maestros de 1.8 y 5V). Ver AN10441 de NXP [PDF]. Esto también funcionará para SPI (solo elimine los pullups). Deberá agregar una línea a su conector para establecer un voltaje de referencia (si aún no lo está haciendo).

Una desventaja de I2C es que estás limitado al reloj más lento del autobús. Si un sensor solo es capaz de 100kHz y desea hablar con su memoria a 400kHz o 1MHz (ambas velocidades válidas), el comportamiento de su sensor más lento no está especificado. Si usa SPI, la línea de selección de chip significa que el sensor más lento ni siquiera escuchará lo que hay en el bus, y puede ejecutar diferentes velocidades para diferentes sensores.


1

Yo usaría I2C. Solo asegúrese de obtener un módulo inalámbrico que pueda comunicarse a través de I2C si desea tenerlo en el mismo bus que sus sensores. La mayoría de los periféricos de comunicaciones que he visto usan SPI, no I2C.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.