¿Puede un esclavo SPI iniciar una transmisión en modo full-duplex?

Hasta donde sé, la transmisión SPI para un esclavo SPI funciona de la siguiente manera:

1. El maestro selecciona un esclavo usando el pin SS
2. El maestro y el esclavo se envían datos entre sí simultáneamente
3. El maestro inicia el reloj y la transmisión de datos al mismo tiempo (no hay reloj antes de la operación de escritura)
4. El maestro detiene la transmisión cuando lo desee (al detener la operación de escritura y la generación del reloj), incluso si el esclavo tiene más datos para enviar.

¿Existe alguna configuración de esclavo SPI que permita al esclavo transmitir datos sin permiso del maestro?

Solo estoy pensando en voz alta. Suponga que solo hay un esclavo y que el maestro proporciona un reloj continuo, etc.

Incluso si la afirmación asumida es verdadera, ¿el maestro y el esclavo no pierden la sincronización de bytes (es decir, recibe el flujo de bits) ya que no hay bits de inicio-parada para SPI?

Estoy haciendo esa pregunta porque he leído la siguiente sección de este documento .

2.2 Ejemplo de SPI

El ejemplo de SPI adjunto ilustra el uso de USART en modo síncrono. USART1 está configurado como esclavo, mientras que USART2 es maestro. Se realizan las siguientes transacciones:

• Transmisión de datos de maestro a esclavo.
• Transmisión de datos de esclavo a maestro.
• Transmisión de datos de maestro a esclavo y de esclavo a maestro simultáneamente.

El documento da un ejemplo de SPI pero se da cuenta del ejemplo usando dispositivos USART. Y entiendo que un esclavo USART puede iniciar una transmisión sin permiso del maestro.

No pude encontrar el código fuente al que hace referencia el documento.

No, con SPI, todas las comunicaciones son conducidas por el dispositivo maestro. Tiene razón en que el maestro no puede simplemente proporcionar un reloj continuo; no habría forma de detectar los límites de bytes.

Un dispositivo esclavo a menudo tendrá un pin de salida separado para indicarle al maestro que tiene datos disponibles. Este pin está conectado a una entrada en un microcontrolador y a menudo se usa como una interrupción.

Luego, el dispositivo puede reafirmar el pin, haciendo que el microcontrolador haga girar el bus SPI.

Para obtener información más detallada, lea :) Esta es una versión ligeramente modificada de una explicación que se encuentra aquí :

El dispositivo esclavo solo puede comunicarse cuando se le proporciona un reloj del maestro. Esto complica la lectura del esclavo, porque debe hacer que el maestro proporcione suficientes ciclos de reloj para que el esclavo responda.

Cuando envía un comando SPI desde el maestro, dos transmisiones suceden realmente durante los mismos ocho pulsos de reloj. La primera es que su byte está fuera de la línea MOSI. Pero, al mismo tiempo, los datos se registran en el microcontrolador a través de la línea MISO.

Pero como el esclavo no obtiene el comando completo hasta el final de estas transacciones, no presenta ningún dato al bus. Esto da como resultado un valor recibido de 0x00 o 0xFF.

Luego, debe proporcionar ocho relojes adicionales para permitir que el esclavo devuelva el valor real. En muchas implementaciones de código, esto se realiza enviando un "byte ficticio" al esclavo.

Tenga en cuenta que, en la primera transmisión, el maestro ignora todo lo que llega del esclavo. En la segunda transmisión, el esclavo ignora todo lo que envía el maestro.

Eso describe el caso general. Puede haber complejidades adicionales. Por ejemplo, algunos IC esclavos realmente emitirán algún tipo de byte de estado al mismo tiempo que reciben un comando del maestro. Entonces, en este caso, el maestro no debe descartar el primer byte recibido.

No, el maestro es el que arbitra los chipselect y maneja el reloj. Un esclavo siempre solo escuchará el reloj y el chipselect. La transferencia de datos puede ser full duplex aún. Hay algunas implementaciones en las que el reloj puede ser continuo, pero no importa mucho ya que el chipselect se utiliza para sincronizar los límites de bytes de todos modos. Pero luego hay sistemas multimaestro, así que básicamente puedes tener algún mecanismo para que los dispositivos decidan quién es esclavo y maestro. O simplemente incluya un cable de "interrupción" separado para que el esclavo le señale al maestro que tiene un paquete de datos para el maestro.