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

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?

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???

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.

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.

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.

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:





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.

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

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.

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.

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.

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.

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.

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.



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.

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ć.

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).

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.

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ć.).

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:



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]:

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?

Wyświetlacz to 320x240x2 (kolor 16 bit), = 153600 bajtów. Na procesorze f103 (72MHz) przesłanie pełnego obrazu to < 0.2sek. Na f407 (168MHz) będzie ze dwa razy szybciej. na pewno jest to kilkanaście obrazów/sek. ale dokładnie nie mierzyłem.

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.

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).

Jak to działa możesz zobaczyć od razu na dwóch:)
http://www.youtube.com/watch?v=wxJpWRPKe-g

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

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

jedrunia wrote:

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

No tak, to by się zgadzało, dla tej większej prędkości wychodzi ok. 50ns, stąd problemy z odbiorem, dziękuję.

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

Już wszystko jest ok.