El protocolo bidireccional SPI requiere que cada vez que el maestro intente intercambiar un byte de datos, el esclavo siempre esté listo para recibir un byte de datos y escupir uno. El maestro alimentará al esclavo con un byte en MOSI sin importar si el esclavo está listo para hacer algo útil con él, y lo que haga el esclavo en el pin MISO será interpretado como un byte de datos por el maestro, ya sea que lo haga. El esclavo tenía algo útil que quería decir.
Para lidiar con esto, muchos chips SPI definen su comportamiento de modo que el primer byte que sigue a una selección de chip indicará si el dispositivo está listo para hacer algo con una solicitud de comando que no sea soltarlo. Efectivamente, lo primero que hace el maestro es preguntar "¿estás listo?" Si el esclavo responde "no", el maestro puede preguntar repetidamente tantas veces como quiera hasta que el esclavo diga "sí". Tal diseño es bastante simple de implementar en el lado esclavo, y es bastante fácil de usar desde el lado maestro. Además, generalmente no es difícil subdividir los diferentes tipos de operaciones que un dispositivo puede realizar en pasos que son lo suficientemente pequeños para que, una vez que el esclavo esté listo para comenzar a realizar un paso, pueda intercambiar todos los datos con ese paso tan rápido. como el maestro se preocupa por cronometrarlo, sin más demora.
Una ligera arruga en todo esto es que algunos esclavos pueden necesitar pulsos en el cable del reloj para realizar ciertas operaciones. Como ejemplo común, muchos diseños esperan bloquear los 8 bits del próximo byte que enviarán antes de recibir el primer impulso de reloj. Si un dispositivo que está preparado para enviar un byte que dice "no listo" está listo, no tendría forma de saber si un pulso de reloj podría llegar justo cuando se estaba preparando para cambiar el siguiente byte que transmitió, haciendo que ese byte contienen una mezcla de datos antiguos y nuevos. Una forma de evitar semejante peligro es hacer que un dispositivo decida en el sexto ciclo de reloj de cada byte si se notificará como listo en el siguiente byte. Incluso si el dispositivo está listo justo cuando recibe el sexto ciclo de un byte, para cuando se reciba el ciclo ocho, el dispositivo ya habría tenido la oportunidad de decidir si pensaba que estaba listo antes del sexto ciclo ( en cuyo caso el siguiente byte debe informar "listo") o no hacerlo (en cuyo caso debe informar otro byte "no listo").
