Безопасно ли прерывать SPI?

Я пишу на карту microSD из моей прошивки, но это задача с самым низким приоритетом, поэтому она может быть прервана другими задачами, когда она находится в процессе чтения / записи.

Теперь предположим, что я общался с этой картой microSD с помощью UART. Проблема во время чтения будет в том, что аппаратный RIF FIFO будет переполнен, поэтому максимальная задержка, которую я смогу приложить, будет (размер FIFO × байтов / секунду), и во время записи не будет проблем, потому что другой конец просто подождет, пока я отправить следующий символ.

Как это работает сейчас я использую SPI? Ситуация та же, что для записей это не имеет значения, а для операций чтения это зависит от размера SPI FIFO?

Подавляющее большинство устройств SPI будут совершенно довольны при любой скорости передачи данных ниже указанного максимума. Можно выполнить часть транзакции, сделать перерыв в любой момент, вернуться через несколько лет и закончить его. При условии, что на часах, выделении или линиях питания не было глюков, транзакция была бы завершена в обычном режиме.

Есть три основных предостережения, о которых следует знать:

1. В общем, как только транзакция началась на шине SPI, ни один из проводов на шине не может использоваться для каких-либо других целей, пока эта транзакция не будет завершена. В общем, это означает, что прерывание не может использовать шину SPI, за исключением случаев, когда это единственное, что будет использовать шину (в некоторых случаях прерывание может иметь исключительное использование шины, а для основного программа для эксклюзивного использования в другое время). Некоторые устройства имеют специальные контакты, позволяющие им «игнорировать» шину в середине транзакции, но даже с такими функциями я бы не рекомендовал пытаться прерывать прерывание SPI-транзакции с одним устройством, выполнять транзакцию с другим устройством, и затем позволить базовому коду возобновить свою транзакцию с первым. Для прерывания лучше использовать отдельную шину SPI.
2. Некоторые устройства могут вести себя странно, если транзакция продолжается слишком долго. Например, некоторые микросхемы часов реального времени не выполняют двойной буферизации регистров времени / даты, а вместо этого фиксируют любые события «опережения времени», которые могут произойти во время транзакции, и применяют их после завершения транзакции. Если транзакция занимает столько времени, что наступает второе событие опережения времени, последнее событие будет игнорироваться, что приведет к задержке часов на это количество времени. Я действительно не вижу оправдания для разработки чипа таким способом (даже если кто-то не хочет затрат на двойную буферизацию данных, указав, что программное обеспечение отвечает за обеспечение его согласованности, будет дешевле, чем добавление логики «отложить обновление», и минимизирует вероятность нарушения синхронизации), но такие чипы существуют.
3. Есть несколько устройств, которые используют часы и сигнал данных, но которые используют «паузу» для обозначения кадрирования. Самым последним примером этого, с которым я столкнулся, была светодиодная цепочка контроллера на лампочку. Мне не особенно нравятся такие конструкции (можно точно также указать кадрирование, используя три последовательных нарастающих фронта на проводе данных без каких-либо промежуточных часов), но опять же, такие устройства существуют.

В то время как определенные типы связи требуют использования определенных таймингов, для устройств SPI редко есть какая-либо причина требовать их. Тем не менее, нужно помнить о существовании таких устройств.

При проверке копии спецификации (которую я не могу процитировать по причинам авторского права / NDA) частота SPI указывается, начиная с 0 Гц, что подразумевает статическую работу в порядке. В SPI вы возвращаете данные только во время синхронизации устройства, поэтому при использовании аппаратного SPI вы получите что-то только после отправки данных (даже если 0 / все равно). Таким образом, в этом отношении он отличается от UART, где вы можете получить незапрошенные данные в любое время.