Razón para elegir dispositivos flash basados ​​en SPI sobre los I2C [duplicado]

Revisé el siguiente enlace que dice que u-boot admite tres tipos de tecnología flash

http://www.stlinux.com/u-boot/flash

1. Nand 2. NOR 3. Flash serie SPI

Me gustaría saber por qué se elige SPI para usarse como dispositivos flash, no como I2C.

¿Por qué no podemos tener tecnología flash basada en I2C?

Respuestas (2)

Hay tres razones por las que siento que SPI es una mejor opción que I2C en la mayoría de los proyectos.

  1. SPI se puede sincronizar más rápido que I2C. He usado SPI hasta 50Mhz en circuitos integrados que admiten esa velocidad, mientras que la velocidad máxima de I2C es de 3,4Mhz.

  2. Dado que I2C es una línea de datos 'compartida', el maestro debe liberar el control de la línea de datos para que el esclavo responda. He estado quemado en varios proyectos antes donde el maestro liberó el control y el IC esclavo procedió a bloquearse (principalmente debido al ruido en la línea). Ahora estás en un estado en el que ambos lados están esperando que el otro responda y necesitas reiniciar todo. Muy frustrante. Con SPI, deja de lado todas las líneas de datos compartidos porque cada línea tiene una dirección dedicada.

  3. Si tiene una diferencia de nivel de voltaje entre sus circuitos integrados (por ejemplo, 3,3 V frente a 5 V), los traductores de voltaje unidireccionales son más fáciles de manejar que el tri-estado necesario para I2C.

En una nota al margen, me resulta más fácil depurar SPI si está utilizando las líneas de selección de chip, ya que puede usar esa línea para activar su alcance. Básicamente, todo se reduce a que, si tiene los pines de repuesto, use SPI y ahórrese el dolor de cabeza. Si, por otro lado, solo tiene 2 pines, está atascado con I2C. Pero en serio, agregue una línea de reinicio separada a su IC esclavo I2C, para que tenga un medio de recuperación de un bus colgado.

Gracias @Peter por su útil respuesta. ¿Podría elaborar el segundo punto con mayor detalle?
¿Es posible que se cuelgue un sistema de un maestro, un esclavo? Ciertamente, es posible que dos esclavos cooperen para colgar el bus, aunque si los esclavos limitaran la corriente de manera segura cuando intentan conducir afirmar SDA cuando fue tirado externamente a un nivel alto "rígido", un maestro debería poder "desatascar" el bus. haciendo que el maestro domine brevemente cualquier dispositivo que lo esté bajando lo suficientemente bien como para que todos los demás dispositivos vean una transición de bajo a alto.
@supercat No recuerdo el IC esclavo que estaba usando en ese momento, pero se bloqueaba cuando el maestro cambiaba al modo de recepción. El IC colgado derribaría todo el autobús y perdí la comunicación con todo. Dado que el estándar I2C especifica resistencias pull up para proporcionar energía al bus, realmente no hay forma de desatascarlo con un alto rígido. Incluso si su maestro puede sobrecargar las líneas y puede hablar con el resto de los IC esclavos, aún no pueden responder debido al IC original colgado. Supongo que lo que digo es que I2C es un último recurso para mí. Chico fanático de SPI firmado. ;)
@Peter: No hay ninguna circunstancia en la que una implementación de esclavo adecuada bloquee un bus I2C. Lo que puede suceder es que dos esclavos intenten generar cadenas interminables de bits cero y busquen pulsos ACK en diferentes momentos. En ese caso, cada esclavo liberará el bus durante un reloj de cada nueve, pero juntos mantendrán el bus para siempre. En un ciclo en el que un esclavo está emitiendo un cero y el otro está buscando un ACK, dominar el que estaba emitiendo un cero haría que el otro viera una parada/reinicio, por lo que ya no reduciría el SDA. Puede ser...
... es necesario repetir la secuencia de sobrealimentación/reloj nueve veces antes de que un dispositivo que está bajando el autobús mire el autobús y pueda ver la parada/reinicio, pero debería ser posible desatascar las cosas. Por supuesto, SPI no tiene ese problema y tiene algunas otras ventajas; Sin embargo, desearía que alguien promoviera una variación de SPI que usara tres cables en lugar de cuatro y pudiera manejar eventos de protocolo de enlace y/o activación.

Banda ancha. I 2 C alcanza un máximo de 3,4 MHz. SPI no suda a 50MHz. Obviamente, se requiere un enrutamiento inteligente si desea alcanzar esa velocidad, pero es posible.

Además, múltiples canales. SPI puede funcionar en "modo cuádruple", donde se transfieren 4 bits cada ciclo en lugar de 1. Esto da como resultado una velocidad de datos de decenas de megabytes por segundo.

Gracias @Ignacio por su rápida respuesta. ¿Ve alguna otra razón para elegir Flash basado en SPI? Me han dicho que es fácil conectar/quitar el controlador SPI a los dispositivos flash porque utiliza la selección de chip que permite una fácil gestión de los dispositivos flash esclavos. pero en el caso de i2c, se solucionaría en su mayoría. ¿Podría darnos su opinión sobre lo mismo?
Por lo general, solo hay un dispositivo flash en un sistema. El mecanismo de selección no es muy importante en ese punto.
Razón para elegir dispositivos flash basados ​​en SPI sobre los I2C [duplicado]
RespuestasAquíPolítica de privacidad1y, 0v