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

[ATMEGA][C] - LCD T6963 240*128 i ładowanie bitmap z karty SD.

adambehnke 03 Wrz 2012 22:16 16701 109
  • #1 11276311
    adambehnke
    Poziom 24  
    Witam
    Męczę się właśnie nad napisaniem obsługi ładowania bitmap na wyświetlacz graficzny 240*128 T6963.
    Do obsługi używam znanych bibliotek kolegi Radosława Kwietnia (radzio.dxp.pl/t6963/).
    Sama obsługa wyświetlania tekstu i rysowania po ekranie jest już przeze mnie opanowana. Tak samo ładnie wyświetlają się też bitmapy odpowiednio skonwertowane programikiem także pana Radka. Bitmapę testową mam załadowane do pamięci programu. Ale niestety muszę ładować te bitmapy z karty pamięci SD.

    Obsługa kart także działa już. Używam Petit FatFs .Mogę spokojnie odczytać zawartość pliku i wyświetlić ją na LCD.
    Ale nie mam pojęcia jak ugryźć ładowanie bezpośrednio z pliku na LCD bez użycia bufora. Chodzi mi o zmaksymalizowanie szybkości ładowania z karty i zmniejszenia zużycia RAM-u.

    Tak czytam kartę SD:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod



    W taki sposób ładuję includowany wcześniej plik z obrazkiem:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod



    Podejrzewam że do ładowania bitmapy muszę w trakcie odczytu zaprzęgnąć ten fragment:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    ale nie wiem od czego zacząć i jak to ugryźć. Nie ukrywam że wcześniej pisałem w Bascomie i ten projekcik z GLCD jest dla mnie dość trudnym wyzwaniem. Ale zanim założyłem ten temat to spędziłem kilka ostatnich dni nad opanowywaniem biblioteki pana Radka.

    Samo odczytywanie plików docelowo ma wyglądać mniej więcej w taki sposób:
    - podaję (nazwę obrazka do załadowania , koordynatę X i Y oraz rozmiar obrazka X i Y)

    Później chciałbym dorobić możliwość wyboru czy wyświetlany obraz ma być w negatywie czy nie. Ale to już powinno być proste.

    Chciałbym docelowo używać do konwersji bitmap programu ze strony pana Radka więc odczyt i ładowanie na lcd danych musi uwzględniać taki format danych jaki zapisuje ten program czyli np:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Tutaj widzimy że obrazek wyląduje w kodzie programu. Co prawda używam Atmega2560 ale obrazków będzie na tyle dużo że muszą być czytane bezbuforowo z karty SD ( ewentualnie jakiś mały podreczny bufor).

    Proszę w miarę możliwości o jakieś sugestie w jaki sposób się za to zabrać.

    Wydaje mi się że powinienem zacząć od tego. Przykład odczytu danych i wysłania strumienia danych dalej (znalazłem to w opisach Elm Chan):

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Z tym że i tu wykorzystywany jest bufor...






    Dla testu napisałem sobie fragment odpowiedzialny za pseudo ładowanie grafiki przy użyciu instrukcji SetPixel. Obrazek skonwertowałem BMP to ASCII do formatu (01010101) czyli zapalony piksel w obrazku to logiczna "1".

    Tu fragment:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Nawet to działa ale makabrycznie wolno (około 15 sekund jeden obrazek).Mam małe przesunięcie na LCD obrazka ale to już szczegół.

    Wstawiam w załączniku plik który ładuję na ekran.
    Ale taki format danych nie może szybko działać.Wolałbym aby było to jednak ładowane w formie do jakiej konwertuje obrazki programik Radka.

    Niestety takie ładowanie nie nadaje się do mojego urządzenia. W Bascomie schodziłem poniżej sekundy....

    Dodaję także w załączniku grafikę którą sobie narysowałem. Jest w formacie 1 bitowym.
  • Pomocny post
    #2 11278580
    tmf
    VIP Zasłużony dla elektroda
    Najpierw uściślijmy twoje potrzeby. Pisząc bitmapy masz na myśli pliki w formacie monochromatycznym BMP? Czy bitmapa będzie wyświetlana na LCD w stałym miejscu, czy miejsce wyświetlania konkretnej bitmapy może się zmieniać?
    Jeśli dana bitmapa, przynajmniej w poziomie będzie wyświetlana zawsze w tym samym miejscu, to prościej ją rozszerzyć, tak, aby zajmowała pełne bajty (piksele rozszerzające zostaw zgaszone). Dzięki temu ładujesz nie po pikselu co jest wolne, ale po prostu transferujesz całe bajty, co jest bardzo szybkie. Jeśli bitmapa może zmieniać położenie, to i tak możesz zrobić optymalizację - wysyłaj całe bajty a nie piksele, w tej sytuacji wyświetlanie brzegów bitmapy wymaga specjalnego traktowania. W skrócie odczytujesz bajt z VRAM, zerujesz wchodzące na niego bity z bitmapy i orujesz z bitmapą, po czym zapisujesz do VRAM. Będzie to kilkanaście razy szybsze niż wyświetlanie po pikselu.
    Z drugiej strony, to co masz najwolniejsze to zapewne odwołania do karty SD. Weź pod uwagę, że odczyt nawet jednego bajtu z SD, wymaga odczytu całego sektora (512 bajtów). Przejrzyj źródła petitFS, ale idę o zakład, że funkcja pf_lseek i pf_read, jeśli ma odczytywać 1 bajt są ultrawolne. Lepiej dobrać się bezpośrednio do 512-bajtowego bufora (który pewnie i tak masz) i stamtąd czytać dane. To może w zależności od implementacji w petitFS być nawet tysiące razy szybsze niż kombinacja lseek/read. Pamiętaj też, że normalna funkcja read powinna też zmieniać wskaźnik odczytu na kolejny bajt, więc kosztowne lseek za każdym razem nie jest potrzebne, właściwie w ogóle nie powinno być potrzebne.
    Pamiętaj też, że masz narzędzie o nazwie objcopy, które potrafi m.in. konwertować pliki binarne na pliki obj, nadające się do zlinkowania z kodem. Z drugiej strony, skoro masz SD to może prościej trzymać na niej po prostu bitmapy, w formacie BMP? Odczyt takiej bitmapy o znanej głębi kolorów wymaga pominięcia stałej, z góry znanej liczby bajtów od początku pliku (nagłówek pliku BMP). Dzięki temu oszczędzasz pracochłonnych konwersji plików, szczególnie pracochłonnych jeśli jak widać robisz to niemalże ręcznie.
  • #3 11278605
    adambehnke
    Poziom 24  
    Dziękuję za zainteresowane.
    Tak , grafiki będą wyświetlane zawsze w tym samym miejscu, na pełnym ekranie o formacie 240*128. Bitmapy jakie konwertowałem są monochromatyczne 1 bitowe. Rzeczywiście rysuję je ręcznie, piksel po pikselu (masakra) .
    Jeśli jest możliwość abym nie musiał ich konwertować to by było idealnie gdyż mogę sobie na bieżąco zmieniać szczegółu na danym obrazku i nie musiałbym ich konwertować w kółko.
    Jeśli ładowanie obrazka trwało by poniżej 0.5 sekundy bo było by super.
    Nie jestem jeszcze aż tak dobry w C dlatego zabieram się do tego jak za "jeża" :D

    Teraz tak sobie patrzę na rozmiar pliku graficznego w formacie *.bmp i tego skonwertowanego do 010101 i różnica w rozmiarze jest ogromna.
    Plik nie konwertowany ma 4k a skonwertowany 30,2k! Więc już sama ilość danych jaką muszę odczytać z karty jest ogromna przy konwertowanym pliku.

    Zapomniałem jeszcze że na LCD stosuję czcionkę w trybie 6 pikseli a dokładnie:

    // display properties
    #define GLCD_NUMBER_OF_LINES 128
    #define GLCD_PIXELS_PER_LINE 240
    #define GLCD_FONT_WIDTH 6

    W module dla którego piszę program używam rs485 o prędkości 115200 i z tego względu podniosłem taktowanie do 18.432 MHz (przyjazne dla uart). Bałem się że będę miał problemy z odczytem karty Sd ,Pcf-a i ds18b20 ale wszystko działa wyśmienicie poza ładowaniem grafik. Dlatego przy takim taktowaniu odczyt z karty SD powinien być dość szybki do tego celu. Na koniec mam zamiar odchudzić maksymalnie biblioteki i usunąć nie uzywane funkcje.
  • Pomocny post
    #4 11278669
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #5 11278703
    mirekk36
    Poziom 42  
    Korzystanie z PetitFS aby było szybkie to tylko i wyłącznie odczyt do bufora w pamięci RAM po 512 bajtów. Każdy odczyt mniejszej ilości bajtów to i tak odczyt sektora 512 bajtów a potem wyszukiwanie w nim tylu bajtów ilu potrzebujesz. Więc zastanów się jeśli ty próbujesz odczytywać po 1 bajcie to i tak aby odczytać 512 tych bajtów, aż 512 razy zostanie odczytany za każdym razem ten sam sektor. Więc rzeczywiście pozostaw daleko za sobą myśli o tym aby nie buforować odczytu z karty bo robisz sobie sam szkodę.

    Załadowanie obrazka monochromatycznego powinno być tak szybkie, że w twoim przypadku wąskim gardłem będzie prędzej twój typ (rodzaj) wyświetlacza niż odczyt z karty. Zobacz sobie tutaj, gdzie odczytuję obrazki z karty SD także za pomocą petitFS ale na wyświetlacze 3,5" 320x240 albo 4,3" 480x272 tyle że nie monochromatyczne a LCD TFT - pełen kolor w standardzie RGB(888) czyli po 3x8 bitów na jeden pixel. I zobacz jak to szybko leci:

    www.atnel.pl/download/filmy/ssd1963a/ssd1963a.html

    www.atnel.pl/download/filmy/ssd1963b/ssd1963b.html

    opisane masz to tutaj:

    https://www.elektroda.pl/rtvforum/topic2094762.html

    tylko że linki do filmów nie działają dlatego podałem aktualne wyżej.

    To co widzisz na filmikach to właśnie odczyt z karty SD za pomocą PetitFS

    Do odczytu w ogóle nie musisz korzystać z pf_lseek(), po co ???? każdy odczyt automatycznie przesuwa wskaźnik odczytu pliku i działa to jak widzisz rewelacyjnie. Nawet Fondy dynamicznie udaje się ładować ;) dzięki temu można ich mieć do woli i do syta ;)

    Reasumując, sposób odczytu pliku polega na:

    1. utworzeniu bufora w RAM 512 bajtów
    2. wczytywanie po kolei od początku plików danych do tego bufora pf_read()
    3. wyrzucanie danych z bufora do wyświetlacza LCD
    4. ale wysyłanie do LCD całych bajtów a nie broń boże jakieś zabawy pixel po pixelu

    i to będzie najszybciej ;)
  • #6 11278707
    adambehnke
    Poziom 24  
    Nie chcę koniecznie pozbywać się bufora. Zależało mi na Ramie ale widzę że mam go jeszcze sporo to można wygospodarować bufor na 512 bajtów.
    Pozbyłem się pf_lseek ale ładowanie tylko minimalnie przyśpieszyło.
    Wydaje mi się że mój tryb w jakim skonwertowałem plik jest do d... Po prostu plik jest za duży.
    Dodatkowo instrukcja GLCD_SetPixel jest bardzo wolna gdyż zapuściłem zapełnianie ekranu w pętli wartością 1 całego ekranu czyli 30720 pikseli i trwa to około 2 sekund.
    Czy jest możliwe wpisywanie danych bezpośrednio do LCD pomijając SetPixel?


    Co do odpowiedzi kolegi Mirka to teraz widzę że nie obędzie się bez bufora. Jestem na bieżąco z filmikami kolegi gdyż nawet mam subscrybcję na YouTube i aż mnie łzy zalewają jak widzę jak to wszystko ślicznie działa. Nie ukrywam że nawet mam wyrwane sobie część włosów :P
  • Pomocny post
    #7 11278733
    mirekk36
    Poziom 42  
    Spokojnie nie wyrywaj włosów - tylko zdecydowanie odpuść sobie właśnie SetPixel bo masz dobre przeczucie że to ci MEGA SPOWALNIA :(

    musisz wysyłać całe bajty jak wyżej dopisałem a pewnie ten wyświetlacz LCD to umożliwia, niedługo w programie PixelFactory pojawią się opcje konwersji plików bitmap monochromatycznych do wykorzystania na różnych LCD monochromatycznych.

    https://www.elektroda.pl/rtvforum/topic2165982.html
  • Pomocny post
    #8 11278735
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #9 11278748
    mirekk36
    Poziom 42  
    Przyznam szczerze że sam teraz w wolnych chwilach a mam ich niestety mało - walczę z własnymi bibliotekami do wyświetlacza KS108 i jak dokończę to właśnie na tej bazie będę dopisywał obsługę bitmap monochromatycznych do tegp PixelFactory ;)
  • Pomocny post
    #10 11278750
    tmf
    VIP Zasłużony dla elektroda
    adambehnke napisał:
    Dziękuję za zainteresowane.
    Tak , grafiki będą wyświetlane zawsze w tym samym miejscu, na pełnym ekranie o formacie 240*128. Bitmapy jakie konwertowałem są monochromatyczne 1 bitowe. Rzeczywiście rysuję je ręcznie, piksel po pikselu (masakra) .
    Jeśli jest możliwość abym nie musiał ich konwertować to by było idealnie gdyż mogę sobie na bieżąco zmieniać szczegółu na danym obrazku i nie musiałbym ich konwertować w kółko.
    Jeśli ładowanie obrazka trwało by poniżej 0.5 sekundy bo było by super.
    Nie jestem jeszcze aż tak dobry w C dlatego zabieram się do tego jak za "jeża" :D

    Teraz tak sobie patrzę na rozmiar pliku graficznego w formacie *.bmp i tego skonwertowanego do 010101 i różnica w rozmiarze jest ogromna.
    Plik nie konwertowany ma 4k a skonwertowany 30,2k! Więc już sama ilość danych jaką muszę odczytać z karty jest ogromna przy konwertowanym pliku.

    Zapomniałem jeszcze że na LCD stosuję czcionkę w trybie 6 pikseli a dokładnie:

    // display properties
    #define GLCD_NUMBER_OF_LINES 128
    #define GLCD_PIXELS_PER_LINE 240
    #define GLCD_FONT_WIDTH 6

    W module dla którego piszę program używam rs485 o prędkości 115200 i z tego względu podniosłem taktowanie do 18.432 MHz (przyjazne dla uart). Bałem się że będę miał problemy z odczytem karty Sd ,Pcf-a i ds18b20 ale wszystko działa wyśmienicie poza ładowaniem grafik. Dlatego przy takim taktowaniu odczyt z karty SD powinien być dość szybki do tego celu. Na koniec mam zamiar odchudzić maksymalnie biblioteki i usunąć nie uzywane funkcje.


    1. Skoro bitmapy są wyświetlane zawsze w tych samych miejscach, to rozszerz je tak, aby rozmiar poziomy był wielokrotnością liczby 8. Dzięki temu po prostu przepisujesz bitmapę bajt po bajcie do VRAM - już masz kilka razy szybciej.
    2. Bitmapy po konwersji są 8x dłuższe bo masz je w pliku tekstowym, binarnie to będzie ciągle to samo.
    3. Nie musisz konwertować. Format pliku BMP mono jest stały, wystarczy pomiąć x pierwszych bajtów (zobacz jak zbudowany jest plik BMP) i dalej masz gołą bitmapę nadającą się wprost do przeniesienia na LCD.
    4. Nieużywane funkcje linker potrafi sam usunąć jeśli mu ciutek pomożesz - zobacz opcje kompilatora -ffunction-sections, -Wl,--gc-sections. Szkoda czasu na ręczną zabawę, to nie Bascom :)
  • #11 11279000
    adambehnke
    Poziom 24  
    No to ok. Załóżmy że stworzę bufor o rozmiarze 512 bajtów

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    i zacznę odczytywać plik w taki sposób:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod



    z tym że pomijam nagłówek (z tego co wyczytałem jest to 40 bajtów) i zaczynam czytać od 41 bajtu.

    Odczyt robię w pętli do momentu napotkania konca pliku lub ustawiam sobie z góry ilość pętli .

    Ale teraz pytanie. W jaki sposób ładować dane do lcd? Polecenie SetPixel już odpada.
    Położenie początkowe grafiki mogę określić poleceniem
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    dalej muszę użyć chyba polecenia
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    ale tu nie jestem tego pewien i nie wiem jak to zrobić.

    i co z trybem w jakim pracuje lcd czyli
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Proszę o cierpliwość do mnie za moje powolne myślenie ale C uczę się od niedawna i jeśli proszę o pomoc to znaczy że nie mam pojęcia co robić..
  • Pomocny post
    #12 11279079
    tmf
    VIP Zasłużony dla elektroda
    Dodatkowy bufor jest ci niepotrzebny - te dane już są w pamięci SRAM mikrokontrolera. Przejrzyj źródła petitFS, będziesz wiedział jak się dobrać do jego wewnętrznego bufora (chyba, że ma jakieś funkcje, które go po prostu udostępniają). Dzięki temu niepotrzebnie nie będziesz kopiował 512 bajtów, no i przede wszystkim nie stracisz tej pamięci.
    Co do pisania po LCD - tak, musisz użyć funkcji bezpośrednio zapisującej do VRAM. Użycie SetPixel nie ma sensu. Swoją drogą, przejrzyj notę do KS108, to tak prosty kontroler, że sam to rozkminisz w parę minut i napiszesz sobie funkcje dostosowane do swoich potrzeb.
  • #14 11279186
    tmf
    VIP Zasłużony dla elektroda
    W sumie masz rację, lepsze jest wrogiem dobrego :) Na początek przy pomocy pf_read odczytuj po 512 bajtów i zapisuj do VRAM bajt po bajcie. Jeśli wyniki ciągle nie będą cię satysfakcjonować to wtedy dopiero kombinuj dalej.
  • #15 11279188
    mirekk36
    Poziom 42  
    Napiszesz napiszesz - bo początek już dobrze wymyśliłeś i nie słuchaj, że bufor ci nie potrzebny. Bardzo dobrze wymyśliłeś z buforem i odczytem pliku do końca, o to właśnie chodzi. Więc nie słuchaj podpowiedzi jak to niektórzy piszą że PetitFS posiada jakiś swój wewnętrzny bufor. Ja podpowiadam ci nie jakieś wyimaginowane i zmyślone sposoby, tylko piszę na podstawie tego co sam zrobiłem, co działa, co można zobaczyć.

    Co do dalszej części zadania to jeśli twój wyświetlacz to KS108, to też dobrze piszesz, że trzeba zapisywać dane bezpośrednio do pamięci w postaci całych gotowych bajtów, bo tak ten wyświetlacz ma pamięć zorganizowaną. Bajty są poustawiane że tak powiem pionowo i tworzą wiersze. Więc łatwo się je zapisuje.

    A zatem po wczytaniu danych do swojego bufora pamiec[] od razu w pętli wyrzucasz po kolei te bajty do wyświetlacza pilnując wierszy....
  • #17 11279378
    mirekk36
    Poziom 42  
    adambehnke napisał:
    Mój wyświetlacz ma kontroler T6963.


    Ok rzeczywiście - coś mi się wydało że wspomniałeś po drodze o KS108. Ja na tym T6963 jeszcze nie działałem więc w takim razie tu szczegółów nie podpowiem ale pewnie też można w nim całe bajty zapisywać albo ich część - no to już pewnie ty jego notę PDF znasz lepiej niż ja na tą chwilę.
  • Pomocny post
    #18 11279462
    Konto nie istnieje
    Poziom 1  
  • #19 11279518
    adambehnke
    Poziom 24  
    Zacznę najpierw od trybu GLCD_FONT_WIDTH 8 i jeśli uda mi się wyświetlić coś to wtedy będę działał z kolejnym trybem.

    Nie rozumiem tylko jak użyć polecenia do ładowania danych do LCD.

    Owszem odczytuję 512 bajtów i pomijam nagłówek pliku czyli 40 bajtów, więc zaczynam czytać te 512 bajtów w rzeczywistości dopiero od 40 bajtu.

    I tu na początku wydaje mi się że mogę sobie użyć
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
    i tym samym pomijam nagłówek i zacznę odczyt od 40 bajtu.

    Potem użyję
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
    i będę miał w zmiennej pamiec 512 bajtów danych gotowych do załadowania do LCD.

    Ale teraz jak ładować te dane. Owszem rozumiem że co 30 bajtów muszę zmieniać linię jesli dobrze rozumuję.

    Ale jakiej funkcji użyć do wysyłania danych do LCD? Czy ma to być
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
    ?

    gdzie X to będzie pamiec[xx] ?

    Oczywiście ładowanie 512 bajtów zapuszczę w pętli czyli XX będzie incrementowane w pętli i w między czasie po każdych 30 bajtach zmieniam linię .

    Czy jakoś w miarę dobrze to rozumuję?? Bo wydaje mi się że się zakręciłem.
  • #20 11279639
    Konto nie istnieje
    Poziom 1  
  • #21 11279672
    adambehnke
    Poziom 24  
    No i coś udało mi się napisać. Ale wyświetla mi zmiksowany obraz. Tak jak by plik był wpisywany na ekran od tyłu.
    Rozpoznaje niektóre fragmenty z mojej bitmapy ale to co było na dole to wyświetla u góry itd.
    Czytam opis formatu BMP i napisano tam " Następnie w pliku znajdują się dane obrazowe.

    Linie obrazu zapisywane są od dołu do góry."
    I to by chyba tak było.
    Zaraz zwariuję.O co tu chodzi??


    Napisałem dla testu coś takiego. Nie czytam całych 512 bajtów tylko 30 (jedną linię), bo chcę sprawdzić o co tu chodzi.

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Ale jak piszę , wyświetla zmiksowany obraz.


    Dołączam biblioteki z których korzystam.Są ogólnodostępne na stronie Radka więc nie powinno być problemów że je wklejam.
  • #22 11279734
    tmf
    VIP Zasłużony dla elektroda
    BMP istotnie tak ma, że obraz jest do góry nogami. Ale to nie przeszkadza, wystarczy w funkcji wyświetlania rysować od dołu i już będzie ok. Czyli swoje a2 zmieniasz na for(a2=30;a2==0;a2--). Poza tym nie czytaj po 30 bajtów, tylko po 512, aż dojdziesz do końca pliku i wtedy oczywiście czytasz tylko końcówkę. Ten petitfs istotnie nie ma nawet bufora odczytu, więc każde wywołanie funkcji pf_read to konieczność przeczytania całego 512-bajtowego sektora i ew. pominięcia n- pierwszych bajtów. Z drugiej strony, jakby trochę podrasować tą funkcję, to można by prosto zrobić normalny, sekwencyjny odczyt po bajcie bez żadnych strat.
  • #23 11279765
    adambehnke
    Poziom 24  
    No to jedno już się wyjaśniło. Spróbuję malować od dołu. Ale nadal nie wiem jak używać tej funkcji : GLCD_WriteDisplayData(pamiec[a2]); Czy to co robię jest dobrze? Bo nie jestem tego pewien. W ogóle czy dobrze czytam (no może poza tymi 512 bajtami) i wysyłam dane do LCD? Kierunki i rotację dopracuję ale czy dobrze to robię. I czy rzczywiście nie muszę wskazywać na nową linię? Z tego co pisze Atom to wynika że nie. Pamiętam program który kiedyś napisał (nawet go mam przed oczami) w Bascomie i linia nie jest zmieniana. ładowane są tylko dane do LCD.
    Kolejna sprawa to w jaki sposób rozpoznać koniec pliku nie licząc bajtów jakie odczytałem i wiem ile bajtów ma plik?

    Znalazłem inny opis formatu BMP i cytuję: "Kolejność rozmieszczenia pixeli w pliku BMP: od lewej do prawej, od dołu do góry (pierwszy pixel w pliku pochodzi z lewego dolnego rogu obrazu)."


    edit: Poddaję się! Idę spać...
  • #24 11279869
    Konto nie istnieje
    Poziom 1  
  • #25 11279872
    adambehnke
    Poziom 24  
    Rzeczywiście mogę to obrócić na kompie. Ale nie zmienia to faktu że nie mogę się uporać z prawidłowym wyświetlaniem.
    Obrazki mogę konwertować i(lub) obracać itd. Ważne jest dla mnie aby ładowały się maksymalnie szybko.

    Czytałem nawet po 512 bajtów i wyświetlałem to na lcd ale ciągle widać sieczkę. WPisywałem dane na lcd od każdej strony , po jednej linii itp. Ale nadal nic nie wychodzi. Dam sobie spokój na dzisiaj. Może któryś z kolegów wpadnie na pomysł co może być przyczyną. Teoretycznie miało to być proste zadanie ale jak widzę to prawdziwa wyprawa na marsa....

    W jaki sposób zapisać na PC plik BMP aby nie było w nim nagłówka tylko surowe dane do wyświetlenia ? W moim programie graficznym jest tylko opcja zwiazana z zapisem bitmapy jako zwykłe BMP oraz OS2/BMP.

    Nie mogę nadal sobie poradzić z zapisem do LCD. Może używam niewłaściwej funkcji? Lub nie tak czytam plik i zapisuję do LCD?
    Nie udało mi się dotychczas nawet uzyskać kawałeczka obrazu poprawnie załadowanego na wyświetlacz.
    Próbowałem za pomocą res = pf_lseek(40); pomijać już różnej długości nagłówki ale bez powodzenia.
    Wydaje mi się że robię błąd w innym miejscu.
  • #26 11280328
    Konto nie istnieje
    Poziom 1  
  • #27 11280350
    adambehnke
    Poziom 24  
    Cześć.

    No fakt. Nocne siedzenie mi nie służy.

    Ale zrobiłem sobie teraz dla testu małą pętelkę znowu czytajaca tylko po jednym bajcie i nadal mam mix na LCD. To znaczy widać w pomiksowanym obrazku że jest obrócony do góry nogami ale jest rozmazany na ekranie.

    Tu pętelka:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod



    Może źle kombinuję ale jeśli wg. standardu BMP "Kolejność rozmieszczenia pixeli w pliku BMP: od lewej do prawej, od dołu do góry (pierwszy pixel w pliku pochodzi z lewego dolnego rogu obrazu)." to jeśli zaczynam czytać plik i jeśli pominę nagłówek to powinienem zacząć pisać do lcd i wskazywać miejsce w które ma zostać wpisany bajt do LCD. Czyli powinienem tak samo pisać jak i czytać ,skoro czytam od lewego dolnego narożnika to tak samo powinienem pisać do LCD.

    Czy dobrze myślę? Pomijam już to że obraz będzie odwrócony. Ważne na początek abym poprawnie załadował cokolwiek.
  • #28 11280410
    tmf
    VIP Zasłużony dla elektroda
    Pliku bmp bez nagłówka nie zapiszesz, bo bez nagłówka to nie byłby już plik bmp :) Gimp umożliwia różne cuda, w tym zapis raw. Ale co szkodzi pomijać nagłówek?
    Co do sieczki, możesz wrzucić fotkę? To by ułatwiło znalezienie przyczyny. Jeśli kolejne linie są poprzesuwane to może po prostu szerokość obrazu jest inna niż pętla rysująca bajty. Szerokość jest podzielna przez 8?
  • #29 11280483
    Konto nie istnieje
    Poziom 1  
  • #30 11280488
    adambehnke
    Poziom 24  
    Tak szerokość jest podzielna przez 8. Rozmiar bitmapy to dokładnie 240*128.
    Bitmapy wcześniej były już ładowane na ten sam LCD tyle że w Bascomie i wszystko działało rewelacyjnie.

    Proszę , tutaj aktualny kodzik testowy(dla testu nadal tryb 1bitowy):

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod




    A tutaj zrzut ekranu i grafika taka jaką powinno załadować:

    [ATMEGA][C] - LCD T6963 240*128 i ładowanie bitmap z karty SD. [ATMEGA][C] - LCD T6963 240*128 i ładowanie bitmap z karty SD.


    Dodaję także programik do konwersji grafik ze strony Radka oraz plik wynikowy po konwersji grafiki 240*128 i wybraniu czcionki 5*8.
    Może można by ładować grafikę na lcd tak jak to robi funkcja void GLCD_Bitmap(unsigned char * bitmap, unsigned char x, unsigned char y, unsigned char width, unsigned char height) z biblioteki T6963 jaką zamieściłem wcześniej?
    Aż tak duzo pracy nie ma z konwersją grafiki do jakiegoś innego formatu.
REKLAMA