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

[BAS i inne] - Oto kod Bas do lcd 320x240, jak robią odświeżanie bez "Clear

jacynka84 23 Gru 2013 20:47 5061 21
  • #1 13092829
    jacynka84
    Poziom 26  
    Jest taki sterownik napisany przez HKipnik w Bascom, do ekranu kolorowego 320x240, na spi.
    Otóż inni na YT odpalają z nim linuksa i wszystko działa super, nie widać żadnego odświeżania, wszystko płynnie teksty grafika. I teraz zasadnicze pytanie jak tego dokonują?? Czemu normalnie w C czy Bas trzeba użyć funkcji czyszczenia ekranu żeby się pozbyć tego co już się nie wyświetla ale "wisi" w VRAM, przez co samo nie znika?
    Jak napisać funkcję która by nadpisywała TYLKO to co chcemy aby przestało się wyświetlać a nie cały ekran powodując koszmarne miganie??
    To dotyczy raczej każdego języka.
    Zamieszczam kod w bas, jest tu użyte SPI HARD na porcie E dla karty SD,
    oraz SPI na porcie D dla LCD, wszystko na Xmega przy 48Mhz i 3,3V.
    Jest napisana tu też opcja wyświetlenia rozmiaru bitmap,
    i wyświetlanie ilości pozostałego miejsca na karcie i miejsca ogólnie.
    Oraz przyciski na porcie C i ich sprawdzanie.
    Tylko nie pytajcie o schemat bo jest banalny. Przyciski na porcie C, LCD można samemu zadecydować, z SPI na porcie D, i karta na porcie E, oba SPI hard, deklaracje już są. Reszta jest do decyzji własnej jak zawsze.
    Może ktoś miałby pomysł na ulepszenie odświeżania?
    A może znacie przykładowy kod w C lub bas na którym się wzorować który właśnie tak działa?
    Zapomniałem dodać że chodzi o ILI9341 na SPI.
  • Pomocny post
    #2 13093991
    ASMnauka
    Poziom 12  
    Cytat:
    Jak napisać funkcję która by nadpisywała TYLKO to co chcemy aby przestało się wyświetlać a nie cały ekran powodując koszmarne miganie??


    Wystarczy :
    1. W odpowiednim miejscu wyświetlacza np. X =100, Y = 120 ustawić okienko auto inkrementacji.
    2. Ustalić rozmiar okienka w zależności od potrzeb.
    3. Wysłać ciąg danych o kolorach poszczególnych pikseli.

    I mamy zapełnioną jedynie część wyświetlacza, która jest Nam niezbędna w danej chwili.

    Mniej więcej tak:

    Set_window 100,120,50,50
    Write_Data Yellow


    Gdzie w Set_window dwie pierwsze informacje to współrzędne X i Y, natomiast trzecia i czwarta to rozmiar okienka.
    W przypadku Write_Data Yellow to kolor, jakim zostanie wypełniony kwadrat.

    Osobiście nie porozumiewam się z SSD po SPI, lecz przez magistralę 16-sto bitową. Sądzę jednak, że nie będzie problemu ze zrozumieniem jaka jest różnica pomiędzy tymi dwoma sposobami komunikowania się XM a SSD.

    Dodaję specyfikacje układu ILI9341.
    Ciebie interesują w tym przypadku strony strony 110 do 113.


    Pozdrawiam.
  • #3 13094245
    BlueDraco
    Specjalista - Mikrokontrolery
    Czegoś tu nie rozumiem. Powtórny zapis tej samej zawartości do pamięci wyświetlacza nie powoduje żadnego migotania, ani nie wymaga wcześniejszego czyszczenia. Po prostu wyrzuć wywołanei funkcji czyszczenie wyświetlacza.
  • #4 13094553
    jacynka84
    Poziom 26  
    Dzięki za wskazówki, także wymyśliłem ze jeśli chodzi o znaki to zwyczajnie mógłbym spróbować używać tła o stałym kolorze, po czym nadpisywać znaki gdy chcę je usunąć tymi samymi znakami ale w kolorze tła, jest to jakiś sposób aby nowe znaki nie zmieszały się ze starymi.
    Z grafiką dynamiczną jednak jest problem, jak np oscylogram czy coś w tym rodzaju.

    Nie rozumiesz chyba BlueDraco, jak nie czyszczę lcd to wszystko zostaje czy chcę wyświetlać czy nie, muszę właśnie użyć czyszczenia aby np tekst stary nie nałożył się na nowy.

    Dodano po 5 [minuty]:

    problemem jest to ze używa się jako VRAMu w takich LCD static ramu, który nie wymaga odświeżania jak sd ram, przez co właśnie mamy taki skutek że piksele wiszą tak długo jak ich nie nadpiszesz lub wyczyścisz, nieważne że już nie używasz funkcji wyświetl coś tam.
  • #5 13095474
    ASMnauka
    Poziom 12  
    Cytat:
    Z grafiką dynamiczną jednak jest problem, jak np oscylogram czy coś w tym rodzaju.


    Nie prawda.

    Jeśli chodzi o wykresy to po prostu:

    1. Zostaje wyświetlony piksel (X i Y) o zdefiniowanym wcześniej kolorze do końca wykresu.
    2. Jeśli wykres osiągnie koniec wcześniej zdefiniowanej pozycji X, lub Y zostają SKASOWANE informacje o pozycji piksela X i Y i ewentualnie o kolorze, o ile istnieje taka potrzeba np. podczas zbyt wysokiej temperatury).
    3. skok do 1.

    Jest to oczywiście jeden z wielu możliwych przykładów.

    Analogicznie do grafiki.

    Chcąc uzyskać prostą animację o rozdz. 120 * 80 pikseli trzeba się dobrze napocić.
  • #6 13095748
    jacynka84
    Poziom 26  
    Ciągle nie chwytasz, mówię że jak wyłączam funkcję która coś wyświetla, to i tak się wyświetla nadal bo jak nie dam polecenia skasuj to i tamto to VRAM w ekranie czy gdzieś tam sam z siebie tego nie przestanie wyświetlać.
    LCD ma gdzieś że nie ma już tej grafiki, u niego w ramie jest i tu się rodzi cały problem bo sam z siebie jej nie skasuje, zresztą skąd miałby wiedzieć czym nadpisać niepotrzebne dane. Można tylko samemu napisać funkcję która znajdzie piksele znaków lub grafiki i je nadpisze np kolorem tła.

    Dodano po 16 [minuty]:

    Wymodziłem że zrobię np linia oscylogramu mi się kręci w pętli, po każdej jest czyść ekran, więc zrobię tak by zamiast czyść rysował tę linię drugi raz ale w kolorze tła. A znaki łatwo bo one się całe jako kratka 8x6 nadpisują.
    Lub tak samo jak linia, tym bardziej ze wtym kodzie chyba też używa do rysowania czcionki funkcji rysuj piksel.
    Jednak dobrze by było jeszcze coś wydumać dla obrazków czy czegoś takiego, bo jak nadpisze kawałek obrazka to reszta obrazka nadal zostaje.

    Np obrazek zajmuje 200x200px, jeśli przestaję go wyświetlać to można by np skierować go do funkcji która czyści jedynie tyle pikseli ile zostanie przekazane w argumencie a argument to wielkość obrazka właśnie. Coś się z tego da zrobić.
  • #7 13099117
    Konto nie istnieje
    Poziom 1  
  • #8 13099133
    ASMnauka
    Poziom 12  
    Marek, zapytam z czystej ciekawości.
    Na jakim interfejsie Miałeś podłączony wyświetlacz ?

    Cytat:
    W przypadku oscyloskopu nie malujesz żadnej czarnej linii, tylko za każdym razem malujesz kolorem aktywnym 1 nowy punkt i malujesz kolorem tła 1 stary punkt, o ile ma wartość różną od nowego.


    W tym przypadku założyciel posta otrzyma jedynie przesuwający się punkt, a nie pełny wykres na wyświetlaczu.

    Cytat:
    Jeżeli to jest bargraf, to malujesz część aktywną i domalowujesz do końca kolor tła.

    Natomiast w tym błędnie to Zrozumiałeś
    Cytat:
    i domalowujesz do końca kolor tła.

    W jakim celu ?

    Kolor tła jest z góry ustalony, jeśli wzrasta procent wypełnienia kontrolki to należy jedynie za pomocą auto inkrementacji ustalić w jakich współrzędnych X, oraz Y ustalić linię dla kontrolki, po czym wypełnić ją pikselami o zadanym kolorze.

    Można to zrobić na wiele sposobów.
    Na przykład tak.
    [BAS i inne] - Oto kod Bas do lcd 320x240, jak robią odświeżanie bez "Clear
    W tym przypadki tablica to zbiór pikseli o współrzędnej X 121, natomiast wysokość to 21 pikseli.
    Więc jeśli ustawimy okno auto inkrementacji na przykład na X = 100 i y = 100, oraz wysokość na 21 i oczywiście szerokość kontrolki np. na 100 to otrzymamy wspomniany bargraf.

    Oczywiście w przypadku, gdy procent kontrolki maleje, należy nadpisać poszczególne piksele kolorem tła.

    Cytat:
    Ze względu na język który wybrałeś nie masz wielkich możliwości


    Niestety i ja zaczynałem od Bascoma, lecz doszedłem do wniosku, iż jest to zbyt prosty język (nie wiedziałem co robi kompilator), więc przesiadłem się na ASM.
    Jednak, jeśli programista zastosuje w newralgicznych punktach wstawki ASM to nie ma problemu.

    Cytat:
    Dla porównania... wypełnienie 1 kolorem matrycy 800x480x16bpp na Xmega128A1U@32MHz ze wsparciem z EBI i DMA, pisane w asm zajmowało mi ok. 0,75s


    Marek, jeśli Miałeś głębię kolorów 16-sto bitową a XMegaU w EBI obsługuje jedynie magistralę 8 bitową, tak więc i tak Musiałeś programowo poskładać kolory, po czym je wysłać do sterownika TFT.

    Reasumując producent XMegi nie nie przewidział, by był on sercem odtwarzacza DVD, nie wspominając już o wyższej pozdzielczości.
    Pozdrawiam
  • #9 13101465
    jacynka84
    Poziom 26  
    LCD na SPI to rzeczywiście masochizm, ale był to najtańszy z dostępnym w BAS kodem LCD 320x240, śmiga nawet nieźle bo ustawiłem xmega na 48Mhz i SPI clock /2.
    Ale sam Bascom wcale nie spowalnia lub mało. Należy zauważyć że można kompilować do asm, więc pewnie robi to tak z całym kodem po czym do hexa wynikowego.
    wszystkie biblioteki są w asm!

    Gdyby wiedział jaki pixel i w jakim kolorze był wyświetlony wcześniej przed wyświetleniem danej rzeczy, to można by było dopiero świetne odświeżanie zrobić. Zresztą w pro wersjach sterów urządzeń jak telefony i takie różne pewnie tak to właśnie robią. W sterach na ARM do pewnych lcd przy poleceniu wyświetl jest np kontrolka 1/0 na wyświetlaj lub nie, nawet jak funkcja jest włączona, czyli jak masz dwa obrazki to jak któryś ma zero to jest pod tym co ma 1. Jakoś tak to działa.
    Ale podejrzewam że trzeba by mieć masę ramu aby cały ekran zapamiętać, a nawet połowę. 320x240 przy 24 bitach to o ile dobrze liczę ~1,85MB...
  • #10 13103432
    ASMnauka
    Poziom 12  
    Cytat:
    Gdyby wiedział jaki pixel i w jakim kolorze był wyświetlony wcześniej


    Istnieje taka możliwość.

    Memory Read komenda to 2Eh

    Strony 116 i 117.
  • Pomocny post
    #11 13104481
    Konto nie istnieje
    Poziom 1  
  • #12 13111727
    ASMnauka
    Poziom 12  
    Marek, za moment Cię zlinczują osoby piszące w C.

    Cytat:
    Do tego jest C, ew. wspomagany przez .asm.

    Tak czy owak kod wynikowy jest przetwarzany na ASM.
    ASM nie jest łatwym językiem, to prawda.
    Lecz jeżeli programista zrozumie działania wielu instrukcji tego języka, jak również złożoności pętli itd. to przeskoczy zarówno Bascom-a, jak i C.

    Pozdrawiam
  • #13 13112241
    jacynka84
    Poziom 26  
    Macie tu film jak działa odświeżanie metodą nadpisania starej linii, słabo bo SPI.
    Ale i tak o wiele wiele lepiej niż zapis całego ekranu...
    Tu kod, pierwsza część zbiera wyniki z adc do tablicy druga dostosowuje do wysokości ekranu trzecia wyświetla oscylogram czwarta też rysuje oscylogram ale kolorem tła i daje właśnie efekt kasowania starej zawartości.
    Banalne. Pomyślę jeszcze jak przerobić ten zapis aby nie smarował tej czarnej lini, bo mamy nadal nieładny efekt ale przy SPI już nic więcej nie zdziałam.
    Chyba zrobię go od nowa na SSD1289 bo mam, na 16bit.
    Kod: text
    Zaloguj się, aby zobaczyć kod



  • #14 13113332
    Konto nie istnieje
    Poziom 1  
  • #15 13113421
    jacynka84
    Poziom 26  
    Marek_Skalski napisał:
    Zamiast rysować punkt i kasować stary punkt w pętli od 0 do N, to Ty rysujesz punkty od 0 do N, następnie kasujesz punkty od 0 do N.


    Zrobiłem jak mówisz oraz jeszcze inaczej, i miałem tylko pionową kreskę. Jakbym oglądał przez pionową szczelinę.
    Rysowałem to też funkcją rysuj pixel, łatwiej i łatwiej zrobić co mówisz, ale mam wtedy zamiast linii śnieg. Bo brak funkcji która by połączyła te piksele w linię oscylogramu.
    Robiłeś kiedyś na LCD? Zrób a zobaczysz.
    Ale oczywiście dzięki za udział i pomoc.
  • #16 13113537
    Konto nie istnieje
    Poziom 1  
  • #17 13113698
    tmf
    VIP Zasłużony dla elektroda
    Marek_Skalski napisał:

    Dla porównania... wypełnienie 1 kolorem matrycy 800x480x16bpp na Xmega128A1U@32MHz ze wsparciem z EBI i DMA, pisane w asm zajmowało mi ok. 0,75s, podczas gdy to samo na STM32F417@168MHz + FSMC+DMA, pisane w C, bez optymalizacji trwało ok. 15ms (>50x szybciej).


    Trochę OT, ale coś tu mocno się nie zgadza. 800x600x16bpp to daje 960000 bajtów, teraz weźmy zapis jednym kolorem:
    Kod: text
    Zaloguj się, aby zobaczyć kod

    co nam daje łącznie 6 taktów, oczywiście do tego trzeba dodać organizację pętli zewnętrznej bo to umożliwia przesłanie tylko 64 kB, a potrzebujemy prawie 960. Ale zewnętrzna pętla praktycznie nie zmienia podanych czasów. Czyli powinniśmy uzyskać czas zapisu dla 32 MHz równy troszkę ponad 150 ms.
    To jak uwzględnimy różnice częstotliwości zegarów (32 vs. 168 MHz) daje nam tylko dwukrotny przyrost dla ARM. Oczywiście nie zmienia to faktu, że łączenie takiego LCD z XMEGA jest strzałem w stopę i nie piszę tego, żeby kogokolwiek zachęcać do takich działań :)
    Niemniej jak spojrzymy na typowe i tanie Cortex M0 z zegarem max 48 MHz, to już ARM tak różowo nie wygląda...
    BTW, twoje problemy jak pamiętam wynikały z kłopotów z interfejsem EBI - jakoś 6 WS musiałeś dawać?
    Nie odbieraj tego jako jakąś nową wojnę ARM vs. AVR, po prostu jestem ciekaw skąd wynikają rozbieżności.
  • #18 13114150
    jacynka84
    Poziom 26  
    Jednak używają nieliczni aż 7" ekranów 800x480 z np SSD1963 do xmega, i w Bascom...Tzn widziałem jeden projekt, ale kod otwarty i jak kto chce to sobie też może go użyć.
    I generalnie to działa, ale wyplucie BMP trwa...z sekundę. Więc o fps'ach można zapomnieć.
  • #19 13114665
    Konto nie istnieje
    Poziom 1  
  • #20 13114769
    ASMnauka
    Poziom 12  
    jacynka84 o ile się nie mylę to wyświetlacz na filmiku pochodzi z telefonu SIEMENS S65 na sterowniku LS020.
    A jeśli tak to jego rozdzielczość wynosi 177x132 piksele.

    Cytat:
    Oczywiście nie zmienia to faktu, że łączenie takiego LCD z XMEGA jest strzałem w stopę ...


    tmf, oczywiście, jeżeli Ktoś sądzi, że poczyni CUDA polegające na napisanie programu odtwarzającego filmy skompresowane np. DIVX-em jest błędzie.
    Nawet korzystając z dedykowanego scalaka (jak ma to miejsce w stacjonarnych i przenośnych DVD z funkcją odtwarzania wspomnianego DIVX-a) XMEGA nie ma wystarczającej mocy obliczeniowej.

    Lecz jeżeli programista chce jedynie wyświetlać grafikę w postaci kontrolek, uwidocznić informacje RDS itd. to nie widzę przeciwwskazań.
    Tym bardziej, że w tej chwili dostępne są pamięci równoległe i XMEGA posiada EBI, co znacząco wpływa na prędkość przesyłu informacji.
    Można również całą niezbędna grafikę wczytać do XRAM, lub SRAM (zewnętrznego), następnie żonglować nią do woli, co znacząco przyśpieszy efekt końcowy.
    Oczywiście XRAM jest wolniejszy od SRAM, ale ma swoja zaletę w postaci wielkości.
  • #21 13115151
    tmf
    VIP Zasłużony dla elektroda
    Marek_Skalski napisał:
    tmf napisał:
    BTW, twoje problemy jak pamiętam wynikały z kłopotów z interfejsem EBI - jakoś 6 WS musiałeś dawać?

    Pokazałeś kawałek kodu w asm, który nijak się ma do transmisji przez DMA.
    Co do opóźnień, to prawda. Mimo stosowania SRAM 55ns nie mogłem zejść poniżej 5WS, ponieważ gubiłem bajty. Powodem była prawdopodobnie zbyt mała stromość zboczy sygnałów na Xmega. Zrobiłem kiedyś kilka pomiarów w tym zakresie, ale nie były dla mnie jednoznaczne i w końcu przesiadłem się na STM32F417 @168MHz.
    Co ciekawe, tutaj też mam opóźnienia na wystawienie adresu, danych i podtrzymanie danych i wszystko działa prawidłowo i znacznie szybciej. Być może niedługo podzielę się z Kolegami moją biblioteką dla SSD1963 dla CM4, a może też dostosuję ją do Xmega.


    Ale dla EBI taktowanego 64 MHz (max dla XMEGA) potrzebujesz pamięci o czasie dostępu <15 ns! Dostęp trwa jeden takt CLKPER2. Jeśli mają dłuższy to trzeba wstawiać WS i te 5 WSów by się mniej więcej zgadzało z czasem dostępu do SRAM na poziomie 55 ns. No i zewnętrzne latche muszą być naprawdę szybkie.
    Niesądzę, aby stromość zboczy była problemem - przetaktowywałem dla zabawy EBI do ponad 110 MHz i ciągle świetnie działało z SDRAM (nie mam SRAM o tak krótkich czasach dostępu).
    Co do mojego przykładu - oczywiście nie ma nic wspólnego z DMA. Można to zrobić na DMA, czas transferu 4 takty zegara, chyba, że procek odwołuje się do IO lub zewnętrznej pamięci - wtedy ma wyższy priorytet i transfer w tym czasie przez DMA wydłuża się do 5-6 taktów zegara.
  • #22 13115311
    jacynka84
    Poziom 26  
    ASMnauka napisał:
    jacynka84 o ile się nie mylę to wyświetlacz na filmiku pochodzi z telefonu SIEMENS S65 na sterowniku LS020.
    A jeśli tak to jego rozdzielczość wynosi 177x132 piksele.

    Nie. Ten z mojego filmu to 320x240, pisałem przecież że na SPI działa.
REKLAMA