Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

LCD tft ili9320 fonts duża czcionka

baracuda2 23 Mar 2016 22:38 2136 23
  • #1
    baracuda2
    Level 13  
    Witam

    Posiadam wyświetlacz ili9320 i potrzebuje uruchomić na nim jakąś dużą czcionkę. Niestety tylko 8x16 oraz 8x14 (oraz inne małe) wyświetla się poprawnie. Duże czcionki jak np. z linku poniżej inne wyświetlają tylko krzaczki.

    Funkcja do wyswietlania znaku:
    Code: c
    Log in, to see the code


    Dane z pliku fonts.h dla czcionki 8x16:
    Code: c
    Log in, to see the code


    Proszę o pomoc z uruchomieniem dużej czcionki z linku (font_big.h lub Arial28x28.h) :
    Czcionki


    Z góry dziękuje za wszelką pomoc.
  • #2
    User removed account
    User removed account  
  • #3
    BlueDraco
    MCUs specialist
    A to widział?

    uint8_t tmp_char=0;

    Zmień typy na szersze i ew. popraw liczbę obiegów pętli.
  • #5
    User removed account
    User removed account  
  • #7
    User removed account
    User removed account  
  • #8
    grko
    Level 33  
    @Piotrus_999
    Pierwsze 4 bajty tego fonta to metadane:
    xsize, yszie, bytes_per_char, char_count

    Czyli będzie:
    16, 16, 32, 95

    Z całą pewnością ta czcionka to 16x16
  • #9
    User removed account
    User removed account  
  • Helpful post
    #11
    grko
    Level 33  
    @baracuda2
    Musisz przerobić funkcję wyświetlajacą na LCD fonta w ten sposób:
    - musi wiedzieć jaki forn ma rozmiar: x, y
    - musi wiedzieć ile znaków jest w foncie

    Te paramatry opisane są przez pierwsze 4 bajty w foncie (przynajmniej tej poprzedniej). Na tej podstawie mozesz zabrać się za pisanie funkcji wyświetlajacej dowolnego fonta.

    Kodu nie musisz pisać na MCU. Funkcja wyświetlającą możesz przetestować na PC. Tu masz wersję dla fonta 16x16:

    Code: c
    Log in, to see the code


    Teraz zastanów sie jak powinna wyglądać funkcja wyświetlająca dla fonta o dowolnym rozmiarze.
  • #13
    ASMnauka_
    Level 15  
    baracuda2 fonty z tej strony są zapisywane inaczej.
    Arial12x12.h
    Arial24x23.h
    Arial28x28.h
    font_big.h

    mają w nagłówkach następujące dane:
    Code: c
    Log in, to see the code

    Tak więc trzeba je odczytywać inaczej.
    Tutaj Masz programy do odczytu tych czcionek, grafiki itd.

    A to jest część programu odpowiedzialna za odczyt czcionek.

    Code: c
    Log in, to see the code

    Tak więc w kolejności Musisz odczytać:
    1. Offset
    2. Szerokość czcionki
    3. Wysokość czcionki
    4. Ilość bajtów na linię
    A swoją drogą jest to bardzo dziwaczny sposób zapisu\odczytu czcionki.
    Wszelkich obliczeń (w locie) wynikających z zapisu czcionki można uniknąć .
    baracuda2 wrote:
    TFT_dot(x+j,y+i,charColor); // 字符颜色

    Nie używaj tego dziadostwa.
    Bardzo spowalnia działanie programu.
    Na każdy wyświetlony piksel Musisz wywołać TFT_dot
    Wzoruj się na przykładzie ze strony, do której link podałem.
    A dokładnie na tym:
    Code: c
    Log in, to see the code


    baracuda2 wrote:
    najbardziej zależy mi na czcionce Neu42x35

    W przypadku tej czcionki informacje o niej zostały zamienione.
    211,42,35,5,
    Począwszy od lewej:
    1. Ilość bajtów w znaku (czcionce)
    2. Szerokość
    3. Wysokość
    4. Ilość bajtów w linii
  • #14
    User removed account
    User removed account  
  • Helpful post
    #15
    ASMnauka_
    Level 15  
    Piotrus_999 wrote:
    W odróżnieniu od asemblera kompilator dobrze sobie poradzi z takimi obliczeniami. Wyoptymalizuje jak należy.

    W to nie wątpię (poradzi sobie z optymalizacją).
    Natomiast jeśli chodzi o asemblera to programista musi o wszystko zadbać.
    Jednak nie ulega wątpliwości, iż zarówno zapis, jak i odczyt jest dziwaczny.
    A najgorsze jest to, że wszelkie obliczenia muszą być wykonane w locie, co znacznie spowalnia działanie całego programu.
    Code: c
    Log in, to see the code

    A tutaj proszę przykład innego zapisu.
    O wiele prostszego, a co jest bardzo istotne zajmuje o wiele mniej miejsca.
    Co prawda w tym przypadku też obliczenia muszą być wykonane w locie, ale wiele mniej, niż w podanych wcześniej fontach.
    baracuda2 tutaj Masz ciekawą lekturę dotyczącą Twojego problemu.
  • #16
    User removed account
    User removed account  
  • #17
    ASMnauka_
    Level 15  
    Piotrus_999 wrote:
    Każdy ma prawo wybrać metodę zamęczania się.
    Piotrus_999, szanuję Cię, lecz proszę nie pisz takich rzeczy.
    Już wielokrotnie napisałem, że pisanie w ASM jest dla mnie przyjemnością
    Piotrus_999 wrote:
    w jak najbardziej upakowanej formie to będzie trochę liczenia. Nie ma cudów
    Żaden z fontów przedstawionych w tym temacie nie jest upakowany.
    Są jedynie zapisywane w dziwaczny sposób.
    Upakowany może być font, który jest "skompresowany" metodą RLE.
    Czyli zbędne zera przy zapisie się wycina, następnie zapisuje się ilość powtórzeń.
    Natomiast przy odczycie trzeba odczytać ilość powtórzeń, po czym je odczytać.
    Oczywiście metoda kompresji RLE jest stratna, ale to już inny temat.
  • #18
    Eagle
    Level 24  
    Quote:
    Oczywiście metoda kompresji RLE jest stratna, ale to już inny temat.


    Run-Length Encoding (RLE, kodowanie długości serii) – prosta metoda bezstratnej kompresji danych, której działanie polega na opisywaniu ciągów tych samych liter (bitów, bajtów, symboli, pikseli itp.) za pomocą licznika powtórzeń (długości ciągu), a dokładniej przez pary: licznik powtórzeń litery, litera.
  • #19
    ASMnauka_
    Level 15  
    Eagle, pisząc o kompresji stratnej RLE w tym przypadku (odczyt czcionki jak i plików BGF) miałem na myśli spowolnienie programu.
    Najpierw musimy znaleźć w pliku bajt o wartości &HAA.
    Jeśli bajt jest równy &HAA. to odczytaj ilość powtórzeń.
    Następnie niezbędna jest dodatkowa pętla, która wykona się tyle razy ile jest powtórzeń.
    A można przedstawić to i tak.
    1. Odczytaj bajt
    2. Jeśli bajt = &HAA
    3. Odczytaj ilość powtórzeń
    4. Zmniejsz ilość powtórzeń
    5. Pętla wykonująca odczytaną ilość powtórzeń
    Tak więc jasno widać, iż bardzo dużo tracimy z punktu widzenia szybkości działania programu.
  • #20
    Freddie Chopin
    MCUs specialist
    ASMnauka_ wrote:
    Tak więc jasno widać, iż bardzo dużo tracimy z punktu widzenia szybkości działania programu.

    W efekcie nasz program będzie kręcił się w pustych pętlach zaledwie przez 91.43% czasu, a przecież mógłby nic nie robić przez 95.75% czasu!
  • #21
    grko
    Level 33  
    Narzekanie na algorytm dekodowania RLE, który ma złożoność obliczeniową O(n) jest naprawdę niedorzeczne. Widać że, fani mikro-optymalizacji oraz zwolennicy nie używania zbyt dużych ilości dostępniej pamięci FLASH/RAM, jak zwykle szukają problemów tam gdzie ich nie ma.
  • #22
    Freddie Chopin
    MCUs specialist
    No... I to jeszcze okazało się, że używając RLE wydajności nie tracimy tak po prostu, tylko tracimy jej

    ASMnauka_ wrote:
    [...] bardzo dużo [...]


    Strach pomyśleć, co assemblerowcy uważają o jakichś "normalnych" algorytmach na cokolwiek... (;
  • #23
    Eagle
    Level 24  
    Quote:
    pisząc o kompresji stratnej RLE w tym przypadku (odczyt czcionki jak i plików BGF) miałem na myśli spowolnienie programu.


    Kompresja stratna – metoda zmniejszania liczby bitów potrzebnych do wyrażenia danej informacji, które nie dają gwarancji, że odtworzona informacja będzie identyczna z oryginałem.

    Aby w przyszłości nie było nieporozumień, lepiej nie redefiniować ogólnie przyjętych definicji. Zresztą dowolna metoda kompresji, będzie wypływała na wydajność.
  • #24
    User removed account
    User removed account