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

[ATmega32][C/AVRstudio] Czyżby spalony port?...

quantor 22 Lis 2009 21:45 2160 9
REKLAMA
  • #1 7296393
    quantor
    Poziom 10  
    Czołem!

    Mam taki problem. W projekcie używam prostej klawiatury sześciu przycisków, którą podłączam do najstarszych linii PORTC. Fragment schematu połączeń gniazda klawiatury do proca:

    [ATmega32][C/AVRstudio] Czyżby spalony port?...

    ...a tu schemat tej prostej klawy:

    [ATmega32][C/AVRstudio] Czyżby spalony port?...


    Wejścia/wyjścia inicjuję taką funkcją:
    void io_init(void)
    {
    	DDRA	= 0x00;
    	PORTA	= 0x00;
    
    	DDRB	= (0 << DD7) | (0 << DD6) | (0 << DD5) | (0 << DD4) | (1 << DD3) | (1 << DD2) | (1 << DD1) | (1 << DD0);
    	PORTB	= 0x00;
    
    	DDRC	= (0 << DD7) | (0 << DD6) | (0 << DD5) | (0 << DD4) | (0 << DD3) | (0 << DD2) | (1 << DD1) | (1 << DD0);
    	PORTC	= (1 << PC7) | (1 << PC6) | (1 << PC5) | (1 << PC4) | (1 << PC3) | (1 << PC2) | (1 << PC1) | (1 << PC0);    // TO nas interesuje...
    
    	DDRD	= (1 << DD7) | (1 << DD6) | (1 << DD5) | (1 << DD4) | (0 << DD3) | (0 << DD2) | (0 << DD1) | (0 << DD0);
    	PORTD	= 1 << 4;
    
    	SFIOR	&= ~(1 << PUD);	// Niby tak jest domyślnie, ale...
    	ASSR	&= ~(1 << AS2);	// j/w
    }



    Stan klawiatury sprawdzałem, kopiując przemaskowaną wartość portu do struktury:
    	Keyboard.Byte	= PORTC & 0xFC;


    Kiedy każdy odczyt zwracał wartość zero, zacząłem sprawdzać wartości nie w strukturze, a bezpośrednio z portu To samo.

    Pomierzyłem wartości na używanych liniach Portu C (7...2), które są ustawione jako podciągnięte wejścia. I kolejno, na liniach (5...2) jest oczekiwany stan wysoki. natomiast na liniach (7) i (6) jest stan niski... :/ Oczywiste jest, że nie używam tych linii jako wejść oscylatora.

    Kiedy przestawię linie (7...2) Portu C na wyjścia (oczywiście po odpięciu klawiatury), zachowują się OK: wpisanie 0 lub 1 zwraca odpowiednią wartość napięcia na liniach.


    W pierwszej kolejności nasuwa się wniosek: utrzaskany port C. Ale nie jestem ekspertem jeśli chodzi o AVRy, więc może coś przeoczyłem? Proszę osoby bardziej obeznane o rzucenie okiem na wyżej przedstawione materiały i wszelkie sugestie. Przelutowanie scalaka SMD z płytki wykonanej ręcznie przy użyciu ręcznej lutownicy nie uśmiecha mi się za bardzo...

    Pozdrawiam
  • REKLAMA
  • #2 7296479
    dawid512
    Poziom 32  
    Nie majstrujesz czasem przy Timerze 2? Jeżeli ustawi się odpowiedni bit( patrz datasheet) to te końcówki przestają być I/O.
  • REKLAMA
  • #3 7296523
    quantor
    Poziom 10  
    dawid512 napisał:
    Nie majstrujesz czasem przy Timerze 2? Jeżeli ustawi się odpowiedni bit( patrz datasheet) to te końcówki przestają być I/O.


    Nie. Używam tylko T1 jako autoretrygowalny licznik wywołujący przerwanie co 10ms. Natomiast licznika T2 nie ruszam.

    Acha! Zapomniałem dodać, że jeśli kość totalnie wyczyszczę (ERASE) to na liniach 7 i 6 portu C utrzymuje się stan niski, a na pozostałych - wysoki. To raczej nie jest normalne zachowanie, prawda?...
  • #4 7296651
    michalko12
    Specjalista - Mikrokontrolery
    To może zacznij sprawdzać to za pomocą innego rejestru i wyłącz JTAG za pomocą FUSEbitów.

    Keyboard.Byte   = PINC & 0xFC;
  • REKLAMA
  • Pomocny post
    #5 7296656
    AVRowiec
    Poziom 18  
    Wyłącz JTAG.
    W fuse bitach.
  • REKLAMA
  • #6 7296711
    quantor
    Poziom 10  
    JTAG jest wyłączony. Podsyłam zrzut ze stanami FUSEów.

    [ATmega32][C/AVRstudio] Czyżby spalony port?...

    Poza tym, gdyby był włączony, to cały port byłby niepodciągnięty.
    A co do sprawdzania innym rejestrem, też to robiłem. Nawet sprawdzałem stan na PINC, zachowuje się tak samo (zwraca zera).

    Czy w związku z powyższym można uznać, że kostka jest trzaśnięta?... Nie chcę ryzykować wymiany (o powodzie czego pisałem wyżej), zwłaszcza, jak ma się okazać, że kolejna kostka zachowa się tak samo... ;-|
  • Pomocny post
    #7 7296729
    dawid512
    Poziom 32  
    JTAG masz włączony ale niestety on odpowiada z inne końcówki(aczkolwiek go wyłącz) więc problemu szukałbym gdzie indziej.
  • #8 7296922
    quantor
    Poziom 10  
    dawid512 napisał:
    JTAG masz włączony

    Hmmm... W PonyProg FUSE'a się ustawiało gasząc ptaszka. Tu jest normalnie, 1 to 1, o to 0. O ile dobrze rozumiem, żeby włączyć JTAG, trzeba ten bit ustawić:
    "When the JTAGEN fuse is unprogrammed, these four TAP pins are normal port pins and the TAP controller is in reset. When programmed and the JTD bit in MCUCSR is cleared, the TAP input signals are internally pulled high and the JTAG is enabled for Boundary-scan and programming."

    Cytat:
    ale niestety on odpowiada z inne końcówki(aczkolwiek go wyłącz) więc problemu szukałbym gdzie indziej.


    Racja. Tylko gdzie?... :-/

    BTW: Reszta FUSEów jest dobrze ustawiona?...

    Dodano po 49 [minuty]:

    Hmmm... Chyba masz rację, jeśli bit jest USTAWIONY, to JTAG jest WYŁĄCZONY.
    Sprawdzam stan linii wystawiając zawartości portów PORTC i PINC na terminal. Oto co zwraca:

    [ATmega32][C/AVRstudio] Czyżby spalony port?...


    Jak widać, wartość (PINC) zwraca autentyczny stan na liniach.


    I zaraz padnie pytanie, które wielu może wydać się głupie. ;) Zrozumiałem z PFDa, że PORTC to rejestr wejścia/wyjścia, czyli wprowadzam tam dane jeśli chcę wystawić je na port i wyprowadzam, jeśli chcę je odczytać z portu (oczywiści, przy odpowiednim ustawieniu rejestru kierunku). Ale, jeśli port pełni rolę wejścia, to wpisując do PORTC ustawiam przecież podciągnięcia. Skąd zatem muszę odczytać dane z portu? Z PORTC, czy z PINC?... Bo widzę, że jak port ustawię jako wejście i wpiszę do PORTC jakąś wartość (np. 0xAA, co podciągnie mi co drugą nóżkę, ale dwa ostatnie bity są celowo zamaskowane), to te same wartości mi się potem z rejestru PORTC odczytują... Wniosek wydaje się oczywisty, ale chcę mieć pewność...
  • #9 7299918
    janbernat
    Poziom 38  
    Z rejestru PINC odczytujesz stan wejść.
    Od zawsze.
    Jeśli port pracuje jako wyjście PINx kopiuje zwykle stan PORTx z opóźnieniem.
  • #10 7308262
    quantor
    Poziom 10  
    janbernat napisał:
    Z rejestru PINC odczytujesz stan wejść. Od zawsze.


    Heh, teraz już też to wiem. ;-) Jak pisałem, uczę się dopiero AVRów i nie wiem co za diabeł podkusił mnie, by się wspomóc jakąś polską publikacją, która błędów ma od czorta. :-/ Obecnie korzystam już tylko z DataSheetów, które są pewniejszymi źródłami informacji (co nie znaczy, że bezbłędnymi). niemniej idzie (odpukać) coraz lepiej. ;-)

    Cytat:
    Jeśli port pracuje jako wyjście PINx kopiuje zwykle stan PORTx z opóźnieniem.


    Zgadza się. :-) Zdaje się o cykl maszynowy, chyba, że przyczyna jest na zewnątrz (np. zwarcie). Wówczas stan w PINx zależy od tego, kiedy ów spinol nastąpił.

    Dzięuję za sugestie, temat zamykam.
REKLAMA