Witam wszystkich, jako że nie widzę na forum działu dla PIC'ów napiszę w tym temacie

Od kilkunastu dni, jak pewnie niektórzy z czatu wiedzą walczę z komunikacją PIC32MX250F128B za pomocą SPI z ekspanderem MCP23S17. Wreszcie udało mi się zmusić go do jakiejkolwiek reakcji na przesyłane dane. Wysyłałem mu rozkaz ustawienia wszystkich portów jako wyjścia w stanie 1.
Ekspander ustawia 1 ale tylko na niektórych pinach co mnie nieźle zaskoczyło i całkiem zbiło z tropu... Mógłby ktoś bardziej doświadczony rzucić okiem i podpowiedzieć gdzie zrobiłem błąd? Procek pracuje na 40MHz.

SPI konfiguruję tak:


A do ekspandera wysyłam dane tak:


Funkcja setup_MCP23S17() jest umieszczona przed pętlą while w pliku main i wykonuje się tylko raz. Ekspander reaguje ale nie rozumiem dlaczego nie tak jak mu kazałem.

Pozdrawiam Dexter

_________________
Zestaw ATB 1.04
Niebieska książka
Zielona książka

https://gitorious.org/pic32mx/tft/sourc ... 3S17defs.h
zobacz to

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Doszukałem się co jest nie tak dzięki analizie oscyloskopem tego co leci po SPI.

Okazało się że procek automatycznie nie dzieli transmisji na poszczególne tylko wysyła wszystko jak leci przy jednym stanie na pinie CS.
Czyli dla


wystawia stan niski na CS i śle wszystko a powinien za każdym razem gdy wchodzi do wysyłania przemiatać pinem CS.

Teraz pytanie czy da się to jakoś zrobić sprzętowo? Bo nie uśmiecha mi się przemiatanie tym pinem programowo gdy transmisja jest sprzętowa.

_________________
Zestaw ATB 1.04
Niebieska książka
Zielona książka

Włącz Frame Sync Pulse

_________________
Dragonus Cracovus: Biomagia

Niestety włączenie tego narobiło jeszcze większego bałaganu, teraz procek przemiata CS co kilka bitów.

W moim kodzie zmienia stan CS na niski tylko na początku transmisji i przywraca stan wysoki po zakończeniu bez względu na to ile danych wysyłam. Powinien zmieniać stan CS za każdym razem gdy chcę wysłać nowe dane.

_________________
Zestaw ATB 1.04
Niebieska książka
Zielona książka

To zmień długość na 32 i wysyłaj jeszcze 4 bajt taki jak 3:

bo wydaje mi się że nie można tam wstawić 24 bity

_________________
Dragonus Cracovus: Biomagia

Zmiana na 32 bajty powoduje tylko wydłużenie transmisji, niestety pin CS jest w stanie niskim przez całą transmisję więc ekspander nie reaguje.

Dziwne jest to że bez względu na to ile danych wysyłam, sygnał CS generowany jest po 1 bajcie a dalej pozostaje niski do końca transmisji.
Próbowałem pozmieniać ustawienia ramki według noty tak żeby mikrokontroler generował sygnał synchronizacji po każdym bajcie i trwający przez cały bajt ale procek w ogóle nie reaguje na takie ustawienia.

Albo ja coś robię nie tak albo działa tu jakaś kosmiczna upierdliwa energia...

_________________
Zestaw ATB 1.04
Niebieska książka
Zielona książka

Pozostaje samemu sterować CS. Nie ma aż tak dużo roboty. Tylko:

oraz:

_________________
Dragonus Cracovus: Biomagia

Też o tym pomyślałem i napisałem dokładnie taką samą funkcję tylko że też nie działa. Pin CS jest przemiatany tak jak sie spodziewałem ale w trakcie transmisji, tzn. procek wysyła dłużej dane niż siedzi w tej funkcji.

Objawia się to przemiataniem pinu CS ale zupełnie niezgodnie z tym co aktualnie wysyła SPI, pomogło dodanie oczekiwania po każdym putcSPI1 aż transmisja się zakończy. To działa świetnie ale wtedy pada USB bo procek oczekuje przy SPI.

Jedyny sposób to pełna sprzętowa obsługa transmisji

_________________
Zestaw ATB 1.04
Niebieska książka
Zielona książka

To zrób tak:

Jest jeszcze taki bit FRMSYPW:

Nie mam po ręką tych funkcji więc napiszę tak:


------------------------ [ Dodano po: 1 pikosekundzie ]


No rzeczywiście tak jest. Zapomniałem o tym. Można by w przerwaniu po zakończeniu wysyłania ustawiać ten pin, ale to będzie działać tylko jak wysyłasz raz na jakiś czas jedną ramkę. Podczas startowej konfiguracji robisz to 3 razy i tam należałoby czekać co można zrobić bo to wykonuje się raz przy starcie.

_________________
Dragonus Cracovus: Biomagia

Ustawienie tego bitu FRMSYPW nie powoduje żadnych zmian, próbowałem ustawić ramkę z aktywnym stanem LOW, generowaną po każdej wysłanej danej do tego trwającą przez całą wysyłaną daną i nic to nie dało... Impuls generuje sie na oko po pierwszym bajcie a potem jest ciągle zero do końca transmsji.

Co do oczekiwania to na początku nie robi to żadnego problemu bo setup jest wykonywany tylko raz gorzej później gdy muszę ustawić jakieś wyjścia albo w przerwaniu odczytać wejścia. Tu już nie może być oczekiwania.

Kombinuję jeszcze nad funkcją która pobierałaby po jednym bacie ze zmiennej bufor_spi następnie blokowała się aż do wysłania tego bajtu po czym po zakończeniu nadawania pobierałaby kolejny bajt i tak w koło macieju do opróżnienia bufora. Nie wiem tylko jak zachowa się program jeśli w czasie wysyłania wystąpi jakieś zdarzenie i powrót do pobrania kolejnego bajtu zajmie prockowi troche wiecej czasu. Wtedy odstęp np. w połowie ramki będzie dłuższy i prawie losowy. Obawiam się że ekspander tego nie przyjmie. No ale próba nie strzelba

_________________
Zestaw ATB 1.04
Niebieska książka
Zielona książka

Napisz tą funkcję w oparciu o przerwania. Jedne od przesunięcia danych z rejestru SPIxBUF do SPIxSR dla pierwszych 2 bajtów i od wysunięcia w świat wszystkich bitów z SPIxSR dla 3 bajtu. Potrzebna będzie jakaś zmienna licząca bajty.
W takim układzie pierwsze przerwania zapewnią wysyłanie 3 bajtów bez zwłoki, a 3 zwolnienie CS.

_________________
Dragonus Cracovus: Biomagia