Te recomendamos que revises esta resolución en un ambiente controlado antes de enviarlo a producción, un saludo.
Solución:
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.
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.
Te mostramos las comentarios y valoraciones de los lectores
Puedes animar nuestra ocupación añadiendo un comentario o dejando una valoración te lo agradecemos.