O SPI é seguro para ser interrompido?

Estou escrevendo para um cartão microSD de dentro do meu firmware, mas é a tarefa de menor prioridade, para que possa ser interrompido por outras tarefas enquanto estiver no meio da leitura / gravação.

Agora, suponha que eu tenha me comunicado com este cartão microSD usando um UART. O problema durante as leituras seria que o FIFO do RX do hardware estouraria , portanto o atraso máximo que eu poderia fazer seria (tamanho do FIFO × bytes / segundo) e durante as gravações não haveria problema, porque a outra extremidade aguardaria até que eu envie o próximo caractere.

Como isso funciona agora, estou usando o SPI? A situação é a mesma que para gravações não importa e para leituras depende do tamanho do SPI FIFO?

A grande maioria dos dispositivos SPI ficará perfeitamente feliz com qualquer taxa de dados abaixo do máximo especificado. Pode-se realizar parte de uma transação, fazer uma pausa a qualquer momento, voltar alguns anos depois e finalizá-la. Desde que não houvesse falhas no relógio, na seleção ou nas linhas de energia, a transação seria concluída normalmente.

Há três advertências principais a serem observadas:

1. Em geral, depois que uma transação é iniciada em um barramento SPI, nenhum dos fios do barramento pode ser usado para qualquer outra finalidade até que a transação seja concluída. Em geral, isso significa que uma interrupção não pode usar um barramento SPI, exceto quando é a única coisa que estará usando o barramento (pode ser possível que a interrupção tenha uso exclusivo do barramento em alguns momentos e para o principal). programa para uso exclusivo em outros momentos). Alguns dispositivos incluem pinos especiais para permitir que eles "ignorem" o barramento no meio de uma transação, mas mesmo com esses recursos, eu não recomendaria que uma interrupção suspendesse uma transação SPI com um dispositivo, realizasse uma transação com outro dispositivo, e deixe o código subjacente retomar sua transação com o primeiro. É melhor que a interrupção use um barramento SPI separado.
2. Alguns dispositivos podem se comportar de maneira estranha se uma transação continuar por muito tempo. Alguns chips de relógio em tempo real, por exemplo, não armazenam em buffer duplo os registros de hora / data, mas bloqueiam quaisquer eventos de "avanço de tempo" que ocorreriam durante uma transação e os aplicam após a conclusão da transação. Se uma transação demorar tanto que um segundo evento de avanço de tempo chegar, o último evento será ignorado, fazendo com que o relógio caia nessa quantidade de tempo. Realmente não vejo desculpa para projetar um chip dessa maneira (mesmo que não se queira o custo de buffer duplo dos dados, especificando que o software é responsável por garantir que sua coerência seja mais barata do que adicionar a lógica de "adiamento de atualização", e minimizaria a probabilidade de perturbação do relógio), mas esses chips existem.
3. Existem alguns dispositivos que usam relógio e sinal de dados, mas que usam uma "pausa" para significar enquadramento. O exemplo mais recente disso que encontrei foi uma cadeia de luzes LED de controlador por lâmpada. Não gosto particularmente desses projetos (pode-se indicar o enquadramento usando três arestas ascendentes consecutivas no fio de dados sem nenhum relógio intermediário), mas, novamente, esses dispositivos existem.

Embora certos tipos de comunicação exijam o uso de intervalos específicos, raramente há motivo para os dispositivos SPI exigirem. No entanto, é preciso estar atento à existência de tais dispositivos.

Verificando uma cópia da especificação (que não posso citar por motivos de direitos autorais / NDA), a taxa SPI é especificada a partir de 0Hz, o que implica que a operação estática está correta. No SPI, você só recupera os dados enquanto o dispositivo está sendo sincronizado, por isso, se estiver usando um SPI de hardware, você receberá apenas algo após o envio dos dados (mesmo que 0 / não importe). Portanto, nesse aspecto, é diferente de um UART, no qual você pode receber dados não solicitados a qualquer momento.