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

tAvrLib: nowe procedury obsługi wyświetlacza HD44780

Tomkiewicz 24 Gru 2009 22:20 25880 40
  • #31
    Tomkiewicz
    Poziom 13  
    Wystarczy, że wspomniany użytkownik doda sobie ten przełącznik do własnego projektu (o ile nie korzysta bezpośrednio z linkera).

    Posuwanie się do stwierdzenia, że to błąd, jest moim zdaniem nadużyciem. Owszem, nie jest to rozwiązanie idealne, ale lepszego kompromisu nie znalazłem. Wspomniane wycinanie kodu przez preprocesor zwiększyło by ilość stałych do zadeklarowania przy konfiguracji co najmniej dwukrotnie (a już ktoś narzekał, że i tak jest ich podobno dużo). Nie mówiąc o znacznym zaciemnieniu kodu.
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • #32
    PO.
    Poziom 20  
    Nooo, gratulacje :) .

    Nie powiem, żeby mi się wszystko w Twojej bibliotece podobało i od razu zaznaczam że nie przewiduję w moim życiu jej użytkowania :P ale powstaje konkretny projekt.
    Jak sam zaczynałem to szybko zauważyłem że dostępne biblioteki zawierają błędy a co najmniej niedokładności i niezręczności programistyczne ;) i też zacząłem pisać własną - cały czas ją rozwijam w miarę potrzeb i używam dość uniwersalnie do wszystkich moich projektów.
    W podłączeniu lcd bezpośrednio tylko 4bit z odczytem zajętości - kulturalnie i skutecznie i tylko tak polecam używać. 8bit natomiast mam tylko jako podłączone przez ekspander (a w zasadzie dwa ekspandery) ze względu na czasy przesyłania, co chyba zrozumiałe - nie zrozumiałem z opisu jak to się u Ciebie zachowuje, czy podłączasz lcd przez ekspandery czy masz je "luzem" jako dodatek.

    Nie udostępnię mojej biblioteki, chętnie natomiast podzielę się doświadczeniami. Nie traktuj poniższego jako złośliwości, pliss.

    Nie przejrzę Twojej biblioteki w całości, nie lubię zresztą dłubać w cudzych kodach ;) ale zainteresowało mnie w niej wyświetlanie polskich znaków - i chyba znalazłem drobny błąd w dokumentacji w przykładzie na początek:
    Code:

            HD44780_PUTPSTR("Zażółć gęślą jaźń");

    Sam piszesz że jest tylko 8 pól :) . Ostatni zdefiniowany znak "wskoczy" na miejsce pierwszego jeśli definiujesz dynamicznie. A jeśli tylko ze strony kodowej, to co się stanie z "ź"?

    Jak w ogóle tworzysz sobie czcionki - pytam od strony warsztatu. Szukasz gotowych w sieci, używasz wyobraźni, czy kartki papieru?

    A propos, chyba nie masz znaków (cyfr) podwójnej i poczwórnej wysokości w bibliotece? To jest przydatne :) .


    No i przy okazji pytanie do publiki. HD44780 ma tylko 8pól cgram, "drugą" ósemkę adresów traktuje jako pierwszą i nadpisuje sobie. Pamiętam, że znalazłem kiedyś w sieci info że można jakoś "oszukać" kontroler i w któreś (które?) miejsce pamięci wrzucić kolejne 8znaków, i mieć łącznie 16znaków - mnie się to jednak nigdy nie udało, nie mogę obecnie odkopać w sieci tej informacji powtórnie, więc tymczasem to miejska legenda. Czy ktoś coś wie i może się podzielić informacją :) ?
    8znaków to niestety mało, gdyby ktoś chciał naprawdę zażółcić gęślą jaźń :P ...

    Pozdrawiam wesołoświątecznie.
  • #33
    yogib
    Poziom 12  
    Mam pytanko. Okroiłem przykładowy program tak aby tylko wyświetlał na LCD napis [TEST]:

    Code:
    int main()
    
    {
            const char *p;

            hd44780_init();

            p = PSTR("[TEST]");
            hd44780_goto(0, 0);
            hd44780_putPStr(p, -1);

            return 0;
    }


    Po skompilowniu otrzymałem kod wynikowy:

    Cytat:
    avr-size hd44780-example
    text data bss dec hex filename
    1604 0 2 1606 646 hd44780-example


    Pytanie: dlaczego kod wynikowy jest tak duży. Da się to jakoś "skurczyć"? Przy użyciu innej biblioteki otrzymuje kod w granicach 0,5k.
  • #34
    Tomkiewicz
    Poziom 13  
    Ekspandery to całkiem osobny element biblioteki, na chwilę obecną nie związany. Myślałem o wykorzystaniu ich właśnie przy lcd, ale chyba skupię się na innym rozwiązaniu - zamiast ekspanderów użycie jakiegoś możliwie małego ATTiny i komunikacja po i2c.

    W sprawie litery ź - wspomniałem o tym w dokumentacji dotyczącej polskiego zestawu znaków - po prostu jej nie ma. Zamiast ź jest wyświetlane ż. Czcionki narysowałem w GIMPie, a potem za pomocą kalkulatora (polecam KCalc z włączoną opcją wyklikiwania bitów) przeliczyłem je na liczby.

    Znaki zwiększonej wielkości jakoś mi nie przypadły do gustu, wolę po prostu użyć wyświetlacza graficznego. Może kiedyś, jak będzie zapotrzebowanie...

    Jak będę miał więcej czasu (taa ;)), spróbuję przeskanować pamięć tego kontrolera (przy użyciu linii RW można czytać, co się chce - właśnie tak zrobiłem to przewijanie ekranu), może coś ciekawego uda się stamtąd wydusić.

    @yogib: to jest właściwie niedopowiedzenie w dokumentacji. W przykładowym projekcie w pliku makefile są dodane opcje
    Code:
    -Wl,-u,vfprintf -lprintf_min

    podmienia ona implementację printf na oszczędniejszą, ale skoro go nie używasz, to jest dodawana niepotrzebnie. Wystarczy usunąć po prostu te dwa przełączniki (później uzupełnię opis w dokumentacji).

    Podany proram powinien - w zależności od wyświetlacza - zająć 440 - 600 bajtów.
  • #35
    yogib
    Poziom 12  
    Tomkiewicz napisał:

    Podany proram powinien - w zależności od wyświetlacza - zająć 440 - 600 bajtów.


    Dzięki, jest lepiej :)

    Cytat:
    avr-size hd44780-example
    text data bss dec hex filename
    618 0 2 620 26c hd44780-example


    Mam nadzieję, że nie zniechęcisz się szybko i rozbudujesz swoją bibliotekę czego serdecznie Ci życzę.
  • #36
    PO.
    Poziom 20  
    >@ekspandery:
    u mnie chodzi w miarę kompletnie - mam "niekulturalnie" deklarowaną bibliotekę w postaci każdego pliku osobno, w ten sposób wybieram jaki chcę interfejs, większość funkcji jest wyższego poziomu a funkcje sprzętowe mają zunifikowane nazwy.
    Jednakże też się zastanawiam nad zrobieniem dedykowanego kontrolera, jest nawet taki projekt na sieci. Możnaby wrzucić dodatkowe funkcje :) poza standardem. Choć najbardziej boli brak większego generatora znaków (ale możnaby zrobić dynamiczny bez obciążania mastera), regulację kontrastu i jasności bez zajmowania na stałe magistrali (co i tak kuleje), itp...

    >@ź:
    Przede wszystkim zmień przykład ;) .
    Poza tym podpowiem Ci że jest wersja tego kontrolera (romcode A02) która ma litery ó i Ó w standardzie pod kodami ascii, czyli
    //Ó 0xd3
    //ó 0xf3
    można więc jako opcję przestawianą mieć zamiennie ó np z ź (niestety jest sporo kontrolerów z innymi romami u nas).
    No i jest jeszcze opcja z dynamicznym generatorem, tylko to zasobożerne będzie więc chyba tylko do osobnego kontrolera...

    >@podwójne cyfry itd:
    Może nie zawsze jest superładne ale wszelkie zegarki, termometry itp do odczytywania z dalszej odległości tego potrzebują. Mnie tam ganz egal ;) .

    Szkoda że wszystkie wyświetlacze graficzne mają co najmniej jedną z poniższych wad, bo stare poczciwe hd czasami nie wystarcza... A graficzne:
    - mają inne proporcje
    - cena
    - standardowość / dostępność długofalowa?



    PS: właśnie mnie przypiliło i przerobiłem moją bibliotekę pod kątem polskich znaków wyświetlanych dynamicznie :) . Programik testowy, z obsługą i2c (lcd wisi), czytaniem stringa z eepromu, tablicami czcionek wielkich i małych liter, no i oczywiście dynamicznym wyświetlaniem zajmuje jakieś 6kB czyli da się przeżyć :D - jak wyłączę optymalizację to ~13,5kB.
    Testów na szybkość nie robiłem, na razie i tak są delaye testowe w kodzie. Takie wątki naprawdę motywują...
  • #37
    Tomkiewicz
    Poziom 13  
    Co masz na myśli, pisząc "dynamiczny generator znaków"? Chodzi o automatyczne wczytywanie polskich fontów, w razie potrzeby? Jak już wcześniej pisałem, takie rozwiązanie nie przypada mi za bardzo do gustu. Za to regulacja kontrastu to fajny pomysł.

    Mam zamiar wykorzystać ATTiny26, która posiada 16 IO - wystarczy na komunikację 8bit z RW, dwie linie E, komunikację po i2c i płynną regulację podświetlenia (ADC + tranzystor będzie OK?) oraz kontrastu (tu chyba wystarczy samo ADC, bez tranzystora?). Będzie trzeba zająć reset, ale chcę ten układ tak zaprojektować, żeby po jednorazowym zaprogramowaniu konfiguracja przebiegała w całości po i2c. Większość z 128 bajtów ramu wykorzystam jako bufor (żeby główny proc nie musiał czekać na LCD), a eeprom może na jakieś predefiniowane ciągi tekstowe? Tylko czy dla tych 128 bajtów zaoszczędzonych we flashu głównego proca gra będzie warta świeczki...

    Co do kwestii z literą ź - moim zdaniem właśnie przykład jest dobry - user od razu zobaczy, że zamiast ź dostanie ż. O literze ó wiedziałem, ale niestety u nas zdecydowanie przeważają kontrolery japońskie (z 4 lcd, które kupiłem, żaden nie jest europejski). W związku z tym nie widzi mi się rozważanie takiego mało uniwersalnego rozwiązania.
  • #38
    PO.
    Poziom 20  
    Hehe, z tą uniwersalnością to jeden woli brunetki a drugi blondynki :) - a moje też jest uniwersalne tylko inaczej. Ale ludzie muszą się różnić, żeby było ciekawie ;) .

    Już Ci piszę jak to mam u siebie. Mój generator dynamiczny jest w tej chwili dla polskich znaków ale bezboleśnie może (dosłownie) używać dowolnych znaków, czy wstawiać automatycznie ikonki, zmieniając tylko tablicę fontów. Tablica fontów jest dwuwymiarowa, z tym że na każdy font przypada nie 8 ale 9bajtów - 9bajt to kod znaku który ten font zastępuje.
    Dalej jest już z górki: przy każdym znaku program trzepie ostatnie komórki fontów i jeśli znajdzie to zagląda do drugiej tablicy z aktualną zawartością cgram (tu na szczęśćie tylko 8x1) - jeśli znajduje to wyświetla z cgram a jeśli nie to wrzuca font do najdawniej używanej pozycji cgram (jest zmienna, która tego pilnuje) oraz kod podmienianego fontu do mirrora cgram.
    Wady? Przede wszystkim procek musi trochę przemielić, a poza tym to dalej tylko 8 różnych znaków (w zakresie 8 dowolnie dużo) - więc jak ktoś lubi szaleć to musi się ograniczać przy pisaniu komunikatów i innych bajerów do lcd.

    PS: 8 znaków to również mało, żeby zrobić czytelne i ładne jednocześnie fonty cyfr podwójnej wysokości (bylejakie można) - o literach w ogóle możemy zapomnieć...

    Również u mnie zażółcić gęślej jaźni się nie da, bo ń wskoczy na ż. Ale za to zaszalałem i mam zarówno małe jak i WIELKIE litery (a propos, czy wszystkich polskich da się użyć jako wielkie? Wyraz na Ń na przykład?).

    Co do obciążenia to właśnie dlatego też widzę przeniesienie całości - tylko ja nie do tiny26 a do mega8, żeby starczyło na fonty i na rozwijanie programu :) . Główny procek będzie wtedy tylko wysyłał stringa...

    No i pod tym kątem odpowiedź na Twoje pytanie, też pytaniem: po co Ci ADC? Chcesz z jakiegoś fototranzystora odczytywać jasność otoczenia i automatycznie kontrast regulować :) ? I dla jasności i dla kontrastu PWM (strzelam że Tobie też o to chodziło) - wartości startowe z eepromu, graniczne dla konkretnych wyświetlaczy też można w eeprom wrzucić, żeby klient nie przejechał i cały czas coś widział.
    Jak dla mnie eeprom to przede wszystkim (zawsze) ustawienia, czyli:
    adres i2c, wymiary wyświetlacza, te kontrasty ;) , mogą być ustawienia trybów działania - w stylu kilka tablic fontów do wyboru, włączanie (nie)podmieniania "ó" itp. Reszta raczej wolna a same fonty do flasha wrzucać (po to mega8 - obecny koszt średnio 4zł na allegro, więc nie ma co się zabijać).
  • #39
    Janusz_kk
    Poziom 20  
    Tomkiewicz napisał:
    Właśnie udostępniłem wersję 1.0.1 biblioteki, w której większość sugestii zostało zrealizowanych. Jeżeli widzicie pod adresem tAvrLib.wasilczyk.pl starą wersję - proszę spróbować ctrl + F5.
    .


    Witam
    Fajnie że udostępniłeś ale twoja strona każe sobie płacić za ściągnięcie.
    Możesz to dać tutaj na elektrode?

    janusz
  • #40
    przemcio-tst
    Poziom 10  
    Witam, temat widzę leciwy, ale pytanie na czasie:

    dlaczego avrStudio + WinAVR najnowsze nie chcą mi skompilować i wywalają error na ten kawałek kodu:

    Code:

    FILE _hd44780_stream;


    dziwne, że nikt wcześniej tego nie zauważył, ale typ FILE nie jest nigdzie zdefiniowany...
  • #41
    Tomkiewicz
    Poziom 13  
    Biblioteka jest pisana pod avr-gcc (pod linuxem). Być może WinAVR nie definiuje tego typu.