Estoy escribiendo en una tarjeta microSD desde mi firmware, pero es la tarea de menor prioridad, por lo que puede ser interrumpida por otras tareas mientras está en medio de la lectura / escritura.
Ahora supongamos que me comuniqué con esta tarjeta microSD usando un UART. El problema durante las lecturas sería que el RX FIFO del hardware se desbordaría, por lo que el retraso máximo que puedo hacer sería (tamaño FIFO × bytes / segundo), y durante las escrituras no habría ningún problema, porque el otro extremo solo esperaría hasta que yo envía el siguiente personaje.
¿Cómo funciona esto ahora que estoy usando SPI? ¿Es la situación la misma que para las escrituras no importa y para las lecturas depende del tamaño de SPI FIFO?
La gran mayoría de los dispositivos SPI serán perfectamente felices a cualquier velocidad de datos por debajo del máximo especificado. Uno podría realizar parte de una transacción, tomar un descanso en cualquier momento, regresar unos años más tarde y finalizarla. Siempre que no haya fallas técnicas en el reloj, en la selección o en las líneas eléctricas, la transacción se completará normalmente.
Hay tres advertencias principales a tener en cuenta:
En general, una vez que una transacción ha comenzado en un bus SPI, ninguno de los cables en el bus puede usarse para ningún otro propósito hasta que se complete esa transacción. En general, esto significa que una interrupción no puede usar un bus SPI, excepto cuando es lo único que usará el bus (es posible que la interrupción tenga un uso exclusivo del bus en algunos momentos, y para el principal programa para tener uso exclusivo en otros momentos). Algunos dispositivos incluyen pines especiales para permitirles "ignorar" el bus en medio de una transacción, pero incluso con tales características, no recomendaría intentar que una interrupción suspenda una transacción SPI con un dispositivo, realice una transacción con otro dispositivo, y luego deje que el código subyacente reanude su transacción con el primero. Es mejor que la interrupción use un bus SPI separado.
Algunos dispositivos pueden comportarse de manera extraña si una transacción continúa durante demasiado tiempo. Algunos chips de reloj en tiempo real, por ejemplo, no almacenan doblemente los registros de hora / fecha, sino que bloquean los eventos de "avance de tiempo" que ocurrirían durante una transacción y los aplican después de que se complete la transacción. Si una transacción lleva tanto tiempo que llega un segundo evento de avance de tiempo, el último evento será ignorado, lo que hará que el reloj se deslice por esa cantidad de tiempo. Realmente no veo ninguna excusa para diseñar un chip de esta manera (incluso si uno no quisiera el costo de duplicar los datos, especificando que el software fue responsable de garantizar que su coherencia sería más barata que agregar la lógica de "aplazamiento de actualización", y minimizaría la probabilidad de perturbación del reloj), pero existen tales chips.
Hay algunos dispositivos que usan una señal de reloj y datos, pero que usan una "pausa" para indicar el encuadre. El ejemplo más reciente de esto que he encontrado fue una cadena de luz LED de controlador por bombilla. No me gustan particularmente tales diseños (uno podría indicar el encuadre utilizando tres bordes ascendentes consecutivos en el cable de datos sin ningún reloj intermedio) pero, de nuevo, tales dispositivos existen.
Si bien ciertos tipos de comunicaciones requieren el uso de tiempos particulares, rara vez hay alguna razón para que los dispositivos SPI los requieran. Sin embargo, uno debe ser consciente de la existencia de tales dispositivos.
+1 Nice! Completamente de acuerdo con todas sus opiniones / frustraciones. Lo he visto muchas veces también.
DrFriedParts
11
Al verificar una copia de la especificación (que no puedo citar por razones de derechos de autor / NDA), la tasa de SPI se especifica a partir de 0Hz, lo que implica que la operación estática está bien. Bajo SPI, solo recupera datos mientras el dispositivo se está sincronizando, por lo que si usa un SPI de hardware, solo recibirá algo después de que se hayan enviado los datos (incluso si 0 / no me importa). Entonces, en ese sentido, es diferente a un UART donde puede recibir datos no solicitados en cualquier momento.
Entonces, ¿mi única preocupación debería ser que la tarjeta MicroSD tenga algún tipo de tiempo de espera incorporado, pero no SPI?
Muis
55
De acuerdo con las especificaciones de todo lo que pude ver, tampoco debería haber ninguna forma de tiempo de espera en la tarjeta SD, así que realmente no veo que deba tener ningún problema. Hace años escribí un código personalizado y, mientras que la depuración era un solo paso a través del código, dejando unos 10 segundos o más entre las operaciones de SPI y todo estaba bien.
PeterJ
1
+1, ser capaz de ejecutar SPI hasta 0 Hz es útil para la depuración. Gracias.
Anindo Ghosh
1
Vale la pena señalar que en algunos dispositivos SPI la salida de datos solo puede cambiar en un borde de reloj en particular, pero en otros la salida de datos a veces puede cambiar de forma asincrónica; Esto es especialmente común con un bit "ocupado". En algunos chips, si uno ha desconectado el estado del bit "ocupado" y todavía está en la salida cuando la parte deja de estar ocupada, la salida cambiará asincrónicamente. En algunos otros chips, el estado "ocupado" informado no cambiará hasta que se vuelva a sincronizar. Ambos diseños tienen ventajas y desventajas, por lo que es útil saber que existen ambos tipos de diseños.
Al verificar una copia de la especificación (que no puedo citar por razones de derechos de autor / NDA), la tasa de SPI se especifica a partir de 0Hz, lo que implica que la operación estática está bien. Bajo SPI, solo recupera datos mientras el dispositivo se está sincronizando, por lo que si usa un SPI de hardware, solo recibirá algo después de que se hayan enviado los datos (incluso si 0 / no me importa). Entonces, en ese sentido, es diferente a un UART donde puede recibir datos no solicitados en cualquier momento.
fuente