¿Cómo finalizar el envío de datos a través de I2C por Slave o Master?

Pero me pregunto cómo se lleva a cabo este apretón de manos entre un Maestro y un Esclavo cuando el Esclavo es el remitente y el Maestro es el receptor y solo el Esclavo (remitente) sabe cuándo no hay más datos para enviar al receptor.

Esto no se supone que suceda. i2c es un protocolo muy definido y cada dispositivo esclavo debe ser conocido por cada maestro. Por lo general, el maestro solicita al esclavo que transmita, y el tamaño del mensaje es fijo, el mensaje es secuencial o el mensaje incluye cuántos bytes se enviarán.

1. El maestro escribe una dirección de registro, luego el maestro cambia a lectura y el esclavo envía un byte. Eso es todo lo que quiere el amo, envía una parada.

2. El maestro escribe una dirección de registro, luego el maestro cambia a lectura y el esclavo envía un byte, luego el maestro vuelve a leer, por lo que el esclavo envía el siguiente byte (o el mismo byte). El maestro lee cuantos quiere, arbitrariamente, y luego envía una parada.

3. El maestro escribe una dirección de registro, luego el maestro cambia a lectura y el esclavo envía un byte. Ese byte le dice al maestro cuántos bytes debe tener ese registro. El maestro lee y el esclavo envía esa cantidad, luego el maestro se detiene.

Toda la comunicación es controlada por el maestro. El esclavo no hace nada que el amo no quiera que haga. El maestro controla la velocidad del reloj (a pesar del estiramiento del reloj) y cuántos bytes se leen. En ningún momento el esclavo debe intentar forzar la línea de datos cuando el maestro no se lo indique. La estructura de datos debe conocerse de antemano.

Esas son las dos opciones.

Si el receptor esclavo no acepta más datos, puede NAK el byte, pero el maestro sigue siendo responsable de enviar la condición de parada.

Para un transmisor esclavo, no puede señalar nada para que se detenga, debe saberse de antemano o podría estar codificado en los datos, por ejemplo, la cadena de texto termina con un cero para que el esclavo pueda transmitir ceros hasta que el maestro se detenga.

Por lo general, esto es raro y existe un protocolo conocido, por lo que el maestro siempre debe saber de antemano cuántos bytes leerá o escribirá en una sola transacción, incluso si eso significa transferir primero un encabezado de tamaño fijo entre dispositivos y cuánto transferir.

Digamos que un Esclavo o Maestro está enviando múltiples bytes al receptor en el bus I2C y la cantidad de bytes no está definida de antemano. Entonces, ¿cómo le dirá el remitente al receptor que no tiene más datos para enviar?

Si Master es el remitente, entonces sabe cuántos bytes se deben enviar. El maestro señalará el final de su transferencia de datos enviando una condición de PARADA después de enviar el último byte y terminará la transacción.

Tenga en cuenta que el Maestro puede hacer esto en cualquier momento. El esclavo puede enviar NACK para decir que no quiere recibir más datos. Pero solo el Maestro decide si detener esta transacción.

Pero me pregunto cómo se lleva a cabo este apretón de manos entre un Maestro y un Esclavo cuando el Esclavo es el remitente y el Maestro es el receptor y solo el Esclavo (remitente) sabe cuándo no hay más datos para enviar al receptor.

Si Slave es el remitente, Master debe saber de antemano cuántos bytes se deben recibir. El maestro lo señalará enviando un NACK después de recibir el último byte para que el esclavo ya no maneje la línea SDA. El Maestro ahora puede iniciar una condición de PARADA y terminar la transacción.

Tenga una buena lectura aquí: TEXAS i2c

Voy a digerir todo tu post poco a poco...

Digamos que un Esclavo o Maestro está enviando múltiples bytes al receptor en el bus I2C y la cantidad de bytes no está definida de antemano.

Pero debe definirse. Si se enviaba o recibía información aleatoria, nunca podrá interpretarla.

Entonces, ¿cómo le dirá el remitente al receptor que no tiene más datos para enviar?

El fabricante determina cuántos bits necesita recibir del esclavo. El maestro generalmente está escrito por algún dispositivo lógico como un microcontrolador, CPU, etc.

Hasta ahora lo que entiendo es que para el caso en que el remitente es Maestro, envía un NACK para decirle al Esclavo (Receptor) que no hay más datos para enviar.

No, no del todo correcto correcto. Un "NACK" ocurre cuando el maestro no "escucha" nada del esclavo después de enviar este bit al esclavo. Es como estar al teléfono y decir: "Hola, ¿estás ahí?"

Pero me pregunto cómo se lleva a cabo este apretón de manos entre un Maestro y un Esclavo cuando el Esclavo es el remitente y el Maestro es el receptor y solo el Esclavo (remitente) sabe cuándo no hay más datos para enviar al receptor.

Tu definición de emisor y receptor está sesgada. Tanto el maestro como el esclavo actúan como emisor y receptor. El maestro puede enviar y recibir, según las operaciones de escritura o lectura, respectivamente.

Consejo útil: considere leer cualquier hoja de datos de esclavos I2C. Busque la palabra clave, "mensaje". Esta es la información que el maestro envía al esclavo.

Foto de aquí ... no es mi foto.

El maestro debe programarse para leer la misma longitud del marco de dirección que el esclavo, que está definido por la hoja de datos del esclavo. También puede establecer una dirección de un esclavo, pero por lo general no mucho. Esto ayudará a abordar el conflicto si dos esclavos comparten la misma dirección.

Aquí hay un ejemplo de una parte con la que trabajé recientemente, es un controlador de intercambio en caliente ADM1276. Cumple con las especificaciones de PMBUS, pero aún se aplica la topología I2C. Le informa las interacciones del maestro y el esclavo cuando envía, recibe, lee y escribe bytes.

No hay nada en el protocolo i2c que resuelva este problema. Puede hacer que funcione, pero usará algún software para hacerlo. Dado que i2c fue diseñado para la comunicación de hardware, que generalmente involucra registros de tamaño fijo, no se proporcionó nada para manejar datos de longitud variable. Lo descubrí yo mismo y tuve que resolver el mismo problema que está considerando.

Dado que el maestro controla todo, todo lo que el esclavo puede hacer es enviarle pistas sobre la cantidad de datos que debe enviar. Lo que mejor me ha funcionado es hacer que el esclavo envíe la longitud como el primer byte. Entonces el maestro sabe cuántos bytes necesita pedir.

El propio protocolo no permite tal acción, pero no es nada que no se pueda solucionar con programación.

Dos posibles opciones posiblemente:

1. Que el profesor primero pida un valor en este caso entero (menos de 255) y este será el tamaño de los datos que enviarás después en la próxima llamada que hagas.

2. Si tiene conocimiento de la longitud máxima que tendrán los datos a enviar, tome esto como referencia, conviértalo en un arreglo o cadena y agregue un carácter específico que va a tomar para marcar dónde terminan sus datos y en el maestro. vuelves a convertir en el tipo de datos que estás usando. Con los datos más pequeños, complete el resto de la cadena con su carácter especial y listo, siempre enviará una cadena con el mismo tamaño.