Esta es una secuencia normal para una lectura SPI:
Quiero codificar para un esclavo SPI. ¿Cómo se hace esto normalmente? ¿Cómo puede el esclavo responder tan rápido (en el siguiente bit) con los datos apropiados después de haber recibido la dirección del registro que el maestro quiere leer?
Hay una razón por la cual el hardware se usa generalmente para implementar esclavos SPI. Se puede hacer en un microcontrolador si sabe que la velocidad del reloj se limitará a un valor máximo, una secuencia determinada siempre será seguida por el maestro, etc. En el caso general, es muy difícil debido al posible tiempo muy corto entre la recepción información y luego tener que producir datos basados en esa información.
En su caso, tiene menos de 1 ciclo de reloj para digerir el último bit de la dirección antes de tener que generar datos que probablemente dependan de esa dirección. Si conoce el sistema o tiene algún control sobre él, puede hacer que el maestro use un reloj lento o al menos alargar el reloj entre los flancos ascendente 23 y 24. De lo contrario, una solución que no sea de hardware probablemente no sea viable.
Digamos que la velocidad del reloj es de 10 MHz, que es perfectamente válida para muchos dispositivos SPI. Eso significa que solo tienes 100 ns entre ciclos de reloj. Un dsPIC que se ejecuta a 40 MIPS solo puede hacer 4 ciclos de instrucción durante ese tiempo, lo cual es muy poco probable que esté lo suficientemente cerca como para usar la dirección, hacer la búsqueda y comenzar a devolver los datos.
No todas las cosas son posibles solo porque quieres que lo sean. Este protocolo en particular estaba claramente destinado a algún tipo de chip dedicado para implementar en el lado esclavo. Cualquier cosa que no sea un FPGA no va a funcionar para eso en el caso general.
En general (pueden existir excepciones, pero no conozco ninguna), los esclavos SPI basados en microcontroladores impondrán inevitablemente restricciones de tiempo que los hacen utilizables solo con maestros que son conscientes de esas restricciones y las cumplen. El estándar I2C está diseñado para que un esclavo con una pequeña cantidad de hardware pueda pedirle a un maestro adecuadamente diseñado que haga coincidir su velocidad con un procesador esclavo arbitrariamente lento, pero SPI no tiene tales características. Con los periféricos esclavos SPI de la mayoría de los microcontroladores, el único medio práctico de dar la mano es determinar el momento más desfavorable después de los cambios de CS o de que se envíe un byte antes de que se garantice que el esclavo está listo para el próximo evento, y que el maestro espere incondicionalmente ese tiempo después de cada evento. En consecuencia, aunque tener dos controladores que se comunican usando SPI podría ser teóricamente 10 veces más rápido que usar I2C o UARTs, SPI a menudo terminará siendo más lento debido a la necesidad de que el maestro resuelva los peores casos del esclavo (por ejemplo, si después de un byte Normalmente, el esclavo estará listo para el siguiente byte 2us más tarde, pero se produce alguna otra interrupción a medida que el byte llega puede tomar 50us, la comunicación SPI útil probablemente se limitará a aproximadamente 20Kbytes / segundo, mientras que un UART con búfer cuádruple o I2C Probablemente podría manejar unos 50Kbytes / segundo.
No sería difícil para el hardware SPI incluir características, por lo que el maestro podría adaptarse fácilmente a la sincronización del esclavo (he diseñado el hardware "SPI bridge" que lo hizo), pero no conozco ningún controlador que incluir dicho hardware internamente.
Lea otras preguntas en las etiquetas spi