SPI peut-il être interrompu en toute sécurité?

J'écris sur une carte microSD à partir de mon micrologiciel, mais c'est la tâche la moins prioritaire, elle peut donc être interrompue par d'autres tâches pendant qu'elle est en cours de lecture / écriture.

Supposons maintenant que je communique avec cette carte microSD en utilisant un UART. Le problème pendant les lectures serait que le matériel RX FIFO déborderait, donc le délai maximum que je peux faire serait (taille FIFO × octets / seconde), et pendant les écritures, il n'y aurait pas de problème, car l'autre extrémité attendrait simplement que je envoyer le caractère suivant.

Comment cela fonctionne-t-il maintenant que j'utilise SPI? La situation est-elle la même que pour les écritures, cela n'a pas d'importance et pour les lectures, cela dépend de la taille SPI FIFO?

La grande majorité des appareils SPI seront parfaitement satisfaits à tout débit de données inférieur au maximum spécifié. On pourrait effectuer une partie d'une transaction, faire une pause à tout moment, revenir quelques années plus tard et la terminer. À condition qu'il n'y ait pas de problèmes sur l'horloge, la sélection ou les lignes électriques, la transaction se terminerait normalement.

Il y a trois mises en garde principales à prendre en compte:

1. En général, une fois qu'une transaction a commencé sur un bus SPI, aucun des fils du bus ne peut être utilisé à d'autres fins tant que cette transaction n'est pas terminée. En général, cela signifie qu'une interruption peut ne pas utiliser un bus SPI sauf lorsque c'est la seule chose qui utilisera le bus (il peut être possible pour l'interruption d'avoir une utilisation exclusive du bus à certains moments, et pour le principal programme à un usage exclusif à d'autres moments). Certains appareils incluent des broches spéciales pour leur permettre "d'ignorer" le bus au milieu d'une transaction, mais même avec de telles fonctionnalités, je ne recommanderais pas d'essayer de faire interrompre une transaction SPI avec un appareil, d'effectuer une transaction avec un autre appareil, puis laissez le code sous-jacent reprendre sa transaction avec le premier. Mieux vaut que l'interruption utilise un bus SPI séparé.
2. Certains appareils peuvent se comporter bizarrement si une transaction dure trop longtemps. Certaines puces d'horloge en temps réel, par exemple, ne mettent pas en double les registres d'heure / date mais verrouillent à la place tous les événements "d'avance temporelle" qui se produiraient pendant une transaction et les appliquent une fois la transaction terminée. Si une transaction prend tellement de temps qu'un deuxième événement d'avance temporelle arrive, ce dernier événement est ignoré, ce qui fait que l'horloge glisse de ce laps de temps. Je ne vois vraiment aucune excuse pour concevoir une puce de cette manière (même si l'on ne voulait pas le coût de la double mise en mémoire tampon des données, spécifier que le logiciel était responsable de garantir sa cohérence serait moins cher que d'ajouter la logique de "mise à jour différée", et minimiserait la probabilité de perturbation d'horloge), mais de telles puces existent.
3. Il existe quelques appareils qui utilisent une horloge et un signal de données, mais qui utilisent une "pause" pour signifier le cadrage. L'exemple le plus récent de cela que j'ai rencontré était une guirlande lumineuse LED contrôleur par ampoule. Je n'aime pas particulièrement ces conceptions (on pourrait tout aussi bien indiquer le cadrage en utilisant trois fronts montants consécutifs sur le fil de données sans horloge intermédiaire) mais encore une fois, de tels dispositifs existent.

Bien que certains types de communications nécessitent l'utilisation d'horaires particuliers, il est rare que les appareils SPI en aient besoin. Néanmoins, il faut être conscient de l'existence de tels dispositifs.

En vérifiant une copie de la spécification (que je ne peux pas citer pour des raisons de copyright / NDA), le taux SPI est spécifié à partir de 0 Hz, ce qui implique qu'un fonctionnement statique est correct. Sous SPI, vous ne récupérez les données que lorsque l'appareil est synchronisé, donc si vous utilisez un SPI matériel, vous ne recevrez quelque chose qu'après l'envoi des données (même si 0 / ne vous en souciez pas). À cet égard, c'est différent d'un UART où vous pouvez recevoir à tout moment des données non sollicitées.