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.

PIC18F46K22 - po załaczeniu transmisji i2c nie działają porty

piotr-cph 18 Mar 2015 13:25 1419 8
  • #1 18 Mar 2015 13:25
    piotr-cph
    Poziom 9  

    Od dłuższego czasu walczę z wyświetlaczem OLED 1306 i2c oraz obsługą przycisków i led-ów na układzie PIC18F46K22. Zaznaczam, że wyświetlacz działa oraz przyciski ze sterowaniem led, ale osobno.
    Obsługa przycisków i led-ów działa do momentu zapisu do i2c. Po zapisie tym porty odmawiają posłuszeństwa. Bez względu na to czy na sam koniec zamknę komunikację i2c.
    Portami steruje standardowo za pomocą LATx. A konfigurowane są za pomocą ANSELx i TRISx
    Doczytałem, że chip PIC18F46K22 używa czegoś takiego jak "Shared bits" przy I2C. W tabeli 15-3 na stronie 257 pdf-a zaznaczone są bity, które nie są używane przy MSSPx przy i2c.

    Za każdą sugestię z góry dziękuję.

    0 8
  • #2 18 Mar 2015 14:00
    94075
    Użytkownik usunął konto  
  • #3 18 Mar 2015 14:21
    piotr-cph
    Poziom 9  

    Ok zamieszczam fragment kodu, żeby była jasność. Tam niema nic szczególnego.

    Kod: cpp
    Zaloguj się, aby zobaczyć kod

    0
  • #4 18 Mar 2015 17:09
    94075
    Użytkownik usunął konto  
  • #5 18 Mar 2015 19:22
    szymonjg
    Poziom 15  

    Shared bits to są bity dzielone razem z portem SPI, ale to raczej nie jest przyczyną.
    Spróbuj użyć programator jako sprzętowy debuger i ustaw breakpoint w następnej linijce za tą funkcją WriteI2C1( _address & 0xfe ); i wtedy się okaże czy procesor wraca z tej funkcji, czy nie.

    0
  • #6 18 Mar 2015 19:40
    piotr-cph
    Poziom 9  

    To co wkleiłem to był skrócony przykład, który też nie działa.
    Wracać wraca procesor z funkcji bo działa pełna obsługa wyświetlacza OLED 1306. Wyświetlanie grafik , tekstów itp. Nie działają jedynie wszystkie porty tak jak wcześniej pisałem, od momentu wysłania pierwszej danej do i2c.

    0
  • #7 18 Mar 2015 20:18
    szymonjg
    Poziom 15  

    To tak jak napisał kolega Albert, błąd na pewno jest w 13 linijce tamtego kodu.

    A wracając do kodu z przykładu to sprawdź debugerem nawet Step by step co się dzieje z rejestrami sterującymi portami. Czy zapisana wartość na pewno się w niej znajduje po zapisaniu i czy nic jej nie nadpisuje. Co sie dzieje z bitami odpowiedzialnymi za transmisję też możesz tak sprawdzić, czy bit ACK jest odbierany wtedy kiedy trzeba, albo czy jakieś przerwanie się nie pakuje wtedy kiedy trzeba. albo... albo... albo...

    Bo ogólnie jest taka zasada, że jak ktoś się pyta o działanie programu to miło by było aby ten program zamieścił. Dodatkowo jeśli ten program steruje jakimś czymś, to schemat tego czegoś też nie zaszkodzi jak by się pojawił. Jak by tego było mało, to jeszcze można wstawić zdjęcia tego układu. W końcu jak nie działanie tych portów jest problemem, to znaczy, że coś do nich możesz chcieć podłączyć. I choćby z czystej ciekawości fajnie było by zobaczyć co i jak jest tam podłączone. Jeszcze nie koniec. Bo wyobraźmy sobie, że niektórzy wymagają nawet aby te zdjęcia były "ostre i dobrze doświetlone" i zważając na nieuchronny postęp fotografii cyfrowej, też trudno się z nimi nie zgodzić.

    0
  • #8 20 Mar 2015 15:18
    Marico
    Poziom 19  

    No to popatrzmy na źródła WriteI2C1:

    Kod: C
    Zaloguj się, aby zobaczyć kod



    jedyne miejsce, gdzie może wystąpić brak powrotu z funkcji to
    Kod: C
    Zaloguj się, aby zobaczyć kod


    Teraz pomyślmy czy to jest to możliwe.
    Teoretycznie TRISA=0 powinien wymusić konfigurację portu A na digital out (domyślnie po resecie port A jest analog in) a w kodzie brakuje ANSELA=0. Sprawdziłbym to.

    0
  • #9 20 Mar 2015 19:02
    94075
    Użytkownik usunął konto