Elektroda.pl
Elektroda.pl
X
SterControl
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

jacynka84 23 Gru 2013 20:47 4164 21
  • #1 23 Gru 2013 20:47
    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.

    0 21
  • SterControl
  • Pomocny post
    #2 24 Gru 2013 08:44
    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.

    0
  • #3 24 Gru 2013 10:00
    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.

    0
  • SterControl
  • #4 24 Gru 2013 12:13
    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.

    0
  • #5 24 Gru 2013 17:22
    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ć.

    0
  • #6 24 Gru 2013 20:36
    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ć.

    0
  • #7 26 Gru 2013 03:30
    Marek_Skalski
    Moderator Projektowanie

    @jacynka84:
    Usiądź sobie i spokojnie się zastanów co chcesz zrobić. Ze względu na język który wybrałeś nie masz wielkich możliwości, ale ostatnie zdanie wskazuje, że coś sensownego już wymyśliłeś.
    BlueDraco dobrze napisał, że kasowanie ekranu (pamięci) przed załadowaniem nowych wartości jest bez sensu. Modyfikujesz je właściwymi do wyświetlenia. Ponadto, kontrolery TFT mają albo sprzętową sygnalizację rysowanej linii (Tear Effect), albo rejestr z którego odczytujesz numer aktualnie rysowanej linii, co pozwala rozpocząć proces odświeżania danych w pamięci w takim czasie, gdy nie grozi to "zgrzytami" na matrycy. Ale to chyba nie zadziała z Bascomem, który jest zbyt powolny.
    Jeżeli przeładowujesz pamięć, to przesyłasz tylko to co zmieniasz. Stałych elementów, tj. ramki, tło, opisy; nie dotykasz. 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. Jeżeli to jest bargraf, to malujesz część aktywną i domalowujesz do końca kolor tła. Najlepiej synchronicznie do skanu pamięci obrazu (TE/raster). Jeżeli to jest bitmapa, to znasz rozmiary pola docelowego i samej bitmapy, rysujesz obraz, a kasujesz tylko to co "wystaje". Operacje ogranicza się zawsze do minimum. No, ale grafika po SPI to jakiś masochizm.
    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).

    0
  • #8 26 Gru 2013 05:40
    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

    0
  • #9 26 Gru 2013 22:02
    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...

    0
  • #10 27 Gru 2013 15:57
    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.

    0
  • Pomocny post
    #11 27 Gru 2013 19:52
    Marek_Skalski
    Moderator Projektowanie

    ASMnauka napisał:
    zapytam z czystej ciekawości.
    Na jakim interfejsie Miałeś podłączony wyświetlacz ?

    EBI w trybie 3 portowym + zatrzaski dla LSB i MSB. Dzięki temu przez DMA przesyłane były słowa, które nie wymagały modyfikacji. Nie polecam.
    ASMnauka napisał:

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

    Mylisz się, a Kolega otrzyma pełny przebieg. Istotą jest modyfikowanie tylko tego co konieczne. Jeżeli rysujesz punkty zdefiniowane jako napięcie w funkcji czasu, każdy punkt rysujesz osobno dla każdej chwili czasu. Linie są tylko w celu poprawy czytelności wykresu, ale na to trzeba mieć znacznie więcej mocy obliczeniowej. Jeżeli chcesz zrobić pseudo-oscyloskop w oparciu o Xmega, TFT320x240 po SPI, to nie oczekuj więcej niż 100Hz samplowania real time. Nic więcej nie policzysz i nie wyświetlisz. A jeżeli chcesz wyświetlać wyniki jako postprocessing, to nie ma większego znaczenia jak rysujesz, ponieważ każdy ekran rysujesz na nowo. Chociaż 3s oczekiwania lub więcej mogą irytować.
    Cytat:
    W jakim celu?

    W takim, że bargraf czy inne elementy graficzne mogą zmieniać wskazania na + oraz na -. Jeżeli będziesz malował tylko na +, to w przypadku zmniejszenia wartości obrazowanej, Ty już tego nie zauważysz. Najpierw malujesz część aktywną paska (pokazującą wartość), aby uzyskać wskazanie, a następnie wypełniasz resztę paska kolorem, paternem, czy grafiką dla części nieaktywnej. Dzięki temu nie widać żadnych ubocznych efektów rysowania. Jeżeli będziesz robił odwrotnie albo wstępnie czyścił całe pole aby później narysować część aktywną, to prawie zawsze będzie widać miganie czy szarpnięcia podczas pracy urządzenia.
    Cytat:
    Oczywiście w przypadku, gdy procent kontrolki maleje, należy nadpisać poszczególne piksele kolorem tła.

    Sam sobie odpowiedziałeś na wcześniejsze pytanie.

    @jacynka84:
    Ale co Bascom kompiluje do asm? Swoje makra i rozwlekłe funkcje, które zanim się wykonają, to muszą sprawdzić tysiąc różnych rzeczy, albo robią różne rzeczy okrężną drogą. Napisz prosty program: uruchom licznik w trybie CTC, w przerwaniu czytaj klawisze, eliminuj drgania i zapalaj ledy, a w pętli głównej usypiaj procesor. Pokaż jak to wygląda w asm z Bascoma. Chętnie zobaczę o ile większy i wolniejszy będzie taki kod w porównaniu do C albo czystego .asm.
    A co do wstawek... Nigdy nie interesowałem się Bascomem, ale na tym Forum jest sporo osób, które doszły do etapu kiedy cały program w Bascomie był wstawką asm, ponieważ tylko wtedy możliwe było uzyskanie założonego działania programu. No wybaczcie, ale Bascom nie nadaje się do zadań związanych z grafiką czy sterowaniem real-time (czyli <1ms). Do tego jest C, ew. wspomagany przez .asm.

    Co do ilości pamięci, to źle liczysz. 320x240x24bpp to tylko 320x240x(3x8bit) = 240kB. Jeżeli użyjesz 16bpp, to potrzebujesz 150kB. Na ogół zawsze wiesz jakie jest tło i dlatego możesz je rysować. A jeżeli masz "aplikację" z okienkami, to zawsze rysujesz tylko aktywne okno i ew. pasek zadań: wskaźniki, kontrolki czy zegarek. Okna nieaktywne są nadpisywane na ekranie i nie wymagają aktualizacji z uwagi na swoją nieaktywność (oczywiste). Usuwane są podczas minimalizacji lub zamknięciu okna, ale to też wymaga włączenia ich aktywności poprzez wskazanie i polega to na przerysowaniu okna "rodzica" i/lub innych okien aktywnych na ekranie lub tła (background) przy braku aktywnych okien.
    Pozdrawiam!

    0
  • #12 29 Gru 2013 13:25
    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

    0
  • #13 29 Gru 2013 15:21
    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: basic4gl
    Zaloguj się, aby zobaczyć kod

    0
  • #14 29 Gru 2013 19:53
    Marek_Skalski
    Moderator Projektowanie

    Zrobiłeś to dokładnie odwrotnie niż należało. 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. Dlatego masz taki tragiczny obraz na ekranie.
    Napisz jedną funkcję, która działa w pętli od 0 do N, rysuje aktualny punkt i kasuje stary punkt (o ile jest różny od aktualnego).
    W C będzie to jakoś tak:

    Kod: C
    Zaloguj się, aby zobaczyć kod

    Powinieneś widzieć jedynie przesuwający się obszar o szerokości 1 piksela, w którym zachodzą zmiany na ekranie. Spróbuj to przepisać do swojego programu i porównaj z tym co masz. Możesz też pokazać jak wyszło.
    Oczywiście zamiast podwójnej tablicy możesz użyć bufora cyklicznego, ale na tym etapie spróbujmy z prostym rozwiązaniem. Optymalizację zostawmy na później.

    0
  • #15 29 Gru 2013 20:16
    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.

    0
  • #16 29 Gru 2013 20:37
    Marek_Skalski
    Moderator Projektowanie

    Taka podpowiedź... współrzędna w poziomie to numer próbki, w pionie to wartość przeskalowanej próbki. Jeżeli nie indeksowałeś w poziomie, to nic dziwnego, że miałeś tylko "szczelinę".
    Tak Kolego, od iluś tam lat pracuję z wyświetlaczami (LED, LCD, TFT, VFD i plazmowe). Zawsze wyświetlam to co potrzebuję. Dlatego staram się też pomóc innym Kolegom na Forum (co znajdziesz w moich postach), ale Tobie nie potrafię.
    Pozdrawiam!

    0
  • #17 29 Gru 2013 21:04
    tmf
    Moderator Mikrokontrolery Projektowanie

    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: asm
    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.

    0
  • #18 29 Gru 2013 22:26
    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ć.

    0
  • #19 30 Gru 2013 00:56
    Marek_Skalski
    Moderator Projektowanie

    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. Wszystko zależy od ilości "wolnego" czasu :)
    Wojować nie zamierzam, ponieważ dobieram to co mi bardziej pasuje do wymagań aplikacji, niż do tego co mam w magazynie lub zwyczajnie lubię.
    Kończę udział w dyskusji o wyświetlaniu obrazu na TFT przez SPI programowane w Bascomie.
    Pozdrawiam!

    0
  • #20 30 Gru 2013 03:34
    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.

    0
  • #21 30 Gru 2013 10:29
    tmf
    Moderator Mikrokontrolery Projektowanie

    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.

    0
  • #22 30 Gru 2013 11:20
    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.

    0