Pytanie:
Czy slave SPI może rozpocząć transmisję w trybie pełnego dupleksu?
JeJoRic
2019-08-09 20:45:20 UTC
view on stackexchange narkive permalink

O ile wiem, transmisja SPI dla slave'a SPI działa jak poniżej:

  1. Master wybiera slave'a za pomocą kodu PIN
  2. Master i slave wysyłają do siebie dane jednocześnie
  3. Master uruchamia zegar i transmisję danych w tym samym czasie (nie ma zegara przed operacją zapisu)
  4. Master zatrzymuje transmisję w dowolnym momencie (zatrzymując operację zapisu i generowanie zegara), nawet jeśli slave ma więcej danych do wysłania.

Czy jest jakaś konfiguracja SPI slave, która pozwala slave'owi przesyłać dane bez zgody mastera?

Po prostu głośno myślę. Załóżmy, że jest tylko jeden slave, a master zapewnia ciągły zegar itp.

Nawet jeśli założona instrukcja jest prawdziwa, czy master i slave nie tracą synchronizacji bajtów (tj. odbiera strumień bitów), ponieważ nie ma bitów start-stop dla SPI?

Zadaję takie pytanie, ponieważ przeczytałem następującą sekcję z tego dokumentu.

2.2 Przykład SPI

Załączony przykład SPI ilustruje użycie USART w tryb synchroniczny. USART1 jest skonfigurowany jako slave, podczas gdy USART2 jest mistrz. Mają miejsce następujące transakcje:

  • Transmisja danych z mastera do slave.
  • Transmisja danych ze stacji slave do master.
  • Transmisja danych z mastera do slave i od slave do master jednocześnie.

Dokument podaje przykład SPI, ale realizuje przykład przy użyciu urządzeń USART. Rozumiem, że slave USART może rozpocząć transmisję bez pozwolenia mastera.

Nie mogłem znaleźć kodu źródłowego, do którego odwołuje się dokument

Slave z definicji nie może zainicjować transakcji (może jednak być w stanie przerwać mastera, aby rozpocząć transakcję).
Jednokierunkowy transfer danych w tradycyjnym SPI to po prostu ktoś * ignorujący * stan linii idącej w drugą stronę.Zapisywanie, odczytywanie i dwukierunkowe transfery tak naprawdę nie różnią się.W rzeczywistości, na przykład, wiele urządzeń peryferyjnych SPI wyrejestruje słowo stanu podczas pierwszego słowa, zanim nawet dowiedzą się, o co jest żądane, ponieważ nic nie kosztuje i umożliwia szybkie sprawdzenie stanu.
Dwa odpowiedzi:
bitsmack
2019-08-09 20:54:19 UTC
view on stackexchange narkive permalink

Nie, w przypadku SPI cała komunikacja jest sterowana przez urządzenie główne. Masz rację, że mistrz nie może po prostu zapewnić ciągłego zegara; nie byłoby sposobu na wykrycie granic bajtów.

Urządzenie podrzędne często ma oddzielny styk wyjściowy, aby zasygnalizować masterowi, że ma dostępne dane. Ten pin jest podłączony do wejścia mikrokontrolera i często jest używany jako przerwanie.

Następnie urządzenie może potwierdzić pin, powodując, że mikrokontroler podkręca szynę SPI.

Więcej szczegółowych informacji można znaleźć dalej :) To jest nieco zmodyfikowana wersja wyjaśnienia, które znajduje się tutaj:

Urządzenie slave może komunikować się tylko wtedy, gdy ma zegar od urządzenia głównego. To komplikuje odczyt z slave'a, ponieważ musisz spowodować, że master zapewni wystarczającą liczbę cykli zegara, aby slave zareagował.

Kiedy wysyłasz polecenie SPI od mastera, dwie transmisje mają miejsce podczas tych samych ośmiu impulsów zegara. Po pierwsze, twój bajt jest wykręcany z linii MOSI. Ale w tym samym czasie dane są taktowane do mikrokontrolera przez linię MISO.

Ale ponieważ slave nie otrzymuje pełnego polecenia do końca tych transakcji, nie przedstawia żadnych danych na magistrali. Powoduje to otrzymaną wartość 0x00 lub 0xFF.

Następnie musisz zapewnić dodatkowe osiem zegarów, aby umożliwić urządzeniu podrzędnemu zwrócenie rzeczywistej wartości. W wielu implementacjach kodu dokonuje się tego poprzez wysłanie „fikcyjnego bajtu” do urządzenia podrzędnego.

Zauważ, że w pierwszej transmisji master ignoruje wszystko, co przychodzi od slave'a. W drugiej transmisji slave ignoruje wszystko, co jest wysyłane przez mastera.

To opisuje ogólny przypadek. Mogą wystąpić dodatkowe zawiłości. Na przykład, niektóre podrzędne układy scalone faktycznie wysyłają jakiś bajt stanu w tym samym czasie, gdy otrzymują polecenie od urządzenia głównego. Zatem w tym przypadku master nie powinien odrzucać pierwszego odebranego bajtu.

„master nie może po prostu zapewnić ciągłego zegara”. Właściwie nie tak dawno widziałem urządzenie, które robi dokładnie to.To była dziwna mała bestia.Niestety nie pamiętam numeru P / N.
@Aaron Dobrze wiedzieć!Ludzie stają się coraz mądrzejsi :-)
Justme
2019-08-09 21:21:20 UTC
view on stackexchange narkive permalink

Nie, master jest tym, który decyduje o wyborze chipa i steruje zegarem.Slave zawsze słucha tylko zegara i wyboru układu.Przesyłanie danych może nadal odbywać się w trybie pełnego dupleksu.Istnieją implementacje, w których zegar może być ciągły, ale nie ma to większego znaczenia, ponieważ wybór chipa i tak jest używany do synchronizacji granic bajtów.Ale są też systemy multimaster, więc w zasadzie można mieć pewien mechanizm, dzięki któremu urządzenia decydują, kto jest slave i master.Lub po prostu dołącz oddzielny przewód "przerwania" dla slave'a, aby zasygnalizować masterowi, że ma pakiet danych dla mastera.

Czy mógłbyś dodać przykład systemu multimaster?


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...