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

[Attiny][asm] Obsługa przerwania ??

FlashCode 11 Lip 2008 14:05 3839 14
  • #1 5333225
    FlashCode
    Poziom 13  
    Czy ktoś z Was sie orientuje czy w każdym cyklu zegarowym sprawdzana jest flaga przerwania INT0? Szukałem po specyfikacjach i nigdzie nie podają.

    Sygnał na INT0 ma okres 64us, Attinego taktuje kwarcem 16MHz (bez div8) i widze że okres pomiędzy obsłużeniem przerwań wacha się około 63,5us - 64,5us
  • #2 5333268
    BoskiDialer
    Poziom 34  
    Generalnie flagi przerwań są sprawdzane po każdej instrukcji, ale niektóre instrukcje trwają różną liczbę cykli - niektóre nawet 3 lub 4 cykle (rcall/ret, nie pamiętam które ma 3 które 4, wiem że oba razem mają 7 cykli). Instrukcja nie może być przerwana w pół, więc pojawiają się małe różnice pomiędzy przerwaniami. W twoim przypadku pomiędzy 63,5us a 64,5us jest około 16 cykli zegara, dodatkowo rozrzut w pomiarze może być zawyżony (jeśli jedno przerwanie pojawiło się trochę później, kolejne poprawnie, to odcinek czasu będzie krótszy), tak więc masz około 8 cykli rozrzutu - to masz rozrzut na wykonaniu instrukcji oraz dodatkowo czas narastania sygnału wejściowego. Tutaj bym nie szukał problemów.. po prostu takie rzeczy się zdarzają..
  • #3 5333298
    szelus
    Poziom 34  
    Ale w czym problem? Wszystko jest dokładnie opisane w pdf-ie, rozdz. AVR CPU Core -> Reset and Interrupt Handling -> Interrupt Response Time.

    Opóźnienie wynosi min. 4 cykle i zeleży od instrukcji jaką AVR wykonuje w momencie zgłoszenia przerwania.

    Ty, jak podajesz, masz różnice czasu reakcji na poziomie 16 cykli. To nie jest dużo, ale, jak widać, może być lepiej - wszystko zeleży od Twojego programu.
  • #4 5333961
    FlashCode
    Poziom 13  
    Szelus, że skok do obsługi przerwania trwa 4 cykle to wiem, moje pytanie dotyczyło czego innego. Program po trochu wygląda tak:
    
    Petla:
    nop
    nop
    nop
    rjmp Petla
    
    Hsync : "przerwanie
    push r16
    in r16,sreg
    push r16
    push r17
    push r18  
    sbi porta,porta.7
    nop
    nop
    nop
    cbi porta,porta.7
    ......
      
       


    Porta.7 jest wykorzystywany jako wygaszanie wizji, na INT0 podawane sa impulsy sync poziomego.
    Program powinien generować pionowy pasek o grubości zależnej od ilości nop pomiędzy ustawieniem i zerowaniem portu. I te 4 cykle skoku do obsługi to wartość stała i wpływa jedynie na przesunięcie całego paska w poziomie.
    Niestety pasek nie jest prosty, jego krawędzie mają kształt piły. Przy ekranie 640*480 zęby piły skaczą na lewo i prawo o 3 piksele. Zakładając że na część widoczną lini PAL przypada 52us to 6 pikseli to 0,48us. Wobec cyklu 0,0625us to dużo i oznacza rozrzut o 8 cykli.
    W pętli głównej dawałem duuuużo instrukcji jednocyklowych i na kształt paska to nie wpływa. Czyżby odpowiedzialna jest tu instrukcja RJMP ??
  • #5 5334356
    szelus
    Poziom 34  
    FlashCode napisał:
    Szelus, że skok do obsługi przerwania trwa 4 cykle to wiem, moje pytanie dotyczyło czego innego.

    Sorry, wiem. Tak mi się z rozpędu napisało ;)

    Cytat:

    Niestety pasek nie jest prosty, jego krawędzie mają kształt piły. Przy ekranie 640*480 zęby piły skaczą na lewo i prawo o 3 piksele.

    A czym to łapiesz, bo te piksele graniczne, to może być błąd (rozdzielczość) pomiaru. Dobry oscyloskop powinien sprawę definitywnie wyjaśnić (teoria, bo ja na przykład dobrego nie mam na swoim warsztacie ;) )

    Cytat:

    W pętli głównej dawałem duuuużo instrukcji jednocyklowych i na kształt paska to nie wpływa. Czyżby odpowiedzialna jest tu instrukcja RJMP ??

    To się zgadza, ilość instrukcji jednocyklowych nie powinna mieć znaczenia.

    A jak zrobisz w pętli głównej tylko RJMP na siebie?
  • #6 5334453
    BoskiDialer
    Poziom 34  
    Może zbocza sygnału hsync nie są zbyt ostre i układ różnie reaguje.. Tu warto pomyśleć nad wykorzystaniem timera do generowania przerwań, a sam sygnał hsync próbkować w podprogramie obsługi przerwania, jeśli sygnał się przesuwa, to co kilka wywołań wprowadzać do timera jednocyklowe poprawki (chyba, że przesunięcie jest zbyt duże). Przerwanie od timera mogło by występować np. zawsze około 10-20 cykli przed przewidywanym zboczem hsync, co dało by możliwość odłożenia kilku rejestrów i przygotowanie się do generowania linii.. Dodatkowo jeśli kod jest uwikłany zależnościami czasowymi, to można cały kod przenieść do pętli głównej i tam testować stan hsync lub wyłączyć przerwania i testować stan flagi (wyłączenie przerwania nie wyłącza detekcji warunków przerwania) od INTx.
  • #7 5334532
    FlashCode
    Poziom 13  
    Cytat:
    A czym to łapiesz, bo te piksele graniczne, to może być błąd (rozdzielczość) pomiaru. Dobry oscyloskop powinien sprawę definitywnie wyjaśnić

    Na razie dokładnie pixele oglądam na LCD 21' (oczywiście za pixel biore R+G+B). Spróbuje pomierzyć na oscyloskopie dokładnie odstępy czasu pomiędzy zmianami portu.
    Tak jeszcze analizowałem i przy teorii że obsługa przerwania czeka na zakończenie instrukcji to pasek byłby poprzesuwany losowo, w zależności od tego jak zbocze na INT0 "trafiło" w cykl i instrukcję. A tu mam cyklicznie powtarzająca sie piłę, 6 zębów na ekran.
    Może zwiększyć częstotliwość taktowania? Tylko zależy mi na stosowaniu wewnętrznego generatora RC+PLL i jak zamiast 16MHz uzyskać na 20-22MHz ? W asm nie mogę poradzic sobie z przestawieniem OSCCAL
    P.S. W poniedziałek postaram się załączyć zdjęcia jak to wygląda na ekranie LCD 320*240
  • #8 5340753
    szelus
    Poziom 34  
    [quote="FlashCode"]
    Cytat:

    Tak jeszcze analizowałem i przy teorii że obsługa przerwania czeka na zakończenie instrukcji to pasek byłby poprzesuwany losowo, w zależności od tego jak zbocze na INT0 "trafiło" w cykl i instrukcję. A tu mam cyklicznie powtarzająca sie piłę, 6 zębów na ekran.

    Dokładnie. Piła jest stacjonarna, czy "płynie"?

    Szczerze mówiać, nie wygląda mi to na zakłocenia z części cyfrowej (tzn. mikrokontrolera). Nie jest możliwe, że dostaje się jakiś sygnał intermodulacyjny, choćby po zasilaniu? Z tych 6 ząbków byłoby to ok 100kHz.

    A może problem leży wewnątrz tego LCD? On na pewno bedzie sygnał przetwarzał, jakiś deinterlacing czy inny filtr, a nie jest to typowy sygnał. Może poziomy w sygnale video mu nie pasują i ARW coś miesza?
    Gdyby to był analogowy telewizor, to miałbym większe zaufanie.

    P.S. Ja tu mocno teoretyzuję. Moja praktyka, zwłaszcza ze wspólczesnym sprzętem TV nie jest taka, jak by to mogło wygłądać z mojej wypowiedzi ;)
  • #9 5341939
    FlashCode
    Poziom 13  
    Tu akurat z nowoczesnego sprzętu nie korzystam w pełni :) Z composite video na RGB rozdzielam sobie sygnał poczciwym analogowym STV22XX, synchronizację wydzielam z LM1881. Sygnał RGB+Sync podaję na zwykłe wejście Scart (RGB) TV. Wygaszanie i sygał koloru daję na wejście STV przez które oryginalnie dostaje sygnał telegazety (czyli matryca RGB szybka).
    A piła jak to piła :)
    Podłaczyłem zewnętrzny kwarc, w zależności od wartości piła ma głębsze zęby (częstotliwość mniejsza), lub płytsze (częstotliwość większa). Jak dotykam palcem kwarcu piła np zamiast falować do góray zaczyna falować w dół.
    Może najlepszym rozwiązaniem będzie maksymalne zwiększenie częstotliości ? aby zmniejszyc ząbki do minimum.....
    Zdjęć nie zdążyłem zrobić :cry:
    Jutro spróbuje jeszcze wywalić generację paska z obsługi przerwania i dam do pętli głownej (oczekiwanie na zmiane wartości portu), wtedy będę dokładnie znał liczbę cykli do zagenerowania paska.
  • #10 5343992
    FlashCode
    Poziom 13  
    Dodaje dwa zdjęcia. Oba wykonane z ekranu LCD 320*240, analogowe wejście RGB+Sync.
    Zacząłem już w tym czasie generację napisów. Pierwsze foto z kwarcem 16MHz, drugie z 17.734475MHz czyli częstotliwość lini * 2048. Szybko licząc wahania 1 piksela w prawo lub lewo to wahania +/- 3 cylke. Nadal troche dużo względem danych procka.....

    [Attiny][asm] Obsługa przerwania ??

    [Attiny][asm] Obsługa przerwania ??
  • #11 5344212
    BoskiDialer
    Poziom 34  
    Możesz synchronizować procek z dokładnością do jednego cyklu:
    in r16, pinX
    in r17, pinX
    in r18, pinX
    in r19, pinX
    in r20, pinX
    in r21, pinX
    
    bst r16, pinHSYNC
    brts _syn_5
    bst r17, pinHSYNC
    brts _syn_4
    bst r18, pinHSYNC
    brts _syn_3
    bst r19, pinHSYNC
    brts _syn_2
    bst r20, pinHSYNC
    brts _syn_1
    bst r21, pinHSYNC
    brts _syn_0
    rjmp _syn_0
    _syn_5:
    nop
    _syn_4:
    nop
    _syn_3:
    nop
    _syn_2:
    nop
    _syn_1:
    nop
    _syn_0:

    Jeśli zbocze hsync pojawi się pomiędzy pobraniami stanu portu na początku, to kod będzie się wykonywał 14 cykli licząc od tego zbocza, czyli uzyskasz synchronizację do 1 cyklu (lepsze to niż sprawdzanie stanu w prostej pętli, gdzie uzyskuje się synchronizację do 3 cykli, jeśli to jest pętla typu sbis/rjmp).
  • #12 5344460
    szelus
    Poziom 34  
    Tak sobie głośno myślę...
    640x480 to nie jest naturalna rozdzielczość systemu PAL, tylko NTSC. Dla PAL byłoby to 720x576. Czyli LCD robi transkodowanie (aproksymację) co najmniej w pionie. To może wyjaśniać cienie w kierunku pionowym.
    Jeżeli założyć, że w poziomie nie ma transkodowania, a po prostu LCD próbkuje z rozdzielczością NTSC, to mielibyśmy częstotliwość próbkowania 704*15625=11MHz. To dawałoby, przy 16/17Mhz zegarze ok 1.5 taktu na pixel.
    W połączeniu z przesunięciami fazy wynikającymi z ograniczonego pasma części analogowej może się okazać, że uzyskanie ostrych krawędzi na granicy pixela jest niemożliwe. Nie bez powodu telegazeta ma tylko 40 znaków w linii. I wydaje mi się, że w telewizorach LCD jest obsługiwana bezpośrednio przez część cyfrową...

    P.S. Może jeszcze spróbować zegara 11MHz? Albo spróbować eksperymentalnie wyznaczyć częstotliwość próbkowania.
  • #13 5345521
    FlashCode
    Poziom 13  
    Zobaczcie tutaj:
    Link
    Jest możliwe wyświetlanie przyzwoitego OSD z AVR i przy tylko 20MHz.

    Najlepsze szelus efekty uzyskałem z kwarcem 17.734475MHz - zdjęcie drugie - piksele na krawędziach nie szalały tak jak na 16MHz (a dokładnie na wewnętrznej PLL). Przy mniejszych częstotliwościach nie zmieszczę się z planowanymi znakami na ekranie (około 8 ).
    Jak dla mnie cudnie wygererowali te znaki.... :)
  • #14 5345683
    szelus
    Poziom 34  
    Co znaczy "wewnętrznej PLL"? Chyba nie chcesz przez to powiedzieć, że próbowałeś to uruchomić na wewnetrznym generatorze RC?

    Tę stronę już kiedyś widziałem. Moim zdaniem te znaki tam też momentami lekko falują, ale za dużo konwersji formatów jest po drodze, aby to stwierdzić na pewno. ;)

    Dodatkowo, jak pisałem, może być problem, na czym się ogląda. Może być też, co pisał Boski Dialer kwestia dokładności/stromości zboczy impulsów synchronizacji.

    Jest trochę eksperymentowania przed Tobą. :)
  • #15 6305981
    speecu
    Poziom 11  
    Witam!

    Temat już dawny, ale ja miałem podobne problemy gdy próbowałem zrobić kartę graficzną na Atmega16-16MHz i AVR-GCC.
    W moim przypadku wina leżała w nierównej ilości cykli pomiędzy sygnałem synchronizacji a wyświetleniem pierwszego piksela.
    Różnica 1 cyklu powodowała widoczne opóźnienie/przyspieszenie wyświetlania całej linii w stosunku do sąsiedniej, nie mówiąc już o większej różnicy.

    Może w tym jest problem?

    Pozdrawiam
REKLAMA