Czy przerwanie SPI jest bezpieczne?

Piszę na karcie microSD z poziomu mojego oprogramowania układowego, ale jest to zadanie o najniższym priorytecie, więc może zostać przerwane przez inne zadania, gdy jest w trakcie odczytu / zapisu.

Załóżmy teraz, że komunikowałem się z tą kartą microSD za pomocą UART. Problem podczas odczytu polegałby na tym, że sprzętowy RX FIFO przepełniałby się, więc maksymalne opóźnienie, jakie mogę podjąć, to (rozmiar FIFO × bajty / sekundę), a podczas zapisów nie byłoby problemu, ponieważ drugi koniec po prostu czekałby, aż I wyślij następny znak.

Jak to działa teraz używam SPI? Czy sytuacja jest taka sama, że ​​dla zapisów nie ma to znaczenia, a dla odczytów zależy od rozmiaru SPI FIFO?

Zdecydowana większość urządzeń SPI będzie całkowicie zadowolona przy każdej szybkości transmisji danych poniżej określonego maksimum. Można wykonać część transakcji, zrobić sobie przerwę w dowolnym momencie, wrócić kilka lat później i zakończyć. Pod warunkiem, że nie wystąpiły usterki zegara, linii wyboru lub linii energetycznych, transakcja zostałaby zakończona normalnie.

Należy pamiętać o trzech głównych zastrzeżeniach:

1. Zasadniczo po rozpoczęciu transakcji na magistrali SPI żaden z przewodów na magistrali nie może być używany do jakichkolwiek innych celów, dopóki transakcja nie zostanie zakończona. Zasadniczo oznacza to, że przerwanie nie może korzystać z magistrali SPI, chyba że jest to jedyna rzecz, która będzie korzystała z magistrali (może być możliwe, że przerwanie będzie miało czasami wyłączne korzystanie z magistrali, a główne program do wyłącznego użytku w innym czasie). Niektóre urządzenia zawierają specjalne piny, które pozwalają im „zignorować” magistralę w trakcie transakcji, ale nawet przy takich funkcjach nie zalecałbym próby przerwania transakcji SPI z jednym urządzeniem, wykonania transakcji z innym urządzeniem, a następnie pozwól kodowi bazowemu wznowić transakcję z pierwszym. Lepiej, aby przerwanie korzystało z osobnej magistrali SPI.
2. Niektóre urządzenia mogą zachowywać się dziwnie, jeśli transakcja trwa zbyt długo. Na przykład niektóre układy zegara czasu rzeczywistego nie buforują podwójnie rejestrów czasu / daty, lecz blokują wszelkie zdarzenia „wyprzedzania czasu”, które miałyby miejsce podczas transakcji, i stosują je po zakończeniu transakcji. Jeśli transakcja trwa tak długo, że nadejdzie drugie zdarzenie z wyprzedzeniem czasu, to drugie zdarzenie zostanie zignorowane, powodując przesunięcie zegara o tę ilość czasu. Naprawdę nie widzę usprawiedliwienia dla zaprojektowania układu w taki sposób (nawet jeśli ktoś nie chciałby ponosić podwójnego buforowania danych, określenie, że oprogramowanie jest odpowiedzialne za zapewnienie jego spójności byłoby tańsze niż dodanie logiki „odraczania aktualizacji”, i zminimalizowałoby prawdopodobieństwo zakłócenia zegara), ale takie układy istnieją.
3. Istnieje kilka urządzeń, które wykorzystują zegar i sygnał danych, ale używają „pauzy” w celu oznaczenia ramkowania. Najnowszym przykładem tego, z jakim się spotkałem, był ciąg diod LED kontrolera na żarówkę. Nie podoba mi się szczególnie takie projekty (równie dobrze można wskazać kadrowanie przy użyciu trzech kolejnych rosnących krawędzi na przewodzie danych bez żadnego zegara pośredniego), ale znowu takie urządzenia istnieją.

Podczas gdy niektóre rodzaje komunikacji wymagają użycia określonych czasów, rzadko istnieje żaden powód, dla którego wymagają tego urządzenia SPI. Niemniej jednak należy pamiętać o istnieniu takich urządzeń.

Sprawdzanie kopii specyfikacji (której nie mogę zacytować ze względu na prawa autorskie / NDA) określa szybkość SPI od 0 Hz, co oznacza, że ​​operacja statyczna jest w porządku. Pod SPI odzyskujesz dane tylko podczas taktowania urządzenia, więc jeśli używasz sprzętowego SPI, otrzymasz coś dopiero po wysłaniu danych (nawet jeśli 0 / nie przejmuj się). W związku z tym różni się od UART, w którym możesz w dowolnej chwili otrzymać niechciane dane.