Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

pobieranie danych z tablicy, ASM

Ch.M. 09 Mar 2007 09:45 1825 8
  • #1 09 Mar 2007 09:45
    Ch.M.
    Poziom 27  

    Witam
    Czy ktoś mi mógłby pomóc z napisaniem takiej procedurki:
    - mam zakodowane trzcionki w nastepujacy sposób:
    1-wszy bajt: liczba "n" bajtów opisujących znak
    2-gi do "n+1" bajt: dane do przerobienia bajt po bajcie by je móc wyświetlić
    - chcę pobierac z tablicy (kodujące dany znak) najpierw informację o długości kodu (liczba bajtów) a następnie bajt po bajcie dane wykonując na nich cyklicznie procedury wyświetlające dane znaki (piksele) na LCD

    jakiego typu powinna być tablica?
    .dw ?

    A: .db 18,0,2,6,28,60,88,16,63,127,68,136,176,65,129,3,7,4,8
    .
    .
    .
    W: .db 26,0,0,34,64,4,136,128,59,80,5,58,96,55,68,4,8,24,48,1,52,128,7,112,0,12,128

    czy może inny sposób na zapis danych byłby dogodniejszy w ich przetwarzaniu?

    Prosiłbym o kodzik z opisem jeśli można :)

    0 8
  • #2 09 Mar 2007 10:58
    Dar.El
    Poziom 40  

    Witam
    To mają być fonty o jednakowej ilości bajtów na znak, czy o różnej? Jeśli o jednakowej to nie trzeba podawać ilości bajtów na znak na początku, ponieważ jest to stała wartość. Do adresu tablicy tych fontów trzeba dodać nr. ASCII znaku pomnożonego przez zajętość bajtów na znak i masz adres do odczytu znaku.
    Ale jeżeli Ty chcesz korzystać z fontów o zmiennej długości, to życzę szczęścia z twoją umiejętnością programowania :D .

    0
  • #3 09 Mar 2007 11:23
    Ch.M.
    Poziom 27  

    A dziękuje za życzenia ;-)
    Zmienna szerokośc; już doszedłem jak działa instrukcja lpm, jednak niemam nic przeciwko jeśli ktoś chce się podzielić swoją wiedzą i jakimiś sztuczkami przyśpieszającymi odczyt

    0
  • #4 09 Mar 2007 11:39
    Dar.El
    Poziom 40  

    Duża szybkość przesyłania danych do wyświetlacza nie jest potrzebna a nawet szkodliwa. Wyświetlacze LCD na ogół nie są zbyt szybkie, ja musiałem wstawić dużo NOPów dla prawidłowego działania.

    0
  • #5 09 Mar 2007 11:44
    Ch.M.
    Poziom 27  

    Ehh no odobra jeśli Cie interesuje mój priojekt to część dotycząca wyświetlacza znajduje się tu:
    https://www.elektroda.pl/rtvforum/topic710497.html
    Wyświetlacz może się komunikować po SPI z prędkością nawet 13MHz i nawet więcej (ta jest nominalna w telefonach)
    Odczyt i przeróbka kodu znaku zajmie niestety sporo czasu kontrolera, temu che je przyśpieszyć maksymalnie, bo yrysowanie kilkudziesięciu znaczków może mi zając więcej czasu niźli bym chciał :/
    W tej chwili procek pracuje z prędkością 8MHz a SPI 4MHz, ale jeśli okarze się to za mało to można go rozpędzić do 16 czy 24MHz

    0
  • #6 09 Mar 2007 11:53
    Dar.El
    Poziom 40  

    Czyżbyś chciał zrobić animację na fontach? Samo przesłanie bajtu do wyświetlacza po SPI zajmie 2µs a w tym czasie mikrokontroler wykona od 8 do 16 instrukcji. Pobranie bajtu z pamięci z post inkrementacją ze sprawdzeniem końca pobierania powinno zmieścić się w tym czasie.

    0
  • #7 09 Mar 2007 12:12
    Ch.M.
    Poziom 27  

    Przeslanie fonta zajmie dużo więcej (polega na kolorowaniu pojedyńczych pikseli 16bit barwa) bo powiedzmy litera A zawiera 18bajtów gdzie kazdy bit oznacza kolor piksela np. niebieski lub różowy; liczba bajtów wyniesie więc 2bajty(kod koloru)x18bajtówX8(kazdy bit to piksel w kolorze tła lub litery)=288bajtów informacji dla fonta o wymiarach pikseli 16x9. Nie wliczam bajtów potrzebnych przy komunikacji SPI bo na pewno są jakieś sterujące informacje. 288bajtów informacji razy czas przesyłu jednego bajta (przy SPI 4MHz =2us) wyniesie więc 576us/znak. niby szybko ale jesli ukontroler musi jeszcze pare innych rzeczy robic (3xTWI, 3xADC, obliczenia, przyciski....) to zacznie nam spowalniać zbytnio :) Juz nie mowie o większych animacjach, ani o pogrubianiu trzcionki...
    Pozdrawiam

    0
  • #8 09 Mar 2007 14:10
    Dar.El
    Poziom 40  

    Podnieś na maksa taktowanie mikrokontrolera, żeby można było uzyskać jak największą transmisję SPI. Żeby osiągnąć zadowalające efekty z grafiką o 65000 kolorów potrzeba ARMa a nie AVRa i dużo pamięci na dane graficzne.

    0
  • #9 09 Mar 2007 14:49
    Ch.M.
    Poziom 27  

    Będzie dobrze i na AVR, komunikatów nie musze duzo wyświetlać ani prędko, jeśli nawet będzie rysować 0,5s to nikomu krzywda się nie stanie :) Szczególnie, że dane i tak nie będą sie zbyt prędko zmieniać
    Dzięki za zainteresowanie

    0
TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo