I2C que combina la operación de lectura y escritura

Estoy diseñando mi propio protocolo de datos para la comunicación entre PIC, IC, etc. y en la especificación me gustaría compararlo con el protocolo I2C existente.

Hay dos tipos de funcionamiento en el bus I2C:

  • Operación de escritura: el maestro escribe INICIO, dirección, datos (el esclavo solo envía ACK)
  • Operación de lectura: el maestro escribe INICIO, dirección. El esclavo envía datos, el maestro envía ACK/NACK.

Solo para aclararme esto: ¿hay alguna forma de usar estas operaciones, de acuerdo con la especificación del protocolo, para leer y escribir datos dentro de una sola operación? Ganarías en rapidez porque no tienes que enviar dos veces la dirección. Entonces, ¿es esto posible?

¿Qué pasa con algo como SPI? Creo que puede hacer una comunicación bidireccional ya que hay líneas de datos de entrada / salida separadas.
Sí, pero esa no es mi pregunta.
¡es bastante obvio que un cable de datos no se puede usar para una lectura y escritura simultáneas!
Es por eso que cambié la pregunta a `leer y escribir datos dentro de una operación', para que no tenga que ser exactamente al mismo tiempo.
¿Realmente necesitamos otro protocolo para la comunicación entre IC?
Bueno, necesito... Pero creo que puede agregar algo. Necesitaba una interfaz de 2 líneas para una gran cantidad de datos, cuando no estás cambiando de esclavo todo el tiempo. I2C es ineficiente ya que tiene que enviar la dirección cada vez.

Respuestas (4)

No hay forma de hacer lo que quiere y seguir el protocolo I2C. Lo más cercano que puede obtener es la condición de "Inicio repetido". Incluso con un inicio repetido, debe enviar la dirección una segunda vez para leer.

El "inicio repetido" se utiliza en el caso de un sistema multimaestro y permite que un maestro bloquee el bus y evite que otro maestro lo tome. En lugar de emitir un bit de parada, el maestro envía otro bit de inicio y retiene el control del bus hasta que se envía el bit de parada. De esta manera, podría llamar al inicio repetido una sola "operación", aunque se pueden realizar múltiples lecturas/escrituras.

En su protocolo teórico, ¿cuánta velocidad cree que ganará si no emite la dirección por segunda vez? ¿Es ese ahorro de tiempo necesario para su diseño?

Hay algunos escenarios realistas en los que poder alternar lecturas y escrituras en una sola transacción podría suponer una diferencia de velocidad superior a 2:1. Potencialmente mucho mayor con algunos subsistemas DMA.

No del todo posible. Dado que hay un solo pin de entrada y salida de datos, no puede leer y escribir simultáneamente.

No tiene que suceder simultáneamente. Podría ser algo como: el maestro escribe INICIO, dirección, datos, envía un AHORA ESCRIBE y luego los esclavos escriben, finalizan la transmisión. ¿Pero eso no es posible en I2C? (Edité mi pregunta: ¿es posible leer y escribir en una sola operación?)
@CamilStaps: pero preguntaste sobre "leer y escribir datos al mismo tiempo". ¿Qué pasa con eso que no especifica que suceda simultáneamente?
Sí, eso no fue bien preguntado. Lo que quise decir fue en la misma operación. Perdón por la confusion.

I2C utiliza el bit menos significativo del byte de dirección para controlar si la operación es de lectura o escritura. Pase lo que pase, la dirección siempre se envía al comienzo de una transacción y se envía si hay un reinicio, por lo que su declaración sobre no tener que enviar la dirección dos veces no tiene sentido para mí.

En una escritura/lectura "combinada", todavía hay una sobrecarga de direcciones:

  • El maestro envía Inicio, luego la dirección del esclavo + escritura; esclavo acks
  • El maestro envía datos, el esclavo reconoce
  • El maestro envía Reiniciar, luego la dirección del esclavo + leer; esclavo acks
  • El esclavo envía datos, el maestro ACK/NACK
  • Maestro envía Stop

Si desea una comunicación verdaderamente simultánea, necesita múltiples buses I2C independientes (y obviamente múltiples maestros y esclavos).

¿Quiere ahorrar velocidad al no escribir 8 bits adicionales a 100/400/1000khz? Solo te estarías ahorrando (a 100khz de velocidad) 8/100000 segundos (0,08 milisegundos/80 microsegundos). Es una cantidad trivial de datos.

Pero, no se puede hacer en el estándar i2c o SMBUS . Pero si está escribiendo su propio protocolo de datos, adelante, es su protocolo, usted decide si puede combinar read/right . Diséñelo de modo que un inicio repetido signifique que solo el mismo esclavo que fue direccionado con el inicio inicial entre en modo de lectura sin direccionamiento.

Inicio - Escribir dirección - Datos - Datos - Reiniciar - Leer - Leer

Sin embargo, no cumplirá con el estándar i2c.

Me pregunto por qué ni el estándar I2C ni las implementaciones típicas de esclavos proporcionan ningún medio para cambiar de dirección en medio de una transacción [por ejemplo, lecturas y escrituras alternas] ni permiten que los esclavos participen en el arbitraje. Si cada esclavo tuviera una identificación única de 32 bits, tales capacidades harían posible tener un comando para, por ejemplo, "leer la identificación de todos los esclavos conectados" sin requerir que los esclavos tengan direcciones preasignadas únicas.
@supercat 1-wire, estás pensando en 1-wire.
No estaba pensando en un cable (cuyo método de búsqueda he usado, por cierto), sino en una situación en la que me hubiera gustado tener varios esclavos en un bus de dos cables y hacer que informen automáticamente sus ID de manera simple y limpiamente. Si el hardware esclavo I2C pudiera manejar la pérdida de arbitraje de una manera similar a los maestros, tal cosa podría haberse implementado de manera muy elegante.