Bawię się SPI na płytce rozwojowej z F103 (konkretnie nucleo) i bardzo mnie zdziwiło zachowanie SPI. Zazwyczaj jest jakaś górna granica szybkości transmisji dla której działa ono poprawnie. U mnie SPI działa tylko gdy bitrate jest powyżej pewnej wartości . Procek lata na 64MHz, i gdy preskaler SPI ustawiony jest na cokolwiek powyżej 16, SPI przestaje działać. Każdy pozostały preskaler działa dobrze. Oznaczałoby to tyle, że SPI radzi sobie z prędkością 32Mb/s (preskaler 2), ale przy 2Mb/s już nie potrafi niczego wysłać .
Na razie do testów używam SPI1 jako slave'a i SPI2 jako mastera - oba w jednym procku. Tak to wygląda:

BSP


przerwania


obsluga SPI


Ma ktoś jakiś pomysł co może być powodem takiego dziwacznego działania? Sprawdzałem wartości dla preskalerów z biblioteki i zgadzają się z tym co jest w nocie...

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

Miałem kiedyś podobne zachowanie procka (z tym, że był to PIC32) - SPI działało poprawnie dopiero powyżej pewnej szybkości.
Co się okazało (po prześledzeniu zachowania procka za pomocą analizatora stanów logicznych)?
Obsługa SPI była na przerwaniach. Przerwanie od odebranego znaku przez SPI (RX). Okazało się, że owszem - kasowałem flagę przerwania, ale nie usuwałem przyczyny przerwania czyli nie odczytywałem znaku z rejestru odbiorczego SPI. I przerwanie ponownie się wywoływało (dwa razy za każdym wysłaniem znaku przez SPI), co oczywiście powodowało błędną komunikację z urządzeniem podłączonym do SPI.
Przy szybszej transmisji znak zdążył się wysłać w czasie jednej tylko obsługi przerwania i drugie przerwanie trafiało na rzeczywiście odebrany znak, co dawało niby poprawną pracę programu
Dopiero wystawienie 1 na jednym portów GPIO podczas wejścia do przerwania i skasowanie jej przy wychodzeniu ujawniło prawdę (po podglądzie na analizatorze) ile razy wywołuje się przerwanie

Nie wiem czy akurat w Twoim przypadku może być podobnie, ale sprawdź czy kasowanie flagi i przyczyny przerwania masz prawidłowe.

Flaga jest kasowana poprawnie, dane są odczytywane za każdym razem. Wewnątrz przerwania mam ustawione i miganie ledem, i wysyłanie znaku po UART - tak więc jestem pewny że wykonuje się tylko raz na jeden znak.

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

A jak wysyłasz bajt z mastera, to od jakiego zdarzenia obsługujesz przerwanie? Od wysyłania czy odebrania? (bo jakoś nie widzę tego w kodzie).
Z tego co pamiętam, to podczas wysyłania przerwanie od TX pojawia się jeszcze przed końcem transmisji, dlatego ja zawsze korzystam z przerwania od RX, (mimo, że wysyłam dane), które przychodzi dopiero po całkowitym skończeniu transmisji.
Może to mieć znaczenie np. przy ustawianiu CS - zbyt szybkie podnoszenie CS, zanim transmisja się jeszcze nie skończyła.

No właśnie bajt wysyłam przez TXE. Domyślnie przerwanie jest wyłączone, a włączane jest tylko na czas transmisji (po wysłaniu bajtu przerwanie wykona się jeszcze raz, i wyłączy samo siebie).

Męczę to SPI już któryś dzień i nie mogę rozgryźć co jest z nim nie tak...

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

No to spróbuj zrobić obsługę od RX'a.
Nie ma też potrzeby ciągłego wyłączania i włączania przerwań - wystarczy zrobić to raz podczas konfiguracji peryferium, tak samo wybiera się tam od jakiego zdarzenia ma się wyzwalać przerwanie - czy od TX czy RX czy błędu. Wtedy w obsłudze przerwania nie trzeba już sprawdzać flag - wiadomo od jakiego zdarzenia przerwanie się wyzwoliło - i nie ma prawa od żadnego innego (bo są zablokowane w bajcie konfiguracyjnym danego peryferium -> tutaj CR2).

Robiłem właśnie testy z przesyłaniem całego bufora zamiast pojedynczego znaku - wygląda na to że miałeś rację z tym CS . Przerwanie TXE wyrzucane jest od razu po załadowaniu bufora nadawczego do rejestru wyrzucanego na szynę - czyli na długo przed zakończeniem transmisji. Ja w tym przerwaniu ustawiałem CSN, czyli slave nie zdążył nawet odebrać całego bajtu, a już został wyłączony. Teraz przesyłają się wszystkie poza ostatnim znakiem (jak CSN jest na stale wyzerowane to oczywiście ostatni także dochodzi).

Zauważyłem to dopiero po twojej uwadze podczas testów z całym buforem danych - dzięki wielkie . Będę musiał pokombinować z tym ustawianiem CSNa.

Jeśli chodzi o przerwania to przyznam że jestem strasznym laikiem jeśli chodzi o STMy. Dopiero zacząłem z nimi zabawę i nie do końca wiem jak inaczej można to rozwiązać. Takie przerwanie TXE na przykład - jeśli włączę je na stałe, to zablokuje mi praktycznie cały procek, bo przez większość czasu rejestr TX jest przecież pusty -> wywoła się przerwanie.

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

No tak - przerwanie od TX'a będzie sie wciąż wywoływać.
Sam już o tym zapomniałem
Ale od RX'a tylko po wysłaniu znaku - przejdź na RX i Twoje problemy się skończą

Chciałem mieć wysyłanie danych w jednym miejscu - w takiej konfiguracji wysyłkę pierwszego bajtu musiałbym inicjować ręcznie, a dopiero następne wewnątrz przerwania odbioru. Ale chyba tylko ta opcja mi pozostaje...

Chociaż popatrzę jeszcze czy nie dałoby się wrzucić do RXNE samego wyłączania CSN.

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

Jak w ostatnim przerwaniu od TX przełączysz rodzaj przerwania na RX, to w jego obsłudze będzie chyba można wyłączyć CS.

Mnie tam jakoś nie przeszkadza że trzeba wysłać pierwszy bajt - i tak jakoś trzeba zainicjować transmisję. A za to później jest mniej wachlowania przy przełączaniu rodzajów zdarzeń wyzwalających przerwanie. I tak trzeba czasami przełączać jeszcze szybkość transmisji i ustawienia PHA/POL jeśli do magistrali jest podłączonych kilka urządzeń o różnych parametrach transmisji.
Jedyną zaletą transmisji karmionej przez TX, jest to, że miedzy bajtami nie ma przerw - jak komuś bardzo zależy na szybkości, to może się o takie karmienie danymi pokusić.

Jeśli dobrze to sobie rozrysowałem, to przerwanie RXNE jest "opóźnione" o 1 bajt w stosunku do TXE. Trochę to utrudnia ustawienie CSN. Ale już chyba to odpuszczę, bo docelowo master będzie i tak realizowany na innym urządzeniu (tutaj jest tylko po to żeby dało się testować transmisję).

Ale chyba tak jak mówisz byłoby najprościej - już przeboleć to jedno nadmiarowe wysyłanie przy rozpoczęciu transmisji, a później mieć spokój . Przynajmniej u mastera, bo slave nie musi ustawiać CSNa...
Dzięki za pomoc, miałem niezłą zagwozdkę z tą szybkością transmisji, a problem okazał się błahy .

------------------------ [ Dodano po: 6 minutach ]

A, jeszcze dla potomnych - okazuje się że jest specjalna flaga BSY, która jest zerowana po zakończeniu transmisji. Jeśli dane są wysyłane w sposób ciągły (przez TXE), to flaga jest zerowana raz, na koniec całej sekwencji bajtów. Dorzuciłem takie coś w przerwaniu RXNE i teraz śmiga jak powinno.

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok