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

[AVR][Bascom/ASSEMBLER] - zagwostka

mirekk36 31 Sie 2008 20:36 1817 9
  • #1 5494225
    mirekk36
    Poziom 42  
    Witam,

    Piszę sobie wstawkę w asm, i powiedzcie mi co źle robię w asm albo dlaczego Bascom traktuje to inaczej niż zwykle. Otóż mam taki oto popularny zapis typu:


         * In R25 , DDRC
         ori   R25, &HF0
         * Out DDRC , R25


    (te gwiazdki to wiadomo - są, bo to jest kawałek kodu w bibliotece bascomowej)

    ... tak więc tym kodem powyżej chciałbym jak widać ustawić kierunek starszych 4 bitów portu C jako wyjście - nie zmieniając przy okazji stanu kierunku pozostałych bitów portu. Taki sam kod asm generuje w tym przypadku np GCC.

    Ale z niewiadomych dla mnie przyczyn gdy używam pewnego jednego rodziaju wyświetlacza a jest to kod do obsługi LCD z użyciem RW mojego autorstwa to - z tym tylko 1 wyświetlaczem to nie działa - pokazują się krzaczory tak jakby nie zmienił się kierunek. Oczywiście jeśli wpiszę:


            * Sbi DDRC, 7
            * Sbi DDRC , 6
            * Sbi DDRC , 5
            * Sbi DDRC , 4


    to okazuje się, że wtedy i ten wyświetlacz działa tak jak inne - o co tu może chodzić - czy gdzieś - widzicie - co mogę robić źle ???
  • #3 5495039
    mirekk36
    Poziom 42  
    adamwesola -> taki zapis &H - jest dopuszczalny w Bascomie i oznacza liczbę hex, ale oczywiście próbowałem już i z innymi rodzajami zapisu jak $F0 lub 0xF0 i zawsze z tym wyświetlaczem mam taki sam efekt - najdziwniejsze, że z innymi to działa - no chyba, że tu chodzi o jakiś czas wykonywania tych 2 różnych operacji, które opisałem na początku

    Dodano po 14 [minuty]:

    hmmm na porcie C ATmegi32 używam jeszcze magistrali I2C na pinach Portc.0 i Portc.1 .... działa to w trybie Slave. No ale przecież do kurki wodnej - najpierw wczytuję zawartość DDRC , ustawiam kilka wyższych bitów i zapisuję znowu do DDRC . Przecież to nie powinno mieć wpływu na I2C. Tym bardziej, że nie tykam przy poleceniu OUT ani PINC ani PORTC - tylko DDRC - więc o co tutaj chodzi.

    a nawiasem mówiąc - nawet jeśli zastosuję taki zapis:

         * In R25 , DDRC 
         ori   R25, &HF0 
         * Out DDRC , R25
    
            * Sbi DDRC, 7 
            * Sbi DDRC , 6 
            * Sbi DDRC , 5 
            * Sbi DDRC , 4


    to też wyświetlacz wariuje, dopiero jak wywalę linijkę z rozkazem OUT DDRC, R25 a później są te SBI to wtedy wyświetlacz rusza - hmm jakieś bzdury - coś chyba za długo już przy tym siedzę. Wprawdzie działa mi to z tym SBI .... ale dręczy mnie ten problem jak jasny gwint
  • #6 5498548
    mirekk36
    Poziom 42  
    Gwiazdką oznaczamy polecenia asm, które mają być kompilowane do kodu wynikowego dopiero podczas kompilacji całego programu a nie przy kompilacji wstępnej biblioteki, która wtedy jest kompilowana do pliku z rozszerzeniem *.lbx.

    ... a gwiazgki są przydatne wtedy gdy np w kodzie biblioteki odwołujemy się do stałych lub zmiennych zdefiniowanych w programie głownym. Ja w tym przypadku tak właśnie robię, tylko dla uproszczenia napisałem

    * In R25 , DDRC 


    zamiast tak jak jest to u mnie w programie

    * In R25 , _lcdddr


    gdzie _lcdddr to stała w programie głównym :

    Const _lcdddr = DDRC


    - może to troszkę pogmatwane ale jak już się załapie to staje się bardzo wygodne - no poza tą moją zagwostką :(
  • #7 5499452
    BoskiDialer
    Poziom 34  
    Spróbuj z innym rejestrem niż r25 - może występuje konflikt w użyciu rejestrów pomiędzy asmem i bascomem (nie znam kompilatora bascoma, więc tylko spekuluję). Inna możliwość, to odkładanie r25 na stos. Jeśli nadal nie będzie działać, to wrzuć skompilowany kod na deasembler i na forum, wtedy powinno się coś wyjaśnić (w kodzie wrzuć kilka nop'ów żeby wyróżnić miejsce)
  • #8 5499750
    mirekk36
    Poziom 42  
    BoskiDialer -> od razu rzuciłem się żeby to sprawdzić bo na to nie wpadłem, ale też kicha.

    Tzn problem jest o tyle dziwny, że gdy podłączam jakiś zwykły wyświetlacz LCD to to działa, ale gdy podłączam wyświetlacz PLED to nie działa. Wtedy muszę użyć tych 4 rozkazów SBI

    dokładniej mówiąc to chodzi o sam moment ustawienia pinów D4-D7 wyświetlacza jako wyjścia tuż po sprawdzeniu flagi zajętości BF (BusyFlag)

    naprawdę straszny dziwoląg - tym bardziej, że dla zwykłych LCD działa i tak i tak a dla PLED tylko z SBI
  • #9 5499918
    BoskiDialer
    Poziom 34  
    Pisząc "po sprawdzeniu flagi zajętości" rozumiem masz na myśli "zaraz po wysterowaniu pinu E w stan wysoki".. ? Może wydawać się to oczywistością, ale dla niektórych nie jest i wtedy pojawiają się problemy...

    Sprawdź też diodą(+R) lub czytając DDR, czy piny rzeczywiście nie ustawiają się jako wyjście, czy reakcja wyświetlacza jest taka, jak by nie reagował. Kod wydaje się jak najbardziej poprawny, za czym przemawia to, że z wyświetlaczami lcd działają obie wersje, popróbuj też z małymi opóźnieniami (od 5 do 10us) pomiędzy zboczami E, oraz około 1us pomiędzy zboczem opadającym E a odczytem bajtu. Może korzystanie z SBI jest na tyle długie (aż 8 cykli), że wyświetlacz nadąża za uC.
  • #10 5499968
    mirekk36
    Poziom 42  
    stan zajętości BF jest sprawdzany oczywiście w pętli, i występują tam jak powinny dwa cykle wysterowania E do 1 a potem do 0. Wstawione tam są dobre opóźnienia (po 2-3 nop'y). Oczywiście dopiero po wyjściu z pętli, gdy BF już = 0 następuje ta zmiana kierunku dla pinów sterujących D7-D4 wyświetlacza.

    ale też już myślałem o tym nie nadążaniu wyświetlacza i wstawiałem mu NOP'y przed tą sekwencją IN-OUT i po niej też, żeby wystąpiło tak sztucznie więcej cykli - i też niestety nic to nie daje.

    ale masz rację, spróbuję to jeszcze jakoś programowo sprawdzić - po pierwsze co wczytuje się do tego rejestru R25. Dam znać
REKLAMA