No es necesario preocuparse de que el módulo SPI use un temporizador. Un problema mayor es que la mayoría de los periféricos esclavos del controlador no están diseñados para hacer que se comporten de la manera en que funcionan la mayoría de los dispositivos esclavos sin procesador. En una conexión SPI bidireccional que utiliza un periférico esclavo típico, el tiempo entre el momento en que el maestro libera / CS y cuando lo reafirma, el tiempo entre cuando afirma / CS y cuándo comienza a registrar los datos, y el tiempo entre cuando el maestro termina marcando un byte y cuando comienza para marcar el siguiente byte, debe ser mayor que el peor de los casos para que el controlador del esclavo responda a esos eventos. No hay forma de que el maestro averigüe cuándo el esclavo está listo para algo; en cambio, el maestro debe esperar ciegamente un tiempo, y siempre debe manejar cada evento dentro de ese marco de tiempo.
Debido a estos requisitos de tiempo, el diseño de dispositivos esclavos SPI confiables es a menudo molesto. Si otras interrupciones tienen prioridad sobre las interrupciones relacionadas con SPI (incluidas la detección de flanco ascendente y de flanco descendente en / CS), puede ser difícil garantizar que los eventos SPI siempre se manejen lo suficientemente rápido para cumplir con la restricción de temporización del peor de los casos. Si las interrupciones SPI tienen prioridad, puede ser difícil evitar que las comunicaciones SPI causen fluctuaciones de tiempo en esas otras interrupciones.
Personalmente, no creo que haya ninguna razón particular por la que los proveedores de chips no puedan diseñar periféricos SPI que permitan al maestro preguntar a en cualquier momento si un esclavo estaba listo para más comunicaciones , sin necesidad de demoras ciegas, pero no conozco ninguna que lo haga.