La respuesta corta a "¿será falso?" es, tal vez, pero es muy específica de cada caso.
En general, SPI no debe mostrar problemas con retrasos entre los pasos que ha anotado. El reloj solo se ejecuta cuando se intercambian datos, y el reloj puede correr a DC. Incluso si estaba usando un RTOS y una implementación de SPI de software (bit banged) y algunos relojes para intercambiar un byte, la tarea que estaba haciendo la transferencia de SPI de software fue detenida por el programador y reiniciada más tarde, al esclavo no debería importarle. p>
Dicho esto, hay problemas de implementación con tipos particulares de esclavos SPI. Por ejemplo, he usado SPI ADC que usan la aserción / CS para iniciar la muestra & proceso de retención y el reloj SPI como el reloj de aproximación sucesiva. Si el reloj de SA se ejecutara demasiado lento, la tensión captada por S & H se perdería. En su caso, con un periférico de comunicaciones como CAN, puede perder los mensajes recibidos porque el periférico CAN solo puede almacenar tantos mensajes antes de que tenga que comenzar a descartar los nuevos, y a 1Mbps puede obtener unos cuantos mensajes CAN en 5 ms.
Una de las formas más ordenadas de solucionar estos problemas (especialmente para un periférico de comunicaciones) es usar una combinación de interrupciones y (si su MCU lo admite) DMA.
Es probable que su controlador CAN tenga algún tipo de indicador de "atención" que pueda indicar a la MCU del host para indicarle que el mensaje / s está esperando para ser leído. El indicador de "atención" provoca una interrupción en la MCU, que luego afirma / CS e inicia una transacción DMA para leer el mensaje / s. Cuando la transacción de DMA se completa, el controlador de DMA provoca una interrupción para indicar a la MCU que anule la aseveración / CS y verifique que el SPI reciba el búfer.
Si su MCU no tiene un controlador DMA pero tiene un hardware SPI periférico, entonces puede (o debería poder) usar interrupciones; a medida que se completa cada intercambio de SPI (generalmente 1 byte, pero a veces más), el periférico de SPI provoca una interrupción y la MCU puede elegir iniciar otro intercambio o completar la transacción completa.
Agregaré que SPI (hardware) suele ser lo suficientemente rápido como para que no tenga sentido usar interrupciones entre bytes. Cuando he usado SPI con MCU de gama baja, si el manejo de interrupciones (ingresar y salir de un ISR) fue más de la mitad del tiempo de CPU requerido para intercambiar el byte, entonces no me he molestado en usar un enfoque basado en interrupciones, solo hecho toda la transferencia en tiempo normal de CPU.