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

[ATMEGA][BASCOM]Obsługa kolorowych wyświetlaczy TFT.

adambehnke 18 Sie 2010 16:08 16236 30
  • #1 8411725
    adambehnke
    Poziom 24  
    Witam

    Mam pytanie do znawców.
    Czy jest jakakolwiek szansa aby można było obsłużyć kolorowy wyświetlacz TFT (powiedzmy >5") poprzez ATMEGĘ i BASCOM?
    Przyjmijmy że poświęcił bym jedną atmegę której zadaniem było by tylko i wyłącznie obsługiwanie wyświetlacza. Dane do wyświetlenia przesyłane były by do niej z innego układu.
    Widziałem że dzięki ARM i C można spokojnie sterować TFT ale u mnie niestety brak znajomości C (jak na razie) .
    Wiem że potrzeba sporych ilości pamięci ale od czego jest karta pamięci SD , czytałem także na temat wyświetlaczy z telefonów jak E51 itp. Ale mi chodzi o prawdziwe TFT.

    Widziałem w Mar....ie że są cyfrowe i analogowe wyświetlacze TFT .

    Zatem czy jest to możliwe?
  • Pomocny post
    #2 8412043
    Freddy
    Poziom 43  
    Możliwość jest dla niektórych LCD TFT. Podobno najprościej obsłużyć LCD od PSP.
    Niektóre LCD mają po prostu za duże wymagania, jak dla ATMega.
  • Pomocny post
    #3 8412166
    tmf
    VIP Zasłużony dla elektroda
    LCD >5" zwykle nie mają kontrolera tylko gołą matrycę. Możesz poświęcić ATMegę na kontroler, ale przy kolorowych będzie miała problem z czasem, a w BASCOMie to już w ogóle będzie nierealne. No i masz niebagatelny problem z pamięcią. Lepiej wsadzić dedykowany kontroler, SEDy możesz kupić po ok. 40zł, a na pokładzie masz już RAM. SD tu ci się nie nada bo raczej nie zamierzasz chyba wyświetlać statycznych obrazów? Poza tym może być problem z wyrobieniem się w czasie - wąskim gardłem będzie interfejs SPI, a w trybie 4-bitowym też nie będzie lepiej ze względu na duże zaangażowanie procesora. Z kolei analogowe LCD do twoich zastosowań zupełnie się nie nadają.
    A może jednak wsadzić ARMa lub AVR32 z kontrolerem LCD onboard?
    Ew. postudiuj DSy o XMega, ma DMA co znacząco ci pomoże jeśli zdecydujesz się na implementację kontrolera na AVR - no ale to też raczej nie w BASCOMie.
  • Pomocny post
    #4 8412254
    poorchava
    Poziom 18  
    Moim zdaniem nie da rady. Ktoś już na forum podłączał atmegę do wyświetlacza kolorowego LCD (od jakiegoś siemensa) i generalnie wyświetlenie sensownej animacji chyba się w końcu nie udało. A taki ekranik od komórki ma jakieś półtora cala. Nawet jakbyś podłączył ten TFT do atmegi, to wyświetlenie jednego ekranu będzie prawdopodobnie trwało ponad sekundę. A w bascomie to strzelałbym, że 3x tyle.

    IMO do obsługi takiego dużego TFT to bez ARM-a i C nie warto podchodzić.
  • Pomocny post
    #5 8412360
    Freddy
    Poziom 43  
    poorchava napisał:
    Moim zdaniem nie da rady. Ktoś już na forum podłączał atmegę do wyświetlacza kolorowego LCD (od jakiegoś siemensa) i generalnie wyświetlenie sensownej animacji chyba się w końcu nie udało. A taki ekranik od komórki ma jakieś półtora cala. Nawet jakbyś podłączył ten TFT do atmegi, to wyświetlenie jednego ekranu będzie prawdopodobnie trwało ponad sekundę. A w bascomie to strzelałbym, że 3x tyle.

    IMO do obsługi takiego dużego TFT to bez ARM-a i C nie warto podchodzić.

    Kolego, przecież wielkość wyświetlacza nie ma nic do jego szybkości :!:
    Poza tym, autor nie powiedział, że chce wyświetlać filmy.
  • Pomocny post
    #6 8412715
    Mat_91
    Poziom 25  
    Freddy napisał:
    Podobno najprościej obsłużyć LCD od PSP.


    Które steruje się dokładnie tak samo jak każdy inny lcd tft bez sterownika, czyli linie danych, zegar, synchronizacja pozioma i pionowa.

    Z racji że autor pyta o duży lcd ten od psp lub z maritexu 4,3" z panelem dotykowym będą najlepszym wyborem ale pod warunkiem zastosowania zewnętrznego sterownika- tak jak radzi kolega tmf jakiś SED czy tam S1D lub np ssd1906 albo ssd1926, większość z nich obsługuje się jak zwykłą pamięć (adres, data, RW, RD, CS). Reszta zależy od uC, przy tych matrycach (480xRGBX272) aby wyświetlić animację, trzeba wysłać ogromne ilości danych do sterownika, nawet biorąc pod uwagę fakt że to szyna równoległa atmega może mieć problem, do statycznych obrazów (jakieś proste GUI) wystarczy bez problemu.

    Starowanie samej matrycy (bez użycia sterownika) to ciężka sprawa, wątpię żeby atmega wyrobiła się czasowo (nie wspominam już o konieczności użycia zewnętrznego ramu).
  • #7 8413245
    adambehnke
    Poziom 24  
    Właśnie mi głównie chodzi o statyczne obrazy. Animacji raczej w moich urządzeniach nie ma. Ja używam aktualnie zwykłych wyświetlaczy graficznych opartych o t6963c 240*128 ale bardzo brakuje mi kolorów. Mam wyświetlone całą masę danych z wszelakich czujników i często aż skandal że nie ma zaznaczone jakichś wartości krytycznych w jakimś kolorze.
    W sumie to nie koniecznie muszą być TFT. Ja osobiście ładuję obrazki (menu itp) z karty SD. I jeśli czas ładowania to max 1 sekunda to jest to do zaakceptowania. Rozdzielczość 240*128 także jest trochę mała.

    Hmm w sumie taki LCD od PSP był by do przyjęcia. Zależy mi bardzo aby wyświetlać kolorowe grafiki jak na lcd z nokii .

    Podejrzewam że będzie dość trudno obsłużyć mi ten lcd z PSP , ale może się mylę.
  • Pomocny post
    #8 8413524
    tmf
    VIP Zasłużony dla elektroda
    Na AVR bez sterownika będzie ciężko. Jakbyś dodał jakiś CPLD, to mogłoby to być realne, ale potrzebujesz także RAM. Nawet statyczny obraz trzeba skądś brać - SD się nie nadaje. A jak policzysz koszty CPLD + SRAM + miejsce na płytce to dedykowany kontroler wyjdzie taniej i prościej. Ten LCD z PSP działa ładnie na AVR32 - wbudowany kontroler ładnie go obsługuje, no ale to zdecydowanie musiałbyś w C wejść.
  • #9 8413900
    adambehnke
    Poziom 24  
    Czyli obraz na tych wyświetlaczach jest odświeżany non-stop i potrzeba pamięci aby z niej przepisywać "obrazek" do LCD tak? Tak to rozumiem. Rzeczywiście jeśli tak jest to "troszkę" atmega się nie nadaje.

    I tak też chyba w końcu zrobię. Zacznę się uczyć C bo mnie już nerwica łapie.
    Ale zanim coś skumam to miesiące zapewne miną. Znów zaczynać od migania diodą i innych głupot.... no ale cóż.
  • Pomocny post
    #10 8414054
    rpal
    Poziom 27  
    Wg. mnie "przepychanie" całych ekranów z procka do LCD nawet kiedy ma on swój kontroler to pomyłka. Łatwo to policzyć ile czasu zajmie taki transfer. Przy okazji mojej "zabawy" z SED-em od kasy fiskalnej z allegro przy zwykłym czarno białym LCD ta pseudo-animacja była warta funta kłaków.Zatem może się mylę ale trzeba zaprząc tu procka którego przestrzeń pamięci danych będzie jednocześnie obszarem pamięci obrazu. Atmega nie nada się w żaden sposób. Choćby z uwagi na czasy transmisji danych pamięci obrazu.
  • Pomocny post
    #11 8414235
    tmf
    VIP Zasłużony dla elektroda
    adambehnke napisał:
    Czyli obraz na tych wyświetlaczach jest odświeżany non-stop i potrzeba pamięci aby z niej przepisywać "obrazek" do LCD tak? Tak to rozumiem. Rzeczywiście jeśli tak jest to "troszkę" atmega się nie nadaje.

    I tak też chyba w końcu zrobię. Zacznę się uczyć C bo mnie już nerwica łapie.
    Ale zanim coś skumam to miesiące zapewne miną. Znów zaczynać od migania diodą i innych głupot.... no ale cóż.


    Jest tak jak piszesz. Co do C to spróbuj, zdziwisz się jakie to łatwe. IMHO łatwiejsze niż BASCOM, bo semantyka języka jest prostsza, no i nie musisz pamiętać jakiś magicznych poleceń i ich parametrów. Za to zdecydowanie musisz się zaprzyjaźnić z notą procesora.
  • Pomocny post
    #12 8415707
    ktrot
    Poziom 20  
    [ATMEGA][BASCOM]Obsługa kolorowych wyświetlaczy TFT.

    Atmega (z dołożoną pamięcią zawnętrzną) jak najbardziej nadaje się do obsługi matryc stn i tft. Mówiąc dokładniej obsłuży każdą matrycę stn - także kolorową natomiast co do tft to maksymalna rozdzielczość matrycy to 640x480 - przynajmniej tyle udało mi się uzyskać na dzisiaj. Większość rzeczy można napisać w dowolny języku - można i Bascomie ale fragmenty krytyczne czasowo muszą być napisane w asemblerze. Jeżeli chodzi o sterowniki typu SED to moim zdaniem nie nadają się się do sterowania matrycami - jak dla mnie za dużo mają ograniczeń: tylko jedna strona co nie pozwala np na double buffering, brak szybkiego czyszczenie ekranu lub jego części (trzeba to robić punkt po punkcie zamiast w czasie 1 ramiki), za mała częstotliwość ramki co powoduje słaby kontrast w matrycach cz.b. (przynajmniej dotyczy to sed'ów, których noty analizowałem ) cena, wreszcie nic nie potrafią poza postawieniem punktu - żeby mieć do dyspozycji makrorozkazy typu linia, okrąg, prostokąt trzeba im dołożyć mikrokontroler ale wtedy po co sed?
    Na zdjęciu fragment animacji na atmega8515+2Mb pamięci oraz matryca cstn 8 cali.
  • #14 8415888
    rpal
    Poziom 27  
    Ja bym się jeszcze dodatkowo zapytał co oprócz wyświetlenia kolorowego obrazu ta Atmega może jeszcze zrobić (na co jej starczy czasu) ?
  • #15 8416011
    tmf
    VIP Zasłużony dla elektroda
    Trudno w to uwierzyć. Proste wyliczenia - matryca 640*480, odświeżanie 25Hz - dotclock=7680000Hz. Dla ATMegi8515 daje to zaledwie 2 instrukcje na pixel (przy maksymalnym taktowaniu 16MHz). Biorąc pod uwagę, że dostęp do zewnętrznego RAM trwa co najmniej o 1 cykl dłużej, to jest to 1 instrukcja/pixel. W dodatku 8515 nie ma interfejsu do XRAM, więc jakiś bajer nam wciskasz. No chyba, że masz całkiem rozbudowany hardware przyśpieszający operacje odczytu. Ale to inna bajka jest i trudno powiedzieć, że to ATMega robi. No i te wyliczenia są dla zaledwie 256 kolorów (1 bajt/pixel). W trybie 16-bitowym to już w ogóle byłaby masakra. Także też chętnie bym zobaczył schemat tego cuda.
  • #17 8416199
    UDMA
    Poziom 16  
    adambehnke napisał:
    Reasumując , to po prostu aby coś sklecić z zastosowaniem TFT to bez AVR32 nie ma co podchodzić.


    Polecam Microchipa:
    Link
  • #18 8416257
    tmf
    VIP Zasłużony dla elektroda
    adambehnke napisał:
    Reasumując , to po prostu aby coś sklecić z zastosowaniem TFT to bez AVR32 nie ma co podchodzić. W C oczywiście.
    Temat raczej wyczerpany :/


    No niekoniecznie. Po prostu kup LCD ze sterownikiem i nie będzie problemów. AVR32 jest fajny, tylko narzędzia do niego są drogie (JTAG).
  • Pomocny post
    #19 8416307
    robiw
    Poziom 26  
    Jeśli nie chce wyświetlać animacji w sensownej prędkości tylko linie, małe bitmapy itp (słowem GUI) to wystarczy TFT ze sterownikiem FSA506 (opis w EP) lub SSD1963 i ATmega32. Ot, wszystko...robiw
  • Pomocny post
    #21 8416392
    ktrot
    Poziom 20  
    Wysłałem filmik na youtube Link

    Trochę komentarz do filmu:

    Aby nie było widać za dużego migotania obrazu przy fotografowaniu kamerą
    zwiększyłem odświeżanie do ok 110Hz co spowolniło (ok 2x) cały proces rysowania
    normalnie wystarcza 60Hz. (efekt jak przy filmowaniu TV)

    1. Linie generowana kodem:
     for (i=0;i++<1000;)
    line(rand()%640,rand()%480,rand()%640,rand()%480,rand()%7+1);

    ok 200 średniej długości (400p) linii/s (nie wiem jak szybka jest funkcja rand() )

    2. Koncentryczne okręgi - ta matryca ma tylko 3 składowe co daje 7 kolorów +tło
    jednak wizualnie kolorów wydaje się więcej.
    for (q=0;q++<30;)
    {
    for (i=j;(i+=4)<240;)
    {
    circle(320,240,i,n);
    if (i>k) { n=rand()%8; k=1000;} 
    }
    n=rand()%8;
    j=rand()&7;
    k=rand()%240;
    }


    3. Wariacje trygonometryczne. Wyświetlane są dosyć wolno ale nie dlatego że sterownik wolno rysuje ale dlatego, że dla każdej figury trzeba policzyć ok 7000 razy sinus lub cosinus. Co jest istotne to każdy kolejny obrazek jest tworzony na osobnym ekranie (i tam zapamiętany). Nie będę przytaczał całego kodu bo nic ciekawego w nim nie ma -adaptowałem go z jakiejś starej gazety z epoki komputerów 8 bitowych. Dla tych, którzy są ciekawi tego fragmentu mogę wstawić.
    
         x=320+sin(kon*(i-2*r))*2*(r-65);
         y=240+cos(kon*(i+x))*2*(r+96); 
    
    zmienna i od 0 do 360, a r różnie np od -20 do +80 kon to 2pi/360

    4. Uprzednio wygenerowane obrazki teraz kolejno wyświetlamy - to właśnie umożliwia animację - te obrazki z pamięci można wrzucać na ekran z bardzo dużą prędkościo nawet 12kHz - oczywiście sens ma tylko częstotliwośc ramki.


    @tmf masz mniej więcej racje z tymi wyliczeniami, używam atmega8515 nie dlatego, że ma inteface do pamięci (bo ma) ale dlatego, że o 3 piny więcej niż np atmega16. W końcu chyba żaden avr nie interfacu do DRAM. Procesor lekko podkręcony - 20Mhz. Zarówno dla prezentowanej matrycy jak i dla TFT dotclk wynosi średnio 2.15 cykla. Szyna danych tej matrycy jest 16 bitowa (sprawdź LM8V311). Na płytce nie ma innych układów poza avr, 2 pamięciami (są 8 bitowe K4F660811B),kwarcem i 1/6 74hct14 - jedna bramka do przesunięcia sygnału.

    Na koniec: Nie upubliczniam na razie kodu i schematu - przynajmniej dopóki nie skończę to co zacząłem.
  • #23 8416706
    tmf
    VIP Zasłużony dla elektroda
    ktrot napisał:

    @tmf masz mniej więcej racje z tymi wyliczeniami, używam atmega8515 nie dlatego, że ma inteface do pamięci (bo ma) ale dlatego, że o 3 piny więcej niż np atmega16. W końcu chyba żaden avr nie interfacu do DRAM. Procesor lekko podkręcony - 20Mhz. Zarówno dla prezentowanej matrycy jak i dla TFT dotclk wynosi średnio 2.15 cykla. Szyna danych tej matrycy jest 16 bitowa (sprawdź LM8V311). Na płytce nie ma innych układów poza avr, 2 pamięciami (są 8 bitowe K4F660811B),kwarcem i 1/6 74hct14 - jedna bramka do przesunięcia sygnału.


    Interfejs do DRAM mają AVRy z serii XMega. Fajny LCD. Tylko, że ma 8 kolorów, adresowanie załatwia ci przy jednym zapisie 2*2 i 2/3 pixela i tylko dlatego AVR się wyrabia. Gdyby to był 640*480*256 kolorów to byłoby ciężko.
  • #24 8417289
    ktrot
    Poziom 20  
    Cytat:
    załatwia ci przy jednym zapisie 2*2 i 2/3 pixe

    Tak, ja używam innej notacji - ilość koniecznych przesłań w poziomie i pionie, ta matryca to 240x240 przesłań co także oznacza, że odpowiada matrycy tft o rozdzielczości 240x240, dlatego maksymalna częstotliwość odświeżania tej matrycy to ok 160Hz a tft 640x480 tylko 30Hz.
    Te 2/3 piksela nieźle dało mi w kość przy pisaniu procedury putpixel - przykładowy kolor np niebieski znaduje sie w różnym miejscu w bajcie w zależności od jego miejsca w linii. Dlatego procedurka putpixel ma coś koło 140 cykli co pozwala wyświetlic ok 75000pkt/s.


    Cytat:
    Gdyby to był 640*480*256 kolorów to byłoby ciężko.

    Właśnie nie jest tak źle jak wygląda. Mogę obniżyć częstotliwość do 27Hz (maksymalna 30Hz) niestety nie można więcej obniżyć bo zaczyna być widoczne migotanie obrazu - początkowo minimalne a przy ok 22Hz już wyraźne. Te 3Hz mniej daje mi 10% czasu procesora na malowanie - niby niedużo ale 10% to 2 mln cykli. Zakładając, że procedura putpixel zajmie 40 (a da sie to zrobić bo nie ma z tym takiego horroru jak z tą cstn - w tej chwili mam chyba 47cykli) to otrzymujemy 50000pkt/s czyli porównywalnie z cstn. Jeżeli dodać do tego prosty transfer całych prostokątnych bloków ekranu (w tym czcionki) to tft może dać nawet lepsze wyniki.

    Mam ochotę na uzyskanie na avr odświeżania 56Hz czyli zejść poniżej 2 cykli. Wstępne obliczenia wskazują, że da się ale zobaczymy...


    Ten cstn ma 2 zalety: kupiłem go bardzo tanio, (dzięki uprzejmości kolegi obecnego na elektrodzie) - w cenie wyświetlacza 2x16 a druga zaleta to ma touch panel.
  • #25 8417368
    tmf
    VIP Zasłużony dla elektroda
    Widziałem, że można go było kupić za grosze, gość chciał kilkanaście zł, co za kolorowy LCD z touch panelem jest ceną niezłą :) Szkoda tylko, że ma podświetlenie CCFL, jednak LEDami się steruje prościej. BTW, weź pod uwagę, że właściwa częstotliwość odświeżania w tych wyświetlaczach jest ważna ze względu na degradację ciekłego kryształu. Także efektem zbyt wolnego odświeżania może być nie tylko migotanie, ale także uszkodzenie LCD. Jednego STNa tak załatwiłem podczas testów.
    Przy okazji skoro to jest STN i ma tak wysokie FR, to możesz spróbować wycisnąć z niego więcej kolorów robiąc FRM. Udało mi się w ten sposób z B&W STNa wyciągnąć 16 odcieni szarości, też na ATMedze, więcej nie dało rady bo się nie wyrabiała :)
    A kolejna sprawa - spróbuj z XMega, one teraz są tanie (w cenie małych ATMega), a mają DMA, co ci odciąży mocno procesor. Przynajmniej kolejne adresy linii będziesz mógł generować z automatu. No i mają taktowanie do 32MHz.
  • Pomocny post
    #26 8417597
    ktrot
    Poziom 20  
    16 odcieni szarości? nieźle :) - musiała być niskiej rozdzielczości - na każdy odcień potrzebna jest częstotliwość podstawowa, przy której matryca nie migocze i ma odpowiedni kontrast zakładając, że matryca działa od 40Hz to aby uzyskać 16 odcieni potrzebne jest 16*40=640Hz odświeżania. Ta cstn jest dosyć szybka jak na stn co oznacza, że nie można zejść poniżej 55Hz - na 4 odcienie potrzebowałbym odświeżanie 220Hz a tyle nie mam. Robiłem próby - 2 ekrany dało 27 kolorów i działało ładnie 4 zgodnie z oczekiwaniami nie działały a 3 nie próbowałem. Jednak nie zrobi się z takiej matrycy przeglądarki do zdjęć - ponadto 1 odcień to wolniejsze wpisywanie punktów na ekran (bo trzeba na 2 ekrany wpisać - przynajmniej czasami )

    DMA mi nie pomoże bo jest wolniejsze od tego co robię. Niemniej nie pomyślałem o DMA jako generatorze adresów - to rzeczywiście warte sprawdzenia- dzięki.

    32Mhz rzeczywiście przydały by mi się, dodając do tego 1 cyklowe sbi cbi i chyba push. Niemniej zwracam się raczej w kierunku Cortexów- miałem już na warsztacie ARM ale nie sposób było ustalić ile trwają instrukcje - do sterowania matrycami się nie nadawały więc wróciłem do AVR. Cortexy pozbawione są tej wady tylko ta pinologia :( porty porozrzucane dookoła obudowy.

    Nie mam takich złych doświadczeń z degradacją matrycy, ta cstn w ogóle jest odporna na podanie napięcia przy braku sygnałow V H - wewnętrzny układ wyłącza wtedy polaryzację. Co innego moja matryca tft NL6448AC30-12 - ta to dopiero dostaje w kość - w czasie programowania dostaje stałe napięcie przez 10s (i oczywiście brak sygnałow sterujących) widać jak rozmywają się po niej plamy- wytrzymała jak dotąd chyba kilkaset takich uderzeń i żyje :) Jednak czarnobiałe matryce stn rzeczywiście wydają się być bardziej podatne na uszkodzenia od napięcia polaryzującego.
  • #27 8418310
    tmf
    VIP Zasłużony dla elektroda
    Matryca była QVGA, mono, adresacja jednocześnie 8 pixeli. Moja częstotliwość podstawowa była mniejsza, ok. 20Hz, dla mono STN nie ma problemu z miganiem, ma tak słabą dynamikę. Problem się pojawiał wraz ze wzorkami w niektórych odcieniach - było widać miganie całych płaszczyzn, ale STN niestety tak mają, podobne zjawisko obserwowałem na oryginalnych sterownikach. Co do punktów to zapisywanie było normalne, w VRAM każdy pixel miał 4 sąsiadujące bity określające odcień, a to program generujący obraz je interpretował i w danym cyklu wyświetlał lub nie. Także zapis był banalny. Niemniej projekt zarzuciłem, bo był bez sensu. Raz, że wyszły tanie kolorowe LCD z kontrolerem, co podważyło sens ekonomiczny tego projektu, dodatkowo dedykowany procesor, pamięć i dodatkowe układy to bez sensu ze względu na skomplikowanie i miejsce na płytce. Poza tym chciałem więcej :) Spróbowałem przerzucić część do CPLD, nawet wyszło, ale się okazało, że CPLD, które pomieści wszystkie funkcje nie jest tanie, więc przerzuciłem się na FPGA (głównie, żeby się tego nauczyć). Mam devboard Spartan3 i jest ok, tylko znowu - wsadziłem układ w TQFP144 :) Co prawda Spartan ma ok. 240kB RAM, więc odpada pamięć zewnętrzna, ale z kolei potrzebuje FLASH do zrzutu konfiguracji. No i znowu mamy kiszkę. Także sobie odpuściłem.
    Co do DMA, to dlaczego uważasz, że jest wolniejszy? Poza tym odciąży procesor, który będzie mógł robić inne rzeczy.
    Z kolei jeśli myślisz o zrobieniu tego na ARM to prościej kupić ARMa ze sterownikiem LCD i odpuścić sobie grzebanie. Nie mam doświadczeń z ARMem, ale na AP7000, który ma sterownik LCD moduł z PSP bardzo ładnie działa. Zresztą na avrfreaks znajdziesz fajne projekty z ATNGW100 + LCD z PSP.
  • #28 8418515
    tymon_x
    Poziom 30  
    Spartan-3AN ma wbudowany konfigurator FLASH (11Mb), zewnętrzne kosztują od 20 do 50 zł na polskie warunki. W obudowie TQFP144 jest tylko XC3S50, XC3S200 lub XC3S400 i mają odpowiednio 72kb, 216kb lub 288kb RAM. Reszta to niestety BGA i pochodne. W bajtach się nie podaje, bo słowo to Sobie można samemu określić (np. Core Generator'em) w tym tryb działania. Ale od czego jest konfigurowalna logika. Można wykorzystać zasoby do stworzenia własnej pamięci RAM (w tym Dual) lub ROM. Łatwo konfiguralne bloki IO i można zapuścić pamięci o odczycie równoległym. Do tego zaleta w postaci obsługi LVDS do dużych wyświetlaczy TFT.
  • #29 8419148
    adambehnke
    Poziom 24  
    Koledzy powiedzcie mi tak. "Kolego Adamie kup wyświetlacz xxxx( taki a taki) z wbudowanym sterownikiem , z którym dasz sobie radę w bascomie." :D
    Jeśli by miał rozdzielczość 240*128 to też bym przeżył ale muszę na dzień dzisiejszy to wysterować z Bascoma. Nie mogę porzucić-przerwac pracy nad projektem aby wykuć się C. Wszystko po kolei.
    Chyba że macie jakiś pomysł jak to ugryźć. Napisać w C lub ASM driver do jakiegoś taniego TFT i dołożyć jakiegoś ARM-a i komunikować się jakoś z moimi Atmegami (Bascomowymi) w celu załadowania jakiegoś obrazka?
    Czy Macie może inną sugestię ?
  • Pomocny post
    #30 8420634
    Dexter77
    Poziom 28  
    W pewnym popularnym czasopismie jest reklama pewnej firmy. Sprzedają wyświetlacze 320x240 TFT z kontrolerem. Kolor jest "tylko" 8bit, ale ATmega i każdy inny 8 bitowiec radzi sobie z tym bez większych zająknięć.
REKLAMA