Estoy tratando de implementar un dispositivo SPI en Verilog. Tengo muchos problemas para coordinar el maestro y el esclavo, ya que a veces (con mi impl. actual) el dispositivo maestro SPI no envía suficientes pulsos de reloj al esclavo para que pueda terminar su procesamiento.
Por ejemplo, esto puede ocurrir si el esclavo se implementa para que su máquina de estado tenga más estados y deja de recibir pulsos de reloj antes de que termine de completar su ciclo.
Podría modificar mi implementación para hacer que estos dos dispositivos estén coordinados en términos de pulsos de reloj, sin embargo, esto significa que el implementador maestro necesita conocer la impl. detalles del esclavo (y todos los esclavos potenciales). Esto no me parece correcto en absoluto.
¿El protocolo SPI especifica exactamente cuántos pulsos debe proporcionar el maestro al esclavo cuando envía, por ejemplo, un byte? Si no, ¿cómo es que cualquier dispositivo maestro SPI es compatible con cualquier esclavo? ¿Estaría bien enviar una tonelada de pulsos (por ejemplo, 64 pulsos por 1 byte) al esclavo por si acaso?
El maestro SPI no es responsable de asegurarse de que la máquina de estado interna del esclavo reciba "suficientes" pulsos de reloj. Todo lo que el maestro es responsable es un pulso de reloj por bit transferido hacia o desde el esclavo, eso es todo.
Si su esclavo necesita un reloj adicional, depende de usted administrar su implementación de una manera que admita esto; tal vez especifique que se debe transferir una cantidad mínima de bytes (incluso si algunos de ellos son bytes 'ficticios'), o tal vez tiene para proporcionar un reloj externo al esclavo además del reloj SPI.
Un esclavo SPI que se comporte bien debe restablecer su máquina de estado SPI cuando su entrada de selección de esclavo esté desactivada para que cualquier cosa que haga el maestro en una ronda de comunicaciones no necesariamente interrumpa la siguiente ronda debido a que algo está en un estado incompleto.
La respuesta a cualquier pregunta sobre el protocolo SPI es: ¡no hay protocolo SPI! Es la forma más simple posible de transferir datos en serie, esencialmente solo un registro de desplazamiento. Eche un vistazo a un módulo SPI típico en una MCU y verá los problemas asociados con el hecho de que no hay un estándar (por ejemplo, qué borde capturar).
Necesita un método para mantener el receptor SPI recibiendo un reloj local y no confiar en que la fuente SPI proporcione un reloj para hacer algo más que registrar datos en serie. Puede usar el reloj SPI compartido para transferir datos, pero use un reloj local para mantener su máquina de estado.
SPI no es un protocolo en ese sentido al que te refieres.
Es solo una interfaz para transferir bits automáticamente en serie, más comúnmente en múltiplos de ocho para transferir bytes entre dispositivos.
Claro, es un protocolo en el sentido de que todas las partes deben acordar cómo enviar datos, incluidas cosas como la fase del reloj para saber en qué borde se cargan los datos y cuál es la polaridad del reloj inactivo.
Y encima depende de los dispositivos usar un protocolo de bits o bytes, para saber qué significan los bits y bytes.
Básicamente, si su receptor SPI necesita cierta cantidad de bits, entonces el transmisor SPI debe transferir esa cantidad de bits, ni más ni menos. Depende de usted qué contienen esos bits y cómo funciona su receptor SPI si no se transmite la cantidad correcta de bits.
La reacción del esclavo a una transferencia MOSI depende completamente de usted, ya que está diseñando el comportamiento del esclavo.
Si la transferencia es la única vez (cuando el marco está activo), para que el esclavo responda, tiene que ajustar su comportamiento para terminar durante el marco O tiene que implementar y describir ese comportamiento para que un maestro que usa esa capacidad esté registrando Datos MOSI lo suficientemente largos (datos de relleno) para permitir que el esclavo se complete.
Ese es el quid de la cuestión.
Un ejemplo de donde he visto esto es en la parte de Microsemi SmartFusion 2 (MS2090):
No es tan extraño o inusual en realidad. El Microsemi M2S090 tiene una condición similar cuando sondea HW_STATUS. El MOSI envía 0xFF, y mientras registra el comando, los datos MISO contienen la respuesta. En el mismo marco, mientras se registra el comando MOSI no después, 0xFFse registra como esclavo.
Compare el contraste con otros comandos en los que después de que la carga útil se sincroniza con MOSI, el maestro mantiene la trama activa, sincroniza más datos con MOSI para que el esclavo pueda responder según algún requisito. El maestro es lo que mantiene activo el marco y mientras está activo mantiene el reloj en marcha.
Es su diseño y por lo tanto sus requisitos.
Lo que hice para investigar para una comparación fue ejecutar algunas placas Arduino M/S y evaluar el comportamiento. Usé este escenario para validar una expectativa de que el Esclavo reaccionara a lo que era el comando/datos MOSI.
EDITAR: Pensándolo bien, esto no depende completamente de ti. De hecho, existen estándares alrededor de los cuales se basan los proveedores externos. Si está completamente seguro de que su jardín amurallado de uso de FPGA y SPI está aislado, haga lo que quiera. Pero si cualquier dispositivo de terceros está destinado a conectarse y realizar transacciones con su maestro , entonces se debe tener cuidado con la conducta del maestro durante un marco de transferencia SPI. (Estoy pensando aquí en Modo, y hay artículos en wikipedia, etc. sobre esto, así como su hoja de datos de su silicio sería un lugar aún mejor para buscar).
arrendajo
Martel
arrendajo
Halcón sentado
Miguel
ilkkachu