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

Hasta donde yo 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 en cualquier momento que lo desee (deteniendo la operación de escritura y la generación de reloj), incluso si el esclavo tiene más datos para enviar.

¿Hay alguna configuración de esclavo SPI que permita que el esclavo transmita datos sin el permiso del maestro?

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

Incluso si la declaración supuesta es verdadera, ¿el maestro y el esclavo no pierden la sincronización de bytes (es decir, reciben un flujo de bits) ya que no hay bits de inicio y parada para SPI?

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

2.2 Ejemplo SPI

El ejemplo de SPI adjunto ilustra el uso del 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 realiza el ejemplo utilizando dispositivos USART. Y me sale 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.

El esclavo, por definición, no puede iniciar una transacción (aunque puede interrumpir al maestro para iniciar una transacción).
La transferencia de datos unidireccional en SPI tradicional es simplemente alguien que ignora el estado de la línea que va en la otra dirección. Escrituras, lecturas y transferencias bidireccionales no son realmente diferentes. De hecho, por ejemplo, muchos periféricos SPI registrarán una palabra de estado durante la primera palabra, incluso antes de que sepan qué se está solicitando, ya que no cuesta casi nada hacerlo y permite un rápido sondeo de estado.

Respuestas (2)

No, con SPI, todas las comunicaciones son impulsadas 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 afirmar el pin, lo que hace que el microcontrolador acelere el bus SPI.


Para obtener información más detallada, siga leyendo :) 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, en realidad ocurren dos transmisiones 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 dado que 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 hace 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 le envía el maestro.

Eso describe el caso general. Puede haber complejidades adicionales. Por ejemplo, algunos circuitos integrados esclavos generarán algún tipo de byte de estado al mismo tiempo que reciben un comando del maestro. Entonces, en este caso, el maestro no debería descartar el primer byte recibido.

"el maestro no puede simplemente proporcionar un reloj continuo" En realidad, no hace mucho tiempo, vi un dispositivo que hace exactamente eso. Era una pequeña bestia extraña. Lamentablemente no recuerdo el P/N.
@Aaron ¡Es bueno saberlo! La gente se vuelve cada vez más inteligente :-)

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

¿Podría agregar un ejemplo de un sistema multimaestro?