sobota, 4 listopada 2023 o 22:31:52 UTC+1 heby napisał(a):

> Dlatego nie wykluczam pamięci w takim wyświetlaczu. Taka hybryda to nic
> specjalnie dziwnego, szczególnie jak faktycznie wejście jest TTL co
> sugeruje wpięcie w jakiś pradawny system o małej mocy pompowania danych.

Hmm, ale jaki sens miałoby jednoczesne:
- pamięć
oraz
- zewnętrzne hsync i vsync?

Jak jest pamięć to jest i sterownik, który sam sobie z tej pamięci czyta
i generuje sygnały akceptowane przez wyświetlacz - czy to CRT czy LCD.

A jak nie ma sterownika to co ma dać pamięć?

W tym 240*128 mono z T6369C były dwa rzędy pinów.
Jeden do komunikacji z T6963C, a drugi bezpośrednio
z driverami kolumn i rzędów - można było samemu robić za T6369C,
ale po co?

I jesteś chyba w dużym błędzie co do tego, czym jest RGBTTL.
To jest w prawie to samo co VGA, tylko z cyfrowymi sygnałami koloru
i dodanym zegarem, żeby monitor nie musiał zgadywać
na podstawie hsync i vsync.
Pompować zaś trzeba równie szybko.
Albo mieć pośrodku coś w stylu FT810, co samo popompuje.
W PCM-5820 pompowała karta graficzna, tak samo jak
w analogowe VGA, tylko bez DAC.
I więcej pinów, nie 15 a 40.

do góry

On 05/11/2023 01:38, Dawid Rutkowski wrote:
>> Dlatego nie wykluczam pamięci w takim wyświetlaczu. Taka hybryda to nic
>> specjalnie dziwnego, szczególnie jak faktycznie wejście jest TTL co
>> sugeruje wpięcie w jakiś pradawny system o małej mocy pompowania danych.
> Hmm, ale jaki sens miałoby jednoczesne:
> - pamięć
> oraz
> - zewnętrzne hsync i vsync?

Nie wiem, ale systemy w automatyce to często wyjątkowo przestarzałe
rozwiązania techniczne. Kompletnie nie zdzwiwłbym się, jak by po drugiej
stronie tego kolorowego wyświetlacza stał sobie Z80 w jakiejś
futurystycznej wersji.

Mała uwaga: prawie wszystkie wyświetlacze z hcync wcale nie musiały by
go mieć. Wszak po wsadzeniu x bitów do rejestru mógłby on automatycznie
zmienić wiersz.

A mają.

Dziwne, nie? Wyglada jak by ktoś chciał na siłe udawać że jest CRT.
Ciekawe dlaczego.

> A jak nie ma sterownika to co ma dać pamięć?

Aby nie trzeba było na gwałt wysyłać danych do wyświetlacza, mieszcząc
się w jakiś ramach czasowych jednej ramki obrazu albo wynikających z
obostrzeń kontrastu.

Ponadto, skąd wnuiosek, że nie ma *jakiegoś* sterownika, nawet customowego?

> I jesteś chyba w dużym błędzie co do tego, czym jest RGBTTL.

Nie ma to znaczenia, pytający nie użył takiej frazy, jak "RGBTTL".

Czekamy na dokumentację, zgadywanie nie ma sensu.

do góry

niedziela, 5 listopada 2023 o 11:25:56 UTC+1 heby napisał(a):
> On 05/11/2023 01:38, Dawid Rutkowski wrote:
> >> Dlatego nie wykluczam pamięci w takim wyświetlaczu. Taka hybryda to nic
> >> specjalnie dziwnego, szczególnie jak faktycznie wejście jest TTL co
> >> sugeruje wpięcie w jakiś pradawny system o małej mocy pompowania danych.
> > Hmm, ale jaki sens miałoby jednoczesne:
> > - pamięć
> > oraz
> > - zewnętrzne hsync i vsync?
> Nie wiem, ale systemy w automatyce to często wyjątkowo przestarzałe
> rozwiązania techniczne. Kompletnie nie zdzwiwłbym się, jak by po drugiej
> stronie tego kolorowego wyświetlacza stał sobie Z80 w jakiejś
> futurystycznej wersji.

A w czym jest gorszy Z80 od x86 czy ARM?

> Mała uwaga: prawie wszystkie wyświetlacze z hcync wcale nie musiały by
> go mieć. Wszak po wsadzeniu x bitów do rejestru mógłby on automatycznie
> zmienić wiersz.

Ale wtedy byłaby sztywna liczba pixeli w linii.
Jasne, że tak jest "najlepiej", ale czasem ktoś
chce mieć "lepiej co innego".

> A mają.
>
> Dziwne, nie? Wyglada jak by ktoś chciał na siłe udawać że jest CRT.
> Ciekawe dlaczego.

Dziwne?
Zakładałem, że oczywiste.
Kompatybilita przede wszystkim.
Gorzej, ale taniej iłatwiej.
Ale przede wszystkim możliwie.
Ostatnia udana rewolucja to październikowa niestety
(tzn. niestety że się ta udała, a nie niestety, że później już nie było).

Po co DVI ma blanking periods?
(Pomijając pytanie o DVI-A ;)
Ale się przydało w HDMI do transmisji dźwięku
(jak wcześniej do teletextu).

> > A jak nie ma sterownika to co ma dać pamięć?
> Aby nie trzeba było na gwałt wysyłać danych do wyświetlacza, mieszcząc
> się w jakiś ramach czasowych jednej ramki obrazu albo wynikających z
> obostrzeń kontrastu.
>
> Ponadto, skąd wnuiosek, że nie ma *jakiegoś* sterownika, nawet customowego?

Hmm, no dałeś do myślenia.
Rzeczywiście może być taki, co łapie do swojej pamięci obraz wysyłany po
RGBTTL, dowolnie powolnie, i sam potem wyświetla.

Ale to będzie mega wolnozmienne, bo nie ma szans innej zmiany obrazu
niż wymiana po całości.

> > I jesteś chyba w dużym błędzie co do tego, czym jest RGBTTL.
> Nie ma to znaczenia, pytający nie użył takiej frazy, jak "RGBTTL".

W moim intetnecie użył (hint: topic).

> Czekamy na dokumentację, zgadywanie nie ma sensu.

No coś jednak mozma osiągnąć
Póki co z kategoryczne nie przeszliśmy do
"Jak masz trampki Siemensa to tak" :>

do góry

On 5.11.2023 11:25, heby wrote:

>
> Czekamy na dokumentację, zgadywanie nie ma sensu.
>

https://www.digimax.it/media_import/DISPLAY/ROCKTECH
/TFT%20LCD/RK043HN01HS-T/RK043HN01HS-T_DS_001.pdf

--
Mirek.

do góry

On 05/11/2023 16:18, Dawid Rutkowski wrote:
>> Nie wiem, ale systemy w automatyce to często wyjątkowo przestarzałe
>> rozwiązania techniczne. Kompletnie nie zdzwiwłbym się, jak by po drugiej
>> stronie tego kolorowego wyświetlacza stał sobie Z80 w jakiejś
>> futurystycznej wersji.
> A w czym jest gorszy Z80 od x86 czy ARM?

Niczym, jesli wszystko co masz, to program napisany w asm przez
brodatego embedowca. Wtedy najzwyczajniej, nie masz wyboru.

Jam masz kod napisany w czymś przenośnym, to Z80 jest gorszy we wszystkim.

Ale zazwyczaj nie masz.

To jest np. powód, dla którego współczesne telefony dalej mają jakiegoś
kolna 8051 do obsługi GSM. Za dużo asemblera powoduje uzależnienie.

>> Mała uwaga: prawie wszystkie wyświetlacze z hcync wcale nie musiały by
>> go mieć. Wszak po wsadzeniu x bitów do rejestru mógłby on automatycznie
>> zmienić wiersz.
> Ale wtedy byłaby sztywna liczba pixeli w linii.

A są jakieś wyświetlacze z elastyczną ilościa pixeli w lini?

> Jasne, że tak jest "najlepiej", ale czasem ktoś
> chce mieć "lepiej co innego".

No i jak myślisz, dlaczego wobec tego dalej stosuje się, do dzisiaj,
HSYNC w LCD zamiast wstawić tam kilka przerzutników? Ogarnięcie tej
garstki tranzystorów powinno kosztować ćwierć centa.

>> Dziwne, nie? Wyglada jak by ktoś chciał na siłe udawać że jest CRT.
>> Ciekawe dlaczego.
> Dziwne?
> Zakładałem, że oczywiste.
> Kompatybilita przede wszystkim.

I tutaj dochodzimy do sedna: dlaczego czasami podpina się archaiczne
sterowniki do współczesnych wyświetlaczy.

Dlatego, mając na chwilę obecną, jakikolwiek wyświetlacz który *wygląda*
na bez pamięci, głowy bym nie dał.

> Po co DVI ma blanking periods?

Bo koszt zmiany myslenia, szczególnie w komitetach za zielonym suknem,
jest czasami równy zastępowalności pokoleniowej. Tu masz odpowiedź, po
co komu iface do LCD przypomianający jak żywo CRT.

Po prostu programatorzy embedded są niereformowalni, wiec nagina się
hardware do gównianego software i liczy na zmianę technologiczną wraz z
zapełnianiem cmentarzy.

> Hmm, no dałeś do myślenia.
> Rzeczywiście może być taki, co łapie do swojej pamięci obraz wysyłany po
> RGBTTL, dowolnie powolnie, i sam potem wyświetla.
> Ale to będzie mega wolnozmienne, bo nie ma szans innej zmiany obrazu
> niż wymiana po całości.

Widziałeś kiedyś jak działa odtwarzacz DVD powiedzmy z 200x roku? Ma
super szybkie pixele z MPEG2, ale niewiarygodnie wolne menu, które
wygląda jak by przesyłali je szeregowo (i chyba tak dokładnie jest).
Refresh ekranu to około 0.5sek.

I wiesz co? Suwerenowi nie przeszkadza.

Tym bardziej operatorowi tokarki.

do góry

On Sun, 5 Nov 2023 18:32:23 +0100, heby wrote:
> On 05/11/2023 16:18, Dawid Rutkowski wrote:
>>> Nie wiem, ale systemy w automatyce to często wyjątkowo przestarzałe
>>> rozwiązania techniczne. Kompletnie nie zdzwiwłbym się, jak by po drugiej
>>> stronie tego kolorowego wyświetlacza stał sobie Z80 w jakiejś
>>> futurystycznej wersji.
>> A w czym jest gorszy Z80 od x86 czy ARM?
>
> Niczym, jesli wszystko co masz, to program napisany w asm przez
> brodatego embedowca. Wtedy najzwyczajniej, nie masz wyboru.

Jak chcesz miec ethernet, internet, wyswietlacz graficzny,
usb, karty pamieci, bzy danych czy dostęp do nich - to duzo gorszyc.

> Jam masz kod napisany w czymś przenośnym, to Z80 jest gorszy we wszystkim.
> Ale zazwyczaj nie masz.
>
> To jest np. powód, dla którego współczesne telefony dalej mają jakiegoś
> kolna 8051 do obsługi GSM. Za dużo asemblera powoduje uzależnienie.

Mówisz?
Technologia sie rozwija, trzeba stale i program unowoczesniac.

>>> Mała uwaga: prawie wszystkie wyświetlacze z hcync wcale nie musiały by
>>> go mieć. Wszak po wsadzeniu x bitów do rejestru mógłby on automatycznie
>>> zmienić wiersz.
>> Ale wtedy byłaby sztywna liczba pixeli w linii.
>
> A są jakieś wyświetlacze z elastyczną ilościa pixeli w lini?

Wyswietlacze to moze nie, ale narobiło się, ze obslugujemy różne
formaty. i "wyswietlacz"/monitor/"ekran" sobie przetwarza..

>> Jasne, że tak jest "najlepiej", ale czasem ktoś
>> chce mieć "lepiej co innego".
>
> No i jak myślisz, dlaczego wobec tego dalej stosuje się, do dzisiaj,
> HSYNC w LCD zamiast wstawić tam kilka przerzutników? Ogarnięcie tej
> garstki tranzystorów powinno kosztować ćwierć centa.

Nawiasem mówiac - cos sie dzieje, i monitory to gier zdaje się
zyskały nieokresloną czestotliwośc pionową ..

>>> Dziwne, nie? Wyglada jak by ktoś chciał na siłe udawać że jest CRT.
>>> Ciekawe dlaczego.
>> Dziwne?
>> Zakładałem, że oczywiste.
>> Kompatybilita przede wszystkim.
>
> I tutaj dochodzimy do sedna: dlaczego czasami podpina się archaiczne
> sterowniki do współczesnych wyświetlaczy.
>
> Dlatego, mając na chwilę obecną, jakikolwiek wyświetlacz który *wygląda*
> na bez pamięci, głowy bym nie dał.

Ale oscylujemy w sprzęt embeded?
To ekran często jest jaki jest :-)

>> Po co DVI ma blanking periods?
> Bo koszt zmiany myslenia, szczególnie w komitetach za zielonym suknem,
> jest czasami równy zastępowalności pokoleniowej. Tu masz odpowiedź, po
> co komu iface do LCD przypomianający jak żywo CRT.

No ale DVI było troche uniwersalne. Analogowy sygnał też gdzieś tam
był.

>> Hmm, no dałeś do myślenia.
>> Rzeczywiście może być taki, co łapie do swojej pamięci obraz wysyłany po
>> RGBTTL, dowolnie powolnie, i sam potem wyświetla.
>> Ale to będzie mega wolnozmienne, bo nie ma szans innej zmiany obrazu
>> niż wymiana po całości.
>
> Widziałeś kiedyś jak działa odtwarzacz DVD powiedzmy z 200x roku? Ma
> super szybkie pixele z MPEG2, ale niewiarygodnie wolne menu, które
> wygląda jak by przesyłali je szeregowo (i chyba tak dokładnie jest).
> Refresh ekranu to około 0.5sek.
>
> I wiesz co? Suwerenowi nie przeszkadza.

Ale to jak rozumiem dlatego, ze sterownik wyswietlacza ma sprzetowy
dekoder MPEG i pomocniczy kanał OSD. Pomocniczy, wiec może być
powolny. Szczególnie, jak komus sie nie chce zrobic w assemblerze,
tylko wyciąga jakąs ambitną bibliotekę graficzną :-)

A wmiksowanie własnych tresci w MPEG ... o, to nie jest takie łatwe,
a wrecz niemozliwe dla Z80 :-)

> Tym bardziej operatorowi tokarki.

No to w czym problem ? Wszyscy sa zadowoleni.

J.

do góry

On 06/11/2023 16:02, J.F wrote:
>>> A w czym jest gorszy Z80 od x86 czy ARM?
>> Niczym, jesli wszystko co masz, to program napisany w asm przez
>> brodatego embedowca. Wtedy najzwyczajniej, nie masz wyboru.
> Jak chcesz miec ethernet, internet, wyswietlacz graficzny,
> usb, karty pamieci, bzy danych czy dostęp do nich - to duzo gorszyc.

Z przygód kolegi pracującego w firmie robiącej sterowanie: jesli chcesz
mieć *jakąkolwiek* zmianę, to soft nadaje się do przepisnia od nowa, tym
bardziej, że autor poprzedniej wersji właśnie łowi ryby na emeryturze.

Systemy oparte o Z80 to guano pisane niskopoziomowo. Ich się nie
rozwija, tylko łata. I tylko przez chwilę, zanim się rozlecą. To samo z
8051. Dodanie tutaj C niewiele pomaga, bo ludzie piszą w nim jak w
asemblerze, często nieprzenośnie.

>> Jam masz kod napisany w czymś przenośnym, to Z80 jest gorszy we wszystkim.
>> Ale zazwyczaj nie masz.
>> To jest np. powód, dla którego współczesne telefony dalej mają jakiegoś
>> kolna 8051 do obsługi GSM. Za dużo asemblera powoduje uzależnienie.
> Mówisz?
> Technologia sie rozwija, trzeba stale i program unowoczesniac.

O najszybszej furmance świata nie słyszałeś?

https://mlodytechnik.pl/news/10647-najszybszy-proces
or-na-swiecie-z-bytomia

Agrumentacja, nie pamiętam już gdzie zasłyszana, ale chyba od pracownika
firmy, była taka, że "8051 ciągle jest używane w modemach gsm".

Czyli, jesli czytać między wierszami, jakośc tego kodu jest poniżej
wszelkich metryk, skoro go jeszcze nie przepisali na cokolwiek innego.
Najwidocznie nie da się przepisać, bo sieczkę można co najwyżej
zaemulować albo dokładać gigazhertzów.

Innymi słowy, doczekałem czasów, kiedy hardware łata dziadowski
software. Nie, żeby nie było też czasem i w drugą stronę.

>>>> Mała uwaga: prawie wszystkie wyświetlacze z hcync wcale nie musiały by
>>>> go mieć. Wszak po wsadzeniu x bitów do rejestru mógłby on automatycznie
>>>> zmienić wiersz.
>>> Ale wtedy byłaby sztywna liczba pixeli w linii.
>> A są jakieś wyświetlacze z elastyczną ilościa pixeli w lini?
> Wyswietlacze to moze nie, ale narobiło się, ze obslugujemy różne
> formaty. i "wyswietlacz"/monitor/"ekran" sobie przetwarza..

To nie wyjasnia obecniści HSYNC we współczesnych wyświetlaczach, bo
problem rozmiaru jest w takim protokole wyłacznie softwareowy. A jednak
produkuje się je na potęgę.

>>> Po co DVI ma blanking periods?
>> Bo koszt zmiany myslenia, szczególnie w komitetach za zielonym suknem,
>> jest czasami równy zastępowalności pokoleniowej. Tu masz odpowiedź, po
>> co komu iface do LCD przypomianający jak żywo CRT.
> No ale DVI było troche uniwersalne. Analogowy sygnał też gdzieś tam
> był.

I kto mu bronił być i być generowany innym elementam hardware, innym
sterowaniem i w ogóle wszystkim innym?

DVI to taka hybryda, gdzie wartości analogowe zamieniono na cyfrowe, ale
"zapomniano" o całej masie innych zbędnych elementów.

To się tylko wyjaśnić brodaczami za zielonym suknem, zmiana myślenia
jest możliwa wyłacznie na poziomie zastepowalności pokoleń.

Jak już masz to wejscie cyfrowe i LCD, to po ch... komu blanking? ba, ja
bym się nawet zastanowiło po co komu wyścig z VSYNC. Taki iface powinien
na spokojnie przyjąc piksel na sekundę, jesli trzeba.

> Ale to jak rozumiem dlatego, ze sterownik wyswietlacza ma sprzetowy
> dekoder MPEG i pomocniczy kanał OSD. Pomocniczy, wiec może być
> powolny. Szczególnie, jak komus sie nie chce zrobic w assemblerze,
> tylko wyciąga jakąs ambitną bibliotekę graficzną :-)

I nikomu, poza mna, nie przeszkadzało. Lduzie mają naprawdę prymitywne
potrzeby.

>> Tym bardziej operatorowi tokarki.
> No to w czym problem ? Wszyscy sa zadowoleni.

W niczym. Taka moja konkluzja. Bez znaczenia jak żałosne i prymitywne
GUI dostarczasz. Przeciętny suweren nie jest w stanie odróznić dobrego
od złego. Nie ma potrzeby sterowania wyświetlaczem dla tokarza, czy
Krystyny @50Hz. Nie zauważą róznicy.

do góry

On Mon, 6 Nov 2023 16:33:27 +0100, heby wrote:
> On 06/11/2023 16:02, J.F wrote:
>>>> A w czym jest gorszy Z80 od x86 czy ARM?
>>> Niczym, jesli wszystko co masz, to program napisany w asm przez
>>> brodatego embedowca. Wtedy najzwyczajniej, nie masz wyboru.
>> Jak chcesz miec ethernet, internet, wyswietlacz graficzny,
>> usb, karty pamieci, bzy danych czy dostęp do nich - to duzo gorszyc.
>
> Z przygód kolegi pracującego w firmie robiącej sterowanie: jesli chcesz
> mieć *jakąkolwiek* zmianę, to soft nadaje się do przepisnia od nowa, tym
> bardziej, że autor poprzedniej wersji właśnie łowi ryby na emeryturze.

Nie mówie nie, ale czy "lepsze" rozwiązania sa naprawde lepsze,
czy tez co pare lat mamy "najlepiej to byłoby napisac na nowo" :-)

> Systemy oparte o Z80 to guano pisane niskopoziomowo. Ich się nie
> rozwija, tylko łata. I tylko przez chwilę, zanim się rozlecą. To samo z

A widzisz. Daje sie poprawic/zmienic :-)

> 8051. Dodanie tutaj C niewiele pomaga, bo ludzie piszą w nim jak w
> asemblerze, często nieprzenośnie.

Możliwosci są, jakie są ...

>>> Jam masz kod napisany w czymś przenośnym, to Z80 jest gorszy we wszystkim.
>>> Ale zazwyczaj nie masz.
>>> To jest np. powód, dla którego współczesne telefony dalej mają jakiegoś
>>> kolna 8051 do obsługi GSM. Za dużo asemblera powoduje uzależnienie.
>> Mówisz?
>> Technologia sie rozwija, trzeba stale i program unowoczesniac.
>
> O najszybszej furmance świata nie słyszałeś?
>
> https://mlodytechnik.pl/news/10647-najszybszy-proces
or-na-swiecie-z-bytomia
>
> Agrumentacja, nie pamiętam już gdzie zasłyszana, ale chyba od pracownika
> firmy, była taka, że "8051 ciągle jest używane w modemach gsm".

No coz, niewątpliwie:
a) ktos chce za to zapłacic, czyli jest zapotrzebowanie,
b) lub dostali jakies dofinansowanie :-)

> Czyli, jesli czytać między wierszami, jakośc tego kodu jest poniżej
> wszelkich metryk, skoro go jeszcze nie przepisali na cokolwiek innego.
> Najwidocznie nie da się przepisać, bo sieczkę można co najwyżej
> zaemulować albo dokładać gigazhertzów.

Oni tylko procesor "zrobili".
O kodzie nic nie wiadomo.

> Innymi słowy, doczekałem czasów, kiedy hardware łata dziadowski
> software. Nie, żeby nie było też czasem i w drugą stronę.

A wspominajac mistrza Lema "jak powszechnie wiadomo - sprzet i program
sie uzupelniają. Mozna uruchamiac prostszy program na lepszym
komputerze, lub lepszy program na gorszym komputerze.
W granicy - nieskonczony program mógłby działać w ogóle bez
komputera" :-)

>>>>> Mała uwaga: prawie wszystkie wyświetlacze z hcync wcale nie musiały by
>>>>> go mieć. Wszak po wsadzeniu x bitów do rejestru mógłby on automatycznie
>>>>> zmienić wiersz.
>>>> Ale wtedy byłaby sztywna liczba pixeli w linii.
>>> A są jakieś wyświetlacze z elastyczną ilościa pixeli w lini?
>> Wyswietlacze to moze nie, ale narobiło się, ze obslugujemy różne
>> formaty. i "wyswietlacz"/monitor/"ekran" sobie przetwarza..
>
> To nie wyjasnia obecniści HSYNC we współczesnych wyświetlaczach, bo
> problem rozmiaru jest w takim protokole wyłacznie softwareowy. A jednak
> produkuje się je na potęgę.

w HDMI nie ma, w DP nie ma, wiec nie bardzo wiem, o czym piszesz.

O jakis tytulowych RGBTTL, gdzie z założenia jest prosty
protokół/interfejs, i HSYNC jest potrzebne?

>>>> Po co DVI ma blanking periods?
>>> Bo koszt zmiany myslenia, szczególnie w komitetach za zielonym suknem,
>>> jest czasami równy zastępowalności pokoleniowej. Tu masz odpowiedź, po
>>> co komu iface do LCD przypomianający jak żywo CRT.
>> No ale DVI było troche uniwersalne. Analogowy sygnał też gdzieś tam
>> był.
>
> I kto mu bronił być i być generowany innym elementam hardware, innym
> sterowaniem i w ogóle wszystkim innym?
>
> DVI to taka hybryda, gdzie wartości analogowe zamieniono na cyfrowe, ale
> "zapomniano" o całej masie innych zbędnych elementów.

Akurat IMHO - łaczył dwa interfejsy w jednym złączu.
Jedni mogli używać cyfrowe, inni analogowe, a inni sie dziwili,
ze nie działa :-)

> To się tylko wyjaśnić brodaczami za zielonym suknem, zmiana myślenia
> jest możliwa wyłacznie na poziomie zastepowalności pokoleń.
>
> Jak już masz to wejscie cyfrowe i LCD, to po ch... komu blanking? ba, ja
> bym się nawet zastanowiło po co komu wyścig z VSYNC. Taki iface powinien
> na spokojnie przyjąc piksel na sekundę, jesli trzeba.

Kolega podesłał dokumentacje, ale czytac mi się nie chce.
Wyswietlacz/sterownik moze zawierac pamięc, i istotnie predkosci
dosyłania mu nieistotne, albo nie zawiera, i trzeba spelnic wymagania
wyswietlacza.

>> Ale to jak rozumiem dlatego, ze sterownik wyswietlacza ma sprzetowy
>> dekoder MPEG i pomocniczy kanał OSD. Pomocniczy, wiec może być
>> powolny. Szczególnie, jak komus sie nie chce zrobic w assemblerze,
>> tylko wyciąga jakąs ambitną bibliotekę graficzną :-)
>
> I nikomu, poza mna, nie przeszkadzało. Lduzie mają naprawdę prymitywne
> potrzeby.

Albo naprawde działa przyzwoicie szybko ... tylko trzeba program
zoptymalizować. Albo sprzęt :-)

>>> Tym bardziej operatorowi tokarki.
>> No to w czym problem ? Wszyscy sa zadowoleni.
>
> W niczym. Taka moja konkluzja. Bez znaczenia jak żałosne i prymitywne
> GUI dostarczasz. Przeciętny suweren nie jest w stanie odróznić dobrego
> od złego. Nie ma potrzeby sterowania wyświetlaczem dla tokarza, czy
> Krystyny @50Hz. Nie zauważą róznicy.

Kiedys zauważą i zaczną narzekać. No chyba, ze przyzwyczaisz,
i nie będą narzekac.

Np klikam na telefonie (Android) ikonkę fotaparatu ... i mija pare
sekund na jego uruchomienie. podobno na iphone szybciej.
No ale trzeba pamiec odsmiecic ...

Druga sprawa - na tymze telefonie w youtube chce dopisac komentarz
... i zawiesza mi sie na blisko 10 sekund. Po czym klawiatura sie
jakos odblokowuje i jest dobrze.

No co - support mam męczyc, czy ajfona kupic, czy sie na YT obrazić?

J.

do góry

niedziela, 5 listopada 2023 o 16:25:53 UTC+1 Mirek napisał(a):
> On 5.11.2023 11:25, heby wrote:
>
> >
> > Czekamy na dokumentację, zgadywanie nie ma sensu.
> >
> https://www.digimax.it/media_import/DISPLAY/ROCKTECH
/TFT%20LCD/RK043HN01HS-T/RK043HN01HS-T_DS_001.pdf

No to wg mnie nie będzie świecił, trzeba mu wciąż dosyłać pixele w tempie mniej
więcej 9MHz
(albo 27MHz, jeśli się chce zamiast 24 linii "danych" mieć tylko 8 - ale nie
doczytałem
jeszcze, jak trzeba przeprogramować sterownik, żeby w tym trybie dobrze wyświetlał).

"Sterownik" wg mnie jest tylko do odbioru danych i sterowania LCD, pamięci nie ma
(oprócz "pamięci" jednej linii).

Choć ma możliwość zmiany pewnych parametrów przez I2C lub SPI.
Najbardziej mnie zastanawia, co to może być to "OTP".
Napisane, że ma "multi-OTP circuit"
i że są
"Multi-OTP Adjustable Parameters
- 7-bit for VCOM offset adjustment
- 7-bit ID1/ ID2/ ID3 for user use"

Ale cały internet milczy na temat tego, co to jest.

Aha, ważne - wyświetlacz jest na 3,3V, więc nie podłączaj do 5V!!!

Sam "sterownik" SC7283 - fajny chip, 1628 padów :)
Ale też mnie zastanawia to, że piszą, że max rozdzielczość to 480*RGB(H) * 272(V),
a w wyjściach jest:
- source outputs: 720 channels
- gate outputs: 544 channels

To 544 gates to jest 272*2 - ale w sumie po co razy 2, choć może ciekły kryształ tak
potrzebuje.
Ale to 720 sources to dziwne, 480*1,5 - czemu *1,5, a nie *3?
Choć "w sumie" to jest *1,5*2=*3 - czyli tyle, ile jest pixeli:
391680=480*3*272=720*544.

do góry

On Sun, 5 Nov 2023 16:25:51 +0100, Mirek wrote:
> On 5.11.2023 11:25, heby wrote:
>> Czekamy na dokumentację, zgadywanie nie ma sensu.
>>
> https://www.digimax.it/media_import/DISPLAY/ROCKTECH
/TFT%20LCD/RK043HN01HS-T/RK043HN01HS-T_DS_001.pdf

Hm, są tam minimalne czestotliwosci i maksymalne okresy,
informacja ze steruje SC7283, pdf do niego nic nie pisze, ze RAM ma
... zakładam, ze trzeba stale dosyłać dane.

I jeszcze jakas tajemnicza notka, ze Tvbp=12 i Thbp=43 w sync mode...
Ale jest jeszcze DE mode ...

https://www.sitronix.com.tw/en/index/
i szukaj jakiejs noty aplikacyjnej, bo w pdf nie opisali.

Ale zakładam, ze trzeba wysyłac stale.

J.

do góry