Elektroda.pl
Elektroda.pl
X

Search our partners

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

[STM32] - SPI z TFT ILI9341 i STM32F103, STM32F407

dziechu 01 Jul 2014 20:35 8877 57
  • #31
    tadzik85
    Level 38  
    dziechu wrote:
    atom1477 napisał:
    No jak dla mnie to każda operacja na SPI to jest jednocześnie zapis i odczyt.

    Zapis to zapis, odczyt to odczyt. To że sprzętowo odbywa się to jednocześnie, nie znaczy że korzystając z komunikacji jednokierunkowej, trzeba bezwzględnie odczytywać rejestr DR. Najlepszym tego przykładem jest to, że tak mam zrobioną właśnie komunikację, i dzięki pozbyciu się rozkazu odczytu DR przy każdym bajcie, jest szybsza. W zasadzie do niczego mi ta komunikacja zwrotna nie jest potrzebna, bo przecież nie muszę odczytywać ID wyświetlacza, ani stanu rejestrów które sam ustawiłem. Ale meczę ten temat dla zasady, żeby poznać i kontrolować SPI - na przyszłość chociażby. Jeżeli używa się komunikacji dwukierunkowej, to owszem - zapis jest jednocześnie odczytem i nie ma po prostu sensu ich rozdział. Przy komunikacji jednokierunkowej jest tylko zapis - odczytu nie ma.


    Faktycznie wiele na tym tracisz. szczególnie w trybie pollingu no masakrycznie. Wysyłanie całego bajtu czekasz na flagę i zbawi cię jeden odczyt w tym czasie?
  • #32
    dziechu
    Level 27  
    tadzik85 wrote:
    Wysyłanie całego bajtu czekasz na flagę i zbawi cię jeden odczyt w tym czasie?

    W urządzeniach w których korzystam z tych wyświetlaczy, nawet nie mam podłączonej linii MISO. Jasne że nie zbawi mnie ten jeden odczyt, tylko po co mam go robic? Dla zasady(zresztą niesłusznej)? Jeżeli tylko wysylam dane, to interesuje mnie wyłącznie bit TXE, żeby wrzucić następny bajt. A Ty w takiej komunikacji odczytujesz DR???
  • #33
    tadzik85
    Level 38  
    dziechu wrote:
    tadzik85 wrote:
    Wysyłanie całego bajtu czekasz na flagę i zbawi cię jeden odczyt w tym czasie?

    W urządzeniach w których korzystam z tych wyświetlaczy, nawet nie mam podłączonej linii MISO. Jasne że nie zbawi mnie ten jeden odczyt, tylko po co mam go robic? Dla zasady(zresztą niesłusznej)? Jeżeli tylko wysylam dane, to interesuje mnie wyłącznie bit TXE, żeby wrzucić następny bajt. A Ty w takiej komunikacji odczytujesz DR???


    Dla jednolitego interfejsu.
    Dla zasady.
    Dla poprawności.

    Dlatego ze po raz 30-sty nad tym debatuję się tu.
  • #34
    dziechu
    Level 27  
    tadzik85 wrote:
    Dla jednolitego interfejsu.

    Nie wydaje mi się że można zrobić uniwersalny interfejs dla wszystkich zastosowań. Wolę dopasowywać rozwiązania do każdej sytuacji optymalnie.
    tadzik85 wrote:
    Dla zasady.

    Jeżeli jest to zasada, to niesłuszna. (kto tworzy takie zasady?)
    tadzik85 wrote:
    Dla poprawności.

    Czego? Interfejs jednokierunkowy bez odczytu działa poprawnie. Dla zwykłej ciekawości chciałem uruchomić komunikację zwrotną - stąd temat.
    tadzik85 wrote:
    Dlatego ze po raz 30-sty nad tym debatuję się tu.

    Ja chyba po raz 30 czytam te debaty i trudno mi się zgodzić z niektórymi tezami, jak - "robi się tak a tak dla zasady i poprawności", jeżeli nie idą za tym żadne bardziej racjonalne argumenty.

    Dodano po 16 [minuty]:

    Dodam jeszcze tak - funkcja samego zapisu jest prostsza, nie zwraca żadnego argumentu, a więc mniej obciąża zasoby procesora, nie odczytuje rejestru DR, więc jest tych kilka cykli zegara szybsza. Ktoś może napisać - No co za obciążanie, jeden bajt na stosie? I co za wolniejsza, o te kilka cykli? Zbawi cie ten jeden odczyt? Odpowiem tak - ja uczyłem się programowania, kiedy komputery miały 1kB RAMu i 16kB ROMu. Uczyłem się walczyć o każdy bajt i każdy cykl zegara. Teraz, przy 'nieograniczonych' zasobach (niby) nikt się nie przejmuje tym jednym bajtem czy niepotrzebnym rozkazem. Efekt jest taki, że programy sa pisane byle jak, niechlujnie. Mimo że komputery przez ostatnie 10 lat mają 100x więcej pamięci, są 100x szybsze, to oprogramowanie jest jedynie 2x szybsze i wydajniejsze. 80% przyrostu tych zasobów idzie na zwykłe ich marnotrawstwo.
  • #35
    tadzik85
    Level 38  
    dziechu wrote:
    Teraz, przy 'nieograniczonych' zasobach (niby) nikt się nie przejmuje tym jednym bajtem czy niepotrzebnym rozkazem. Efekt jest taki, że programy sa pisane byle jak, niechlujnie.


    Fanaberie. Niechlujne jest nieczytanie manuala. i tworzenie kwiatków dla każdego projektu.
    Nie bez kozery ustanowiono pewne standardy w programowaniu.

    Ale spieraj się dalej.

    Szczególnie ze już kilka osób obdarza cię dobrą rady a ty ciągle swoje. 3 tematy założyłeś a dotyczą tego samego.
  • #36
    dziechu
    Level 27  
    tadzik85 wrote:
    Niechlujne jest nieczytanie manuala.

    Zgadzam się. Ja czytam, jednak nie ma niestety manuala po polsku, a w szkole uczyłem się niestety rosyjskiego i kilka lat niemieckiego. Angielskiego nauczyłem się kilka lat temu, jednak nie jest to mój drugi język i sprawia mi kłopot przeczytanie i zrozumienie większego tekstu.

    tadzik85 wrote:
    i tworzenie kwiatków dla każdego projektu.

    Może stosujesz wszędzie te same funkcje metodą kopiuj-wklej. To tez jest niechlujstwo dość częste. Ale skoro tak wolisz... Ja dostosowuję program, funkcje i wykorzystanie peryferiów zależnie od zadania. Takie pisanie programów to nie tworzenie kwiatków ani fanaberie. Nie dałeś żadnego argumentu na konieczność czytania SPI zawsze, poza "bo tak się robi" "bo ustanowiono standarty", a to jest dopiero kwiatek. To może ja wolę tworzyć te standarty niż bezmyślnie się do nich stosować:)

    tadzik85 wrote:
    Szczególnie ze już kilka osób obdarza cię dobrą rady a ty ciągle swoje. 3 tematy założyłeś a dotyczą tego samego.

    Ale nie wiem co ma jedno z drugim wspólnego - w programie w którym staram się odczytać SPI i którego dotyczą tematy, funkcja zapisu jest funkcją odczytu - przecież wkleiłem kod:


    Code: c
    Log in, to see the code



    i moje twierdzenie że przy transmisji jednokierunkowej nie trzeba czytać rejestru DR nie dotyczą tych tematów - tu słucham rad i postępuję wg nich.
  • #37
    tadzik85
    Level 38  
    dziechu wrote:
    tadzik85 wrote:
    Niechlujne jest nieczytanie manuala.

    Zgadzam się. Ja czytam, jednak nie ma niestety manuala po polsku, a w szkole uczyłem się niestety rosyjskiego i kilka lat niemieckiego. Angielskiego nauczyłem się kilka lat temu, jednak nie jest to mój drugi język i sprawia mi kłopot przeczytanie i zrozumienie większego tekstu.

    tadzik85 wrote:
    i tworzenie kwiatków dla każdego projektu.

    Może stosujesz wszędzie te same funkcje metodą kopiuj-wklej. To tez jest niechlujstwo dość częste. Ale skoro tak wolisz... Ja dostosowuję program, funkcje i wykorzystanie peryferiów zależnie od zadania. Takie pisanie programów to nie tworzenie kwiatków ani fanaberie. Nie dałeś żadnego argumentu na konieczność czytania SPI zawsze, poza "bo tak się robi" "bo ustanowiono standarty", a to jest dopiero kwiatek. To może ja wolę tworzyć te standarty niż bezmyślnie się do nich stosować:)

    tadzik85 wrote:
    Szczególnie ze już kilka osób obdarza cię dobrą rady a ty ciągle swoje. 3 tematy założyłeś a dotyczą tego samego.

    Ale nie wiem co ma jedno z drugim wspólnego - w programie w którym staram się odczytać SPI i którego dotyczą tematy, funkcja zapisu jest funkcją odczytu - przecież wkleiłem kod:


    Code: c
    Log in, to see the code



    i moje twierdzenie że przy transmisji jednokierunkowej nie trzeba czytać rejestru DR nie dotyczą tych tematów - tu słucham rad i postępuję wg nich.


    ad1. po łatwiej jest przeportowac program? bo zamiast pisać takie banalne funkcje za każdym razem używam swojej biblioteki? Wstawiam plik i działa?

    Nie znajomość and w stopniu wystarczającym do zrozumienia dokumentacji nie jest usprawiedliwieniem.
    Standardy dla ciebie to kwiatek? no to facet daleko nie zajdziesz.

    A wklejona przez ciebie funkcja to kwiatek ze hohohoh
  • #38
    dziechu
    Level 27  
    tadzik85 wrote:
    Wstawiam plik i działa?

    No jak pisałem - kopiuj-wklej. Pewnie już nawet nie pamiętasz jak te funkcje wyglądają:) Gratulacje! A biblioteki? Własne? To już miałem jak jeszcze internetu w Polsce nie było, ale biblioteki nie służą wcale do bezmyślnego i bezkrytycznego stosowania zawsze i wszędzie - są dobre jako "szkielet" do dopracowania. No ale cóż - skoro większość programistów ma takie zdanie jak Ty, to co się dziwić że programy są wolne, że się wieszają, że aby wydrukować zdanie program musi mieć wielkość 475MB, no bo pisanie pod konkretny cel to fanaberie.

    tadzik85 wrote:
    Nie znajomość and w stopniu wystarczającym do zrozumienia dokumentacji nie jest usprawiedliwieniem.


    To powyżej też jest trudne do zrozumienia...

    tadzik85 wrote:
    Standardy dla ciebie to kwiatek? no to facet daleko nie zajdziesz.


    W moim wieku to już mogę pisać dokąd zaszedłem a nie gdzie zajdę:) Nie martw się, nie muszę pisać programów aby mieć na chleb, to robię bardziej hobbystycznie, co nie zmienia faktu że piszę programy za dużą kasę dla dużych firm, które zrezygnowały z usług wielu innych programistów stosujących się do zasad i reguł:) A oprócz programowania robię kilka zupełnie innych rzeczy za które dobrze mi płacą, dzięki czemu jak znudzi mi się jedno, mogę robić drugie albo trzecie.

    tadzik85 wrote:
    A wklejona przez ciebie funkcja to kwiatek ze hohohoh



    No widzisz, a jest na samym początku tematu, a Ty, zamiast napisać coś mądrego, chcesz mnie przekonywać do standardów, zasad i nie znając mnie zupełnie piszesz że daleko nie zajdę, co jest a co nie jest usprawiedliwieniem, jaki to ja jestem dupiaty programista a jaki Ty doświadczony, zaawansowany i w ogóle genialny... Więc napisz proszę coś w temacie, co pomoże pójść dalej (najpierw przeczytaj dokładnie co już było napisane), albo idź gdzie indziej pouczać tych co chcą słuchać takich mądrych rad, bo ja nie.
    Jeżeli chodzi o while(TXE_bb==0); to tylko dla przykładu, bo było tu już i RXNE_bb i BSY_bb.
  • #39
    tadzik85
    Level 38  
    dziechu wrote:
    tadzik85 napisał:
    Wstawiam plik i działa?

    No jak pisałem - kopiuj-wklej. Pewnie już nawet nie pamiętasz jak te funkcje wyglądają:) Gratulacje! A biblioteki? Własne? To już miałem jak jeszcze internetu w Polsce nie było, ale biblioteki nie służą wcale do bezmyślnego i bezkrytycznego stosowania zawsze i wszędzie - są dobre jako "szkielet" do dopracowania. No ale cóż - skoro większość programistów ma takie zdanie jak Ty, to co się dziwić że programy są wolne, że się wieszają, że aby wydrukować zdanie program musi mieć wielkość 475MB, no bo pisanie pod konkretny cel to fanaberie.


    Ty masz problem ja nie......

    A dywagować kolego z tobą skończyłem. Twoje argumentu przestały mnie bawić.

    Zresztą wystarczy cofnąć się kilka postów wstecz i doskonale widać kto stosuje metodę kopiuj wklej. I to nawet nie własnego dzieła.
  • #40
    dziechu
    Level 27  
    tadzik85 wrote:
    Ty masz problem ja nie......

    Mnie jednak się wydaje że Ty masz większy.... i to nie w temacie programowania.

    tadzik85 wrote:
    A dywagować kolego z tobą skończyłem. Twoje argumentu przestały mnie bawić.


    Przynajmniej mam jakieś argumenty....

    tadzik85 wrote:
    Zresztą wystarczy cofnąć się kilka postów wstecz i doskonale widać kto stosuje metodę kopiuj wklej. I to nawet nie własnego dzieła.


    A niby czyjego? Możesz sprecyzować? Bo to już zwykłe złośliwości, chyba z bezsilności.
  • #41
    tadzik85
    Level 38  
    dziechu wrote:
    tadzik85 wrote:
    Ty masz problem ja nie......

    Mnie jednak się wydaje że Ty masz większy.... i to nie w temacie programowania.

    tadzik85 wrote:
    A dywagować kolego z tobą skończyłem. Twoje argumentu przestały mnie bawić.


    Przynajmniej mam jakieś argumenty....

    tadzik85 wrote:
    Zresztą wystarczy cofnąć się kilka postów wstecz i doskonale widać kto stosuje metodę kopiuj wklej. I to nawet nie własnego dzieła.


    A niby czyjego? Możesz sprecyzować? Bo to już zwykłe złośliwości, chyba z bezsilności.


    Miej sobie i zachowaj dla siebie.....

    Owszem bezsilność bo marnujesz czas, nasz a o twój nie będę się martwił.

    Chcesz za każdym razem pisać wszystko od początku? Twoja sprawa. Ja na to nie mam czasu i wole poświecić się "wyższym celom".
    Niczego nie kopiuje jedynie dołączam właściwy plik dla właściwego procka do projektu.

    Od kilku dni tłum ludzi tłumaczy ci poprawną obsługę SPI, uparcie twierdzisz,że wiesz lepiej. To po co ten wątek?
    Znów cię za rączkę ciągnąc jak w poprzednim wątku? Gdzie nawet po podaniu właściwego pkt we właściwym dokumencie podanym linkiem nie mogłeś znaleźć odpowiedniej informacji?

    Więc co to za argumenty kolego? I do kogo ty chcesz je wygłaszać?


    Życzę powodzenia.
  • #42
    dziechu
    Level 27  
    tadzik85 wrote:
    Owszem bezsilność bo marnujesz czas, nasz

    Pisz w swoim imieniu, nie sugeruj tu że jestem sam a wszyscy pozostali są po twojej stronie.

    tadzik85 wrote:
    Niczego nie kopiuje jedynie dołączam właściwy plik dla właściwego procka do projektu.

    No tak, to zuuuupełnie cos innego niż kopiowanie....

    tadzik85 wrote:
    Od kilku dni tłum ludzi tłumaczy ci poprawną obsługę SPI


    Pewnie jakbyś przeczytał temat, zauważyłbyś że z nikim, poza Tobą, to się nie kłócę. Co więcej, słucham każdej sensownej porady i odpowiadam jakie są skutki zastosowania porady. Gdybyś zaproponował coś sensownego, też pewnie bym to zastosował, ale wolisz mi tu zawalać temat filozofią cwanego programisty.

    tadzik85 wrote:
    uparcie twierdzisz,że wiesz lepiej. To po co ten wątek?


    Już to raz napisałem - ale powtórzę, nie będę Cię odsyłał do szukania, bo pewnie Ci się nie chce - uważam że przy transmisji jednokierunkowej nie ma sensu czytać rejestru DR po każdym wysłaniu bajtu, i koniec. Bo to działa szybciej, bez problemu i stosowanie na siłę czytania tylko dla zasady, mimo że zwalnia obsługę wyświetlacza, to dobre chyba tylko dla skrajnego desperata w stosowaniu gotowców. Natomiast ten temat nie dotyczy transmisji jednokierunkowej, nikomu tu nie wmawiam że nie trzeba czytać DR po każdym wpisie (że jest to jedna funkcja). Problem o który się spieramy nie dotyczy tego tematu. Przeczytaj to powoli, zrozum i zapamiętaj.
  • #43
    dziechu
    Level 27  
    Dołączam następne zrzuty analizatora stanów. Rozkaz RDDPM (0x0A). Jak widać w drugim odbieranym bajcie (a więc tym właściwym) pojawiają się nieprawidłowe szpilki. Podobnie przy innych rozkazach, szpilki pojawiają się zawsze w ostatnim odbieranym bajcie.

    [STM32] - SPI z TFT ILI9341 i STM32F103, STM32F407

    Ale zauważyłem coś innego w dokumentacji. Na stronie 94 dokumentu ILI9341 jest opisane to tak - wysłanie bajtu rozkazu, odebranie pierwszego bajtu nieznaczącego (dummy), odebranie drugiego właściwego. Podobnie opisane są inne rozkazy odbierające np. cztery znaczące bajty itp. Zawsze pierwszy jest dummy. Z kolei na stronie 38 opisane są protokoły dla 4 wire serial protocol dla wymienionych wyżej rozkazów i tam nie ma żadnych bajtów nieznaczących (dummy), znaczący jest od razu pierwszy bajt odebrany po rozkazie (wcześniej tego nie zauważyłem, skupiłem się na samym przebiegu sygnałów). Więc prawdopodobnie nieznaczące pierwsze bajty po rozkazie nie dotyczą magistrali 4 wire, a pojawiające się szpilki to bajty "nadmiarowe", które nie powinny być odbierane? Warto problem rozwiązać, bo te wyświetlacze są na prawdę bardzo fajne, bardzo dobrej jakości, bardzo tanie i stają się coraz bardziej popularne, więc pewnie wielu będzie z nich korzystać, i komunikacja będzie już opanowana - do wglądu dla wszystkich.
  • #44
    Jado_one
    Level 22  
    [STM32] - SPI z TFT ILI9341 i STM32F103, STM32F407

    Jakoś dziwnie wygląda sprawa linii D/CX - wygląda na to, że podczas ostatniego bitu rozkazu powinna nastąpić zmiana tej linii na stan przeciwny - przez czas trwania jednego clock'a.
    Albo tak dziwnie to narysowali.

    A szukałeś jakiś bibliotek do tego wyświetlacza w sieci? Może ktoś już to rozpracował - warto byłoby podejrzeć.
  • #45
    dziechu
    Level 27  
    Nie no to byłoby bez sensu - jak zsynchronizować sygnał spoza SPI z ostatnim cyklem zegara SPI? To raczej pokazuje że linia DC jest czytana w ostatnim cyklu zegarowym i w tym czasie musi być odpowiednio ustawiona - w tym wypadku na 0.

    Są jakieś biblioteki na Arduino, ale nie znalazłem konkretnych funkcji dla SPI. Za to skorzystałem z ciągu rozkazów inicjalizujących.

    Dodano po 2 [minuty]:

    Z kolei przy odczycie (drugi bajt) linia DC powinna być ustawiona na 1, a nie dowolnie, jak na rys. Albo też w tym trybie nie ma znaczenia stan DC przy odbieranym bajcie (proc wyświetlacza wie po rozkazie co ma robić i nie sprawdza DC).
  • #46
    Jado_one
    Level 22  
    No to jeśli powinieneś czytać 2 a nie 3 bajty - bo 'dummy byte niet', to sprawdź, czy to co odczytujesz ma sens i będzie wiadomo jak powinna wyglądać prawidłowa komunikacja po 4-wire SPI z tym wyświetlaczem :-)

    BTW: Ustaw sobie SPI analyzer w programie Saleae Logic, to będziesz wiedział jakie bajty Ci wchodzą/wychodzą przez SPI.
  • #47
    atom1477
    Level 43  
    dziechu wrote:
    Ale zauważyłem coś innego w dokumentacji. Na stronie 94 dokumentu ILI9341 jest opisane to tak - wysłanie bajtu rozkazu, odebranie pierwszego bajtu nieznaczącego (dummy), odebranie drugiego właściwego. Podobnie opisane są inne rozkazy odbierające np. cztery znaczące bajty itp. Zawsze pierwszy jest dummy. Z kolei na stronie 38 opisane są protokoły dla 4 wire serial protocol dla wymienionych wyżej rozkazów i tam nie ma żadnych bajtów nieznaczących (dummy), znaczący jest od razu pierwszy bajt odebrany po rozkazie (wcześniej tego nie zauważyłem, skupiłem się na samym przebiegu sygnałów). Więc prawdopodobnie nieznaczące pierwsze bajty po rozkazie nie dotyczą magistrali 4 wire, a pojawiające się szpilki to bajty "nadmiarowe", które nie powinny być odbierane?

    Raczej nie. To raczej niechlujstwo tego kto pisał datasheeta, bo w tej samej kolumnie rozpisał bajty nadawanie i odbierane. A jakoś musiał rozdzielić wysyłaną komendę od odbieranego bajtu Dummy (mógł to wpisać w jednej komórce i to by było bardziej jasne, ale widać nie pomyślał).
    Nie mniej jednak tak właśnie jest: czyli że nadawana komenda i odbierany pierwszy bajt (Dummy) to powinna być jedna komórka bo są transmitowane w tym samy czasie (Nawet przy magistrali 3-wire tyle że wtedy zamiast Dummy odebrali byśmy nadaną przez nas komendę. Różnicy to wielkiej jednak nie robi, bo ten bajt i tak trzeba by odrzucić.).
  • #48
    dziechu
    Level 27  
    Ok. Teraz będę sprawdzał sensowność odbieranych danych i dam znać jak to wygląda. Już wcześniej nie zastanawiało, że pierwszy odbierany bajt, czyli ten 'dummy', zawsze miał konkretną wartość i zawsze taką samą, a nie przypadkową, czy np. same 0 lub 1.

    Dodano po 26 [minuty]:

    Wygląda że jest to sensowne. Przy rozkazach po których jest odbierany jeden bajt, procedura jest normalna. Przy rozkazach gdzie odbierane są cztery bajty, po bajcie rozkazu musi być wstawiony dodatkowy jeden cykl zegara:

    Code: c
    Log in, to see the code


    Dodano po 12 [minuty]:

    Jado_one wrote:
    Ustaw sobie SPI analyzer w programie Saleae Logic, to będziesz wiedział jakie bajty Ci wchodzą/wychodzą przez SPI

    Nie działa to w trybie z dodatkowym cyklem zegarowym - ten impuls 'rozwala' mu analizę SPI.

    Dodano po 1 [minuty]:

    [STM32] - SPI z TFT ILI9341 i STM32F103, STM32F407
  • #49
    Jado_one
    Level 22  
    No, tak - w tym przypadku to nie będzie działać (chyba, żeby podawać mu przed każdym bajtem, żeby od niego zaczynał analizę - ale to upierdliwe).

    Tak przy okazji - skoro o szybkości mowa - ile czasu trwa przesłanie jednego pełnego obrazu do tego wyświetlacza? I ile to będzie bajtów?
  • #51
    dziechu
    Level 27  
    Zrobiłem dokładne pomiary - 100 przeładowań pełnego ekranu i pomiar timerem. Najkrótszy czas przesyłu 154kB to 0.0608 sek. To najwyższa prędkość SPI1 dla taktowania 72MHz. Wyświetlacz pracuje stabilnie i godzinami przeładowuje się bez błędu. Jednak jest to prędkość SPI zbyt duża dla transmisji dwukierunkowej, pracuje dobrze tylko w transmisji do wyświetlacza (ja takiej głównie używam). Przy odbiorze danych pojawiają się błędy. Najwyższą prędkość stabilną dla transmisji dwukierunkowej, udaje się uzyskać przy ustawieniu BR = 001 (dla 72MHz). Wtedy czas przeładowania wychodzi 0.0811 sek.
    Zrobię podobne testy na F407 z 168MHz.
  • #52
    Jado_one
    Level 22  
    No to nieźle :-)
    Aczkolwiek, to pokazuje mi, że chyba musiałbym korzystać z oddzielnego SPI, gdybym chciał użyć tego wyświetlacza (mam inną transmisję po SPI, która odbywa się co 5,6ms).
  • #54
    Jado_one
    Level 22  
    No nieźle - sam mam jedno RPi wolne, które leży wyłączone.
    Z takim ekranikiem, to by mogło robić za jakiś sprytny sterownik non-stop-on.

    Za dużo qrcze możliwości do wyboru, a za mało czasu :-))

    Właśnie mam zamiar zrobić płytkę dev dla nowego PIC32MX795F512L, potem przeportować na niego kod (może pójdzie bez większych problemów), w kolejce jeszcze kilka płytek z różnymi scalakami do oprogramowania.
    Chyba dopiszę i do tej listy ten wyświetlacz ;-)
  • #55
    jedrunia
    Level 2  
    Witam,

    Różnica prędkości nadawania i odbioru dla tego wyświetlacza zawarta jest w nocie katalogowej, strona 242, 18.3.3 Display Serial Inteface Timing....

    Dla nadawania minimalny stan wysoki/niski zegara to 40ns dla odczytu to 60ns


    pozdrawiam
    Andrzej
  • #57
    jedrunia
    Level 2  
    Dokładniej to minimalny okres zegara wynosi 100ns dla nadawania i 150ns dla odbioru.

    Można z tego wyliczyć jaką teoretyczną max. częstotliwość odświeżania całego ekranu da się "wyciągnąć" przy danym trybie kodowania kolorów.

    Ja dziękuję za przetestowanie tego dodatkowego impulsu zegarowego między rozkazem a odbieranymi danymi - nie muszę sam sprawdzać :)

    Andrzej