logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[Xmeag256-A3BU][SPI] - SPI dziwne zachowanie - pytanie

kazzik87 15 Lip 2013 12:59 1911 9
  • #1 12524234
    kazzik87
    Poziom 12  
    Witam,
    jestem w posiadaniu płytki testowej Xplaned Xmega256-A3BU.

    Staram się uzyskać połączenie przez SPI z modułem radiowym. Kod zaimplementowałem z Atmegi644PA oczywiście zmieniając odpowiednio porty i piny.

    W czym problem?
    Otóż podpoiłem LEDa aby mi sygnalizował prawidłowe odebranie danych. Kiedy włączę układ (dam napięcie) i wsunę kabel na pin MISO to dioda zaczyna świecić? Dodam że przewód z drugiej strony nie jest podpięty :-/

    W czym rzecz?

    Kody do analizy:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #2 12524781
    piotrva
    VIP Zasłużony dla elektroda
    Z tego co widzę to MISO nie jest podciągane, więc podpięcie kabla powoduje, ze zachowa się on jak antena i SPI będzie odbierało losowe dane, jeśli z drugiej strony kabla nie podepniesz pod cały interfejs układu radiowego.
  • #3 12525795
    Konto nie istnieje
    Poziom 1  
  • #4 12526087
    piotrva
    VIP Zasłużony dla elektroda
    No i jeszcze zamiast 0xcośtam warto skorzystać z definicji zapisanych w pliku io(model procesora lub ich serii).h - wtedy od razu widać co dana linijka robi.
  • #5 12526172
    tmf
    VIP Zasłużony dla elektroda
    Marek_Skalski napisał:
    W Xmega nie wystarczy ustawić kierunku i stanu portu, konieczne jest jeszcze skonfigurowanie pinu. Do tego służą rejestry PORTx.PINnCTRL. Możesz zapisywać każdy indywidualnie, albo użyć rejestru MPCMASK w grupie PORTCFG i wskazać które piny konfigurujesz jednocześnie.


    Wystarczy rejestr DIR i OUT. Domyślnie piny są skonfigurowane w przypadku wyjścia jako totem-pole, a w przypadku wejśca - jako zwykłe wejścia bez rezystorów pull up/down. Stąd też jeśli taka konfiguracja wystarczy (jest ona kompatybilna ze znaną z innych AVRów) to PINnCTRL nie trzeba ruszać. Rejestr kontrolny pinu potrzebny jest dopiero, kiedy wybieramy inną niż domyślna konfigurację.
  • #6 12527096
    kazzik87
    Poziom 12  
    Dziękuje za propozycje pomocy.

    Nadal nic się nie zmieniło. Dalej MISO reaguje na przewód!
  • #7 12527148
    kchpl
    Poziom 15  
    Witam
    Jeśli chodzi o program to:
    init_CPU() jest zbędne - xmega i tak startuje z 2MHz RC aktywnym,
    w init_SPI() usuń SPIC.STATUS i SPIC.DATA,
    nie wiem czy masz to gdzieś zdefiniowane ale takich etykiet pinów chyba nie ma
    "PORTC.DIR |= (1 << PORTC_MOSI) | (1 << PORTC_SCK) | (1 << PORTC_SS);"
    ewentualnie spróbuj tak:
    PORTC_DIRSET |= PIN7_bm|PIN5_bm|PIN4_bm;

    PORTR.OUTTGL = (1 << PORTR.PIN0CTRL); to też jest nie tak, powinno być (1<<PIN0_bm)
    dodatkowo statusSPI spróbuj zdefiniować ze znaną wartością np 0
  • #8 12527190
    piotrva
    VIP Zasłużony dla elektroda
    piotrva napisał:
    Z tego co widzę to MISO nie jest podciągane, więc podpięcie kabla powoduje, ze zachowa się on jak antena i SPI będzie odbierało losowe dane, jeśli z drugiej strony kabla nie podepniesz pod cały interfejs układu radiowego.
  • #9 12527204
    Konto nie istnieje
    Poziom 1  
  • #10 12527521
    kazzik87
    Poziom 12  
    Ok, problem rozwiązany.

    1. Błąd w DTR modułu RF. Trzeba było zamienić miejscami SS i SCK.
    2. Brak informacji w DTR o konieczności podpięcia masy! - moduł RF pracował na zasilaniu z baterii.

    Program dobrze napisany :-)

    Temat uważam za zamknięty
    Dziękuje za wszystkie cenne uwagi.
REKLAMA