Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

PIC32 - MCP23S17 dziwne zachowanie

Tomekddd 24 Sty 2015 18:07 1551 7
  • #1 24 Sty 2015 18:07
    Tomekddd
    Poziom 23  

    Witam wszystkich, od paru dni walczę z obsługą ekspandera MCP23S17.
    Dopiero dziś udało mi sie zmusić go żeby w ogóle zareagował na wysyłane dane jednak nie reaguje tak jak powinien. Procesor PIC32MX250F128B działa na 40MHz.

    SPI konfiguruję tak:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Natomiast do ekspandera wysyłam takie polecenia:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Definicje:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    W założeniu ma ustawić oba porty na wyjście ze stanem 1, w efekcie ustawia stan 1 na obu portach ale tylko na niektórych pinach.

    Proszę o pomoc co pokręciłem bo już nie mam pomysłów...
    Pozdrawiam Tomek




    EDIT:
    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
    Kod: c
    Zaloguj się, aby zobaczyć kod


    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.

    0 7
  • #2 25 Sty 2015 23:55
    Marico
    Poziom 19  

    A musisz koniecznie używać plib? Komunikuj się po spi klasycznie, kontrolując samemu CS.

    0
  • #3 26 Sty 2015 11:22
    Tomekddd
    Poziom 23  

    Kontrolowanie samemu pinu CS wymusza dodanie oczekiwania na zakończenie wysyłania danych aby przejść do kolejnego wysyłania. Dodane oczekiwanie zatrzymuje program i kładzie na łopatki komunikację USB. Dlatego chciałem w pełni sprzętowo sterować SPI, ale widzę że chyba nic z tego...

    0
  • #4 26 Sty 2015 13:39
    Marico
    Poziom 19  

    Korzystasz z libów USB Microchipa? Jeśli tak, to przecież one są napisane w modelu cooperative multitasking, ten sam model programowania (z maszyną stanów) powinieneś zastosować w swoim kodzie, wtedy mógłbyś oddawać cpu innym taskom (usb itp.) gdy twój kod potrzebuje oczekiwania na zakończenie transferu po SPI.
    Swoją drogą stos USB Microchipa jest w miarę odporny na niezbyt długie przerwy w wywoływaniu USB_task();. Ile Ci ten transfer zajmuje czasu, że masz problem z USB??

    0
  • #5 26 Sty 2015 17:43
    Tomekddd
    Poziom 23  

    Maszyna stanów to dla mnie czarna magia, dlatego do tego projektu dopisałem swoje pliki z funkcjami które wywołuję klasycznie w main. USB działa sobie tak jak to zrobił Microchip a moje funkcje działają sobie w main.
    Możliwe że przez to program pada jak dodam jakiekolwiek opóźnienie w petli while w pliku main.
    Transfer danych zajmuje niewiele bo potrzebuje wysłać tylko stan wyjść czyli 3 bajty w zależności od tego co będzie się działo, na pewno kilka razy w programie znajdzie się taka funkcja. Odczyt chciałem zrealizować w przerwaniu zewnętrznym które wywoła MCP jak coś zmieni się na jego wejściach.

    Tak jak wspomniałem transmisja działa dobrze ale MCP jej nie rozpoznaje bo procek wystawia stan niski na CS przez całą transmisję a powinien rozdzielać każdy bajt. Jeśli przed załadowaniem kolejnych bajtów do SPI dam oczekiwanie na koniec transferu to procek widzi koniec i prawidłowo rozdziela bajty, a MCP prawidłowo zmienia stan wyjść. Dodanie oczekiwania niestety powoduje zniknięcie procka z USB i już go nie wykrywa.

    0
  • #6 26 Sty 2015 19:02
    Marico
    Poziom 19  

    Absolutnie nie powinno być problemu z wywoływaniem usb_task() np. co 100ms, a na tyle na pewno nie blokuje Ci oczekiwanie na transfer spi. Kilka razy używałem stosu usb mchp i zdarzało mi się go blokować na grube dziesiątki ms ale nigdy nie miałem przypadku "znikania" urządzenia. Co z tego usb wykorzystujesz? Hid? Massstorage?
    Jak komunikujesz plib, który to pin CS (bo tego nie widzę w podanym kodzie)?
    Ten plib chyba nie używa dma, stąd przecież w write() musi być oczekiwanie na opróżnienie sspbuf po uprzednim transferze... ergo i tak write() jest blokujące.

    0
  • #7 26 Sty 2015 19:38
    Tomekddd
    Poziom 23  

    Usb używam jako HID i jedyne zmiany w tym projekcie to wysyłanie i odbiór moich zmiennych zamiast tych oryginalnych. Zmiennych jest około 20.

    Co do pinu CS to używam takiej konfiguracji:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Wydaje mi się że problem jest właśnie oczekiwanie bo funkcji wysyłających wstępne ustawienia MCP jest 5 z której każda ma wysłać 3 bajty. Funkcje wykonują się kolejno więc w efekcie mogę blokować program na zbyt długi czas.
    W programie oczekuję aż bufor nadawczy będzie pusty, dopiero wtedy wrzucam nowe dane, jeśli dane wrzucę wcześniej procek traktuje je jako ciągły strumień i nie rozdziela poszczególnych bajtów.

    Funkcja ustawiająca jest w main przed samą pętlą while, wtedy chyba USB już pracuje i dlatego się rozsypuje.

    0
  • #8 26 Sty 2015 21:42
    Marico
    Poziom 19  

    A czekaj, PLIB_* jest w Harmony, tak? To trochę zmienia postać rzeczy, bo Harmony nie używam i nie zamierzam. To, że wysyła "ciurkiem" zamiast wachlować CS co każdy bajt, wygląda na błąd w libie lub błąd w Twojej konfiguracji SPI (lub niepełna konfiguracja). Być może

    Kod: C
    Zaloguj się, aby zobaczyć kod


    nie ustawia prawidłowo bitów FRMCNT w SPIxCON (powinno być 011, strona 164 datasheet) sprawdź to.
    A chwila, czemu wyłączyłeś FC?:
    Kod: C
    Zaloguj się, aby zobaczyć kod


    Skoro chcesz aby spi sam sterował SSx musisz włączyć framed communication. Aczkolwiek nie jestem pewien czy MCP23S17 supportuje framed communication, a TYLKO w tym trybie używany jest pin SSx, do którego podłączyłeś CS. Zwróć uwagę też na Bit FRMPOL.
    Stąd nie wiem czy osiągalne jest to, co chcesz uzyskać: sterowanie CS przez SSx .

    0