On 06/11/2023 17:30, J.F wrote:
>> 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" :-)

Jesli musisz co kilka miesiący pisać na nowo stos TCP w asm, na
nastepny, o pół centa tańszy uC, to tak, abstrakcja jest lepsza niż
orka. Generuje mniej błedów grubych.

To prawdopodobnie jest wiedza tajemna, sądząc po ilości współczesnych
dramatów typu ventor-lockin w embedded.

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

Tak, zgodnie z zasadą, że wypolerować na błysk można wszystko. Tylko czy
trzeba?

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

O to to.

> No coz, niewątpliwie:
> a) ktos chce za to zapłacic, czyli jest zapotrzebowanie,

Tak, świat tonie w gównianym kodzie. Łatwiej (choć nie taniej) jest
udawać i łatać hardware, niż dokręcić śrubkę programistom aby nie robili
więcej kosztów swoim dziadowskim hackowaniem w asm.

> b) lub dostali jakies dofinansowanie :-)

To być może. Startupy czasami mają komfort na działanie->plan a nie
odwrotnie.

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

Zrobili go, bo "jest do tego kod".

Czyli jest do tego tak zły kod, że innego nie będzie i pozostało przez
50 lat utrzymywać 8051 aż biologia zrobi swoje.

>> 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 tym nieszczęsnym wyświetlaczu, który po 25 latach produkowania LCD
dalej nie ma możliwości dodania licznika i zwolnienia 1 lini.

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

Nie jest. Ale jest. Jak w 99% wyświetlaczy tego typu na rynku, które
opierają się o przedpotopowe scalaki.

Ten intefejs nie jest optymalny, tylko dopasowany do tego co "już raz
słyszałem". Mamoń lubi to.

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

Nie. Lata doświadczenia mi podpowiadają, że np. responsywnośc pilota
N-ki (zmiana kanału zawiesza GUI na 1+ sekundę) powoduje irytację tylko
u mnie. Resza *NIE* widzi tego problemu. Prawdopodobnie, wliczajac
żałosnych programistów którzy to robili. Poprawki na ten problem nie
doczekałem się od 15 lat. To ten sam problem co dziadowskie GUI w DVD,
docelowy klikacz obcując z takim szajsem nie pojmuje że istnieją
alternatywy.

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

Można to markować. Jednym z elementów tworzenia resposywnego i
satysfakcjonującego UI jest markowanie działań. Wystarczy, że przycisk,
który klikasz, zmieni kolor i już masz poczucie natychmiastowości, nawet
jesli rezultat tego przyjdzie za sekundę. Zamiast aparatu można
załadować obrazek aparatu i też powoduje to responsywność. Zamiast
pokazać zdekodowany obraz kanału, można po prostu zmienić kanał na
nastepny od rau po wciśnięciu przycisku (co śmieszne, CRT z początku
wieku był znacząco bardziej responsywne).

Cała sztuka pisania gui to udawanie responsywności.

Ale niestety wielu ludzi nie wyszło jeszcze poza wzorzec projektowy
"onClick" i chyba nigdy nie wyjdzie.

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

Amiga z 7Mhz dawała radę, więc procesor 1000x szybszy też powinien, a
nie daje.

Skoro nie daje rady, to świadczy, jak nisko upadliśmy w jakości
oprogramowania.

PS. Mam telefon z 4GB RAMu. Wydawał się całkiem spoko, do czasu aż
musiałem doinstalować firmowe oprogramowanie (głupi teams i outlook).
Teraz zastanawiam się czy 8GB wystarczy, bo 4 na 100% nie.

do góry

On Mon, 6 Nov 2023 18:00:50 +0100, heby wrote:
> On 06/11/2023 17:30, J.F wrote:
>>> 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" :-)
>
> Jesli musisz co kilka miesiący pisać na nowo stos TCP w asm, na
> nastepny, o pół centa tańszy uC, to tak, abstrakcja jest lepsza niż
> orka. Generuje mniej błedów grubych.

Zakładam, ze jednak nie piszesz.
Szukasz rabatu na swoje procki :-0

A pewnie nigdy nie napisales stosu w assemblerze. Za duża kobyła.

> To prawdopodobnie jest wiedza tajemna, sądząc po ilości współczesnych
> dramatów typu ventor-lockin w embedded.
>
>>> 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 :-)
>
> Tak, zgodnie z zasadą, że wypolerować na błysk można wszystko. Tylko czy
> trzeba?

No sam widzisz - albo sie przesiadamy i piszemy wszystko od nowa,
tudzież wymieniamy cały sprzęt, albo ktos poprawi ten assembler w
godzinę czy kilka :-)

>>> 8051. Dodanie tutaj C niewiele pomaga, bo ludzie piszą w nim jak w
>>> asemblerze, często nieprzenośnie.
>> Możliwosci są, jakie są ...
>
> O to to.
>
>> No coz, niewątpliwie:
>> a) ktos chce za to zapłacic, czyli jest zapotrzebowanie,
>
> Tak, świat tonie w gównianym kodzie. Łatwiej (choć nie taniej) jest
> udawać i łatać hardware, niż dokręcić śrubkę programistom aby nie robili
> więcej kosztów swoim dziadowskim hackowaniem w asm.

Podejrzewam, ze sie mylisz.
Nowy szybki procesor, to jednak nowy projekt, czesto mocno nowy.

Czyli i tak duzo roboty.
A "modemy GSM" ... nie straciły racji bytu? Stary GSM TDMA chyba
likwidują, teraz jakies LTE, pare innych standardów już było ...

>> b) lub dostali jakies dofinansowanie :-)
> To być może. Startupy czasami mają komfort na działanie->plan a nie
> odwrotnie.

Ale kto chcialby dofinansowac 8051?
Na 6502 moze by sie jeszcze paru znalazlo, ale po co - zeby napisac
najszybszego tetrisa na swiecie?
Dotacja musiałaby byc panstwowa :-)

>>> 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.
>
> Zrobili go, bo "jest do tego kod".

A tego akurat w artykule nie ma.

> Czyli jest do tego tak zły kod, że innego nie będzie i pozostało przez
> 50 lat utrzymywać 8051 aż biologia zrobi swoje.

Moze i tak ... ale bedzie ten kod chodzil przy tej predkosci?

>>> 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 tym nieszczęsnym wyświetlaczu, który po 25 latach produkowania LCD
> dalej nie ma możliwości dodania licznika i zwolnienia 1 lini.

O linie to Ty sie nie martw - 24 linie na same dane.
Tysiace do LCD ...

Widac po prostu tak najlepiej.

>> O jakis tytulowych RGBTTL, gdzie z założenia jest prosty
>> protokół/interfejs, i HSYNC jest potrzebne?
>
> Nie jest. Ale jest. Jak w 99% wyświetlaczy tego typu na rynku, które
> opierają się o przedpotopowe scalaki.

A to mi wygląda na w miare nowy scalak.
pdf jest z 2018
https://www.orientdisplay.com/pdf/SC7283.pdf
I ma np rozbudowaną korekcje gamma.

I tak mi wychodzi (głownie z domysłów), ze ma trzy tryby pracy
-Sync - DE, na który narzekasz,
-Sync, który nie wymaga "Data Enable",
-DE, ktory nie wymaga hsync/vsync.

Ale to czasem jest zaleta, ze nie musisz nic przeprogramowywać
w obsludze wyswietlacza - przyjdzie inny sygnał, a i tak wyswietli.

> Ten intefejs nie jest optymalny, tylko dopasowany do tego co "już raz
> słyszałem". Mamoń lubi to.

Te 24 bit RGB istotnie jakos tak mi wygląda.
Ale co proponujesz "lepszego"
Ale moze LCD TFT wymagają ... tzn wymagaja tysiace linii do sterowania
LCD, kto się bedzie przejmował 24 ...

A firma robi całą masę driverów, czemu chcesz uzywac 5-letni ? :-)
A prawda, to Mirek chce :-)

>>> 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.
>
> Nie. Lata doświadczenia mi podpowiadają, że np. responsywnośc pilota
> N-ki (zmiana kanału zawiesza GUI na 1+ sekundę) powoduje irytację tylko
> u mnie. Resza *NIE* widzi tego problemu. Prawdopodobnie, wliczajac
> żałosnych programistów którzy to robili. Poprawki na ten problem nie
> doczekałem się od 15 lat. To ten sam problem co dziadowskie GUI w DVD,
> docelowy klikacz obcując z takim szajsem nie pojmuje że istnieją
> alternatywy.

Widac sekunda to jeszcze znośnie i nikogo innego nie denerwuje :-)

Ale co byś chciał przez te sekunde robić?
Bo zmieniłeś kanał, teraz trzeba poczekac aż odpowiednie dane nadejdą,
aby mozna było go wyświetlic. I to trwa około sekundy wlasnie?

>> Np klikam na telefonie (Android) ikonkę fotaparatu ... i mija pare
>> sekund na jego uruchomienie. podobno na iphone szybciej.
>> No ale trzeba pamiec odsmiecic ...
>
> Można to markować. Jednym z elementów tworzenia resposywnego i
> satysfakcjonującego UI jest markowanie działań. Wystarczy, że przycisk,
> który klikasz, zmieni kolor i już masz poczucie natychmiastowości, nawet
> jesli rezultat tego przyjdzie za sekundę.

No to jakos tam zamarkowali, bo inaczej to bym chyba tez narzekał.
Ale ja, k*, czasem, chce szybko aparat działający, a nie markowanie.

> Zamiast aparatu można
> załadować obrazek aparatu i też powoduje to responsywność. Zamiast

A ja chce szybko aparat, a nie tracenie czasu na niepotrzebny obrazek
:-P

> pokazać zdekodowany obraz kanału, można po prostu zmienić kanał na
> nastepny od rau po wciśnięciu przycisku (co śmieszne, CRT z początku
> wieku był znacząco bardziej responsywne).

Cie nie bardzo rozumiem, co znaczy "zmienic kanał".
Numerek na ekranie ma się zmienic? Logo pokazac?
Zmieniłeś kanał, to widać chcesz obejrzec :-)

> Cała sztuka pisania gui to udawanie responsywności.

Mnie tam raczej wk* te numerki kanałów. I niewielkie mozliwosci
zrobienia "ulubionych"/uporządkowania listy.
A moze przy setce to sie juz po prostu nie da?

> Ale niestety wielu ludzi nie wyszło jeszcze poza wzorzec projektowy
> "onClick" i chyba nigdy nie wyjdzie.

Osobna sprawa, ze takie wzorce są właśnie propagowane.

Ale wlasnie usiłowałem program poprawić, żeby tak bardziej
responsywnie chodził ... ciężkie zadanie :-)

>> No co - support mam męczyc, czy ajfona kupic, czy sie na YT obrazić?
>
> Amiga z 7Mhz dawała radę, więc procesor 1000x szybszy też powinien, a
> nie daje.

Tu sie zawiesza na grube sekundy, to jest cos innego.

> Skoro nie daje rady, to świadczy, jak nisko upadliśmy w jakości
> oprogramowania.

No ba. Ale to przecież "postęp" ?
Kiedys bym sobie zdefiniował odpowiednią strukture danych,
dzis czytam sql do DataTable. Kiedys mialbym numer kolumny w stałej,
dziś indeksuje stringiem. Postęp panie.
I nawet dość szybko to działa, w koncu od czego ma sie te GHz i
rdzenie. Zdaje sie, ze wewnetrznie jakies hashowanie mocno używane.

Czasem nawet cos myslę o optymalizacji, ale mi szybko przechodzi
- przeciez nie po to mam te 4, 8, 16, 32 GB RAM, żeby sie
przejmować tym, ze wczytam np milion rekordów :-)

> PS. Mam telefon z 4GB RAMu. Wydawał się całkiem spoko, do czasu aż
> musiałem doinstalować firmowe oprogramowanie (głupi teams i outlook).
> Teraz zastanawiam się czy 8GB wystarczy, bo 4 na 100% nie.

Outlook to gdzies te emaile musi trzymac.
Teams to ch* wie, co teraz w sobie ma.
Ale czasem patrze na jakies gierki ... kiedys by sie 48kB zmiesciły,
dzis 100MB im trzeba.

No ale przeciez narzekasz na asemblerowców, to co się dziwisz :-)

J.

do góry

On 06/11/2023 19:24, J.F wrote:
> A pewnie nigdy nie napisales stosu w assemblerze. Za duża kobyła.

Ja nie. Kolega tak, jak twierdził, dwa razy pisał to samo (TCP), w tej
samej fimie, do tego samego produktu, bo procesor na którym można było
by skompilować gotowca kosztował o dolara więcej, wiec sprawdzali dwa
tańsze. Nie w gołym asm. Takim przeplatanym z C.

>> Tak, zgodnie z zasadą, że wypolerować na błysk można wszystko. Tylko czy
>> trzeba?
> No sam widzisz - albo sie przesiadamy i piszemy wszystko od nowa,
> tudzież wymieniamy cały sprzęt, albo ktos poprawi ten assembler w
> godzinę czy kilka :-)

Oba wariany idityczne.

Ja proponuję wariant: zmiana -DCPU=XXX na -DCPU=YYY i poprawka w 4
miejscach w HAL.

ALe trzeba było o tym myśleć 20 lat temu.

>> Tak, świat tonie w gównianym kodzie. Łatwiej (choć nie taniej) jest
>> udawać i łatać hardware, niż dokręcić śrubkę programistom aby nie robili
>> więcej kosztów swoim dziadowskim hackowaniem w asm.
> Podejrzewam, ze sie mylisz.
> Nowy szybki procesor, to jednak nowy projekt, czesto mocno nowy.

Niby czemu?

> Czyli i tak duzo roboty.

Nie.

Zobacz arduino. Te same bibliteki są na tyle abstrakcyjne, że banglają
na prockach od 8 do 32 bitów, od bajtów RAMu do megabajtów.

To się wzieło z dobrej architektury, oddzielającej logikę biznesową od
wartwy hardware.

A nie z hackowania w asemblerze.

> A "modemy GSM" ... nie straciły racji bytu? Stary GSM TDMA chyba
> likwidują, teraz jakies LTE, pare innych standardów już było ...

Niech zgadnę, implementacje LTE9 będzie pogadniać 8051 z zegarem 5Ghz?
Nie zdzwiłbym się ani trochę.

>>> b) lub dostali jakies dofinansowanie :-)
>> To być może. Startupy czasami mają komfort na działanie->plan a nie
>> odwrotnie.
> Ale kto chcialby dofinansowac 8051?

Ktoś, kto nie wie, że to furmanka?

Czyli mniej wiecej każdy "inwestor", czyli bankowiec z kredytem, po
kierunku tumanistycznym?

Dostać można doinwestowanie wielu bezużytecznych rzeczy. Dlaczego nie
"najszybszego procesora na świecie"?

> Na 6502 moze by sie jeszcze paru znalazlo, ale po co - zeby napisac
> najszybszego tetrisa na swiecie?

Zabawne, ale Megawin produkuje je do dzisiaj w formie uC ;)

> Dotacja musiałaby byc panstwowa :-)

Taką nawet łatwiej wyrwać, dają ją nie tylko tumaniści, ale też
jednocześnie idioci.

>>> O kodzie nic nie wiadomo.
>> Zrobili go, bo "jest do tego kod".
> A tego akurat w artykule nie ma.

Jak mówię, zasłyszane od pracownika. Niestety nie mam, po tylu latach,
źródła, ale padło w jakimś wywiadzie.

>> Czyli jest do tego tak zły kod, że innego nie będzie i pozostało przez
>> 50 lat utrzymywać 8051 aż biologia zrobi swoje.
> Moze i tak ... ale bedzie ten kod chodzil przy tej predkosci?

Się doda sleepa.

>> O tym nieszczęsnym wyświetlaczu, który po 25 latach produkowania LCD
>> dalej nie ma możliwości dodania licznika i zwolnienia 1 lini.
>
> O linie to Ty sie nie martw - 24 linie na same dane.

Ale one mogą lecieć wprost z RAMu. A HSYNC jednak sterował by CPU.

> Te 24 bit RGB istotnie jakos tak mi wygląda.
> Ale co proponujesz "lepszego"

Pfff, bo ja wiem. HDMI nawet. Cokolwiek szeregowego.

Mam tu na tapecie obecnie jakiś wyświetlacz VGA, bodaj 15 bit, z SPI,
taki maleńki. To będą grube dziesiątki MHz. Ale jak patrze na cenę Pi
Nano, to jakoś mi machanie drutami nawet w setce Mhz nie straszne.

>> Nie. Lata doświadczenia mi podpowiadają, że np. responsywnośc pilota
>> N-ki (zmiana kanału zawiesza GUI na 1+ sekundę) powoduje irytację tylko
>> u mnie. Resza *NIE* widzi tego problemu. Prawdopodobnie, wliczajac
>> żałosnych programistów którzy to robili. Poprawki na ten problem nie
>> doczekałem się od 15 lat. To ten sam problem co dziadowskie GUI w DVD,
>> docelowy klikacz obcując z takim szajsem nie pojmuje że istnieją
>> alternatywy.
> Widac sekunda to jeszcze znośnie i nikogo innego nie denerwuje :-)

Dokładnie. Dlatego ja mam ochotę wychłostać architekta tego guano, ale
*tylko* ja.

> Ale co byś chciał przez te sekunde robić?

Przejść nastepne 5 kanałów w górę. Na większości CRT to było możliwe.

> Bo zmieniłeś kanał, teraz trzeba poczekac aż odpowiednie dane nadejdą,
> aby mozna było go wyświetlic. I to trwa około sekundy wlasnie?

Nie trzeba. Ja chcę zmienić kanał na nastepny. Tymczasem jestem
blokowany aż nadejdzie sygnał, albo dekoder się podda.

>>> Np klikam na telefonie (Android) ikonkę fotaparatu ... i mija pare
>>> sekund na jego uruchomienie. podobno na iphone szybciej.
>>> No ale trzeba pamiec odsmiecic ...
>> Można to markować. Jednym z elementów tworzenia resposywnego i
>> satysfakcjonującego UI jest markowanie działań. Wystarczy, że przycisk,
>> który klikasz, zmieni kolor i już masz poczucie natychmiastowości, nawet
>> jesli rezultat tego przyjdzie za sekundę.
> No to jakos tam zamarkowali, bo inaczej to bym chyba tez narzekał.
> Ale ja, k*, czasem, chce szybko aparat działający, a nie markowanie.

Zwyczajowo jedyne co chcesz to natychmiastowego potwierdzenia akcji, a
nie samej akcji. Aparat może jest tutaj specyficzny. Swoją drogą miałem
nadzieję, że ktoś w końcu zrobi autonomiczny aparat w telefonie, taki z
gatunku milisekund od naciśnięcia mechanicznego przycisku, ale znowu:
suweren nie potrzebuje, można poczekać sekundkę, dziubek i tak się
układa dłużej.

>> Zamiast aparatu można
>> załadować obrazek aparatu i też powoduje to responsywność. Zamiast
> A ja chce szybko aparat, a nie tracenie czasu na niepotrzebny obrazek
> :-P

99% przypadków pozostałych operacji na UI nie wymaga akcji, tylko
markowania. Coś jak ładowanie prostokątów zamiast obrazków. A już możesz
przewijać stronę. Oczywiście twórcy portali do dzisiaj nie potrafią
ogarnąc stabilnej geometrii strony, ale tam też dziadstwo na
dziadostwie. Powiedzmy, że powinno tak być.

>> pokazać zdekodowany obraz kanału, można po prostu zmienić kanał na
>> nastepny od rau po wciśnięciu przycisku (co śmieszne, CRT z początku
>> wieku był znacząco bardziej responsywne).
> Cie nie bardzo rozumiem, co znaczy "zmienic kanał".
> Numerek na ekranie ma się zmienic?

Tak.

Oglądam 11-kę. Chce obejrzeć 13-tkę. Kosztuje mnie to, zamiast 0.5sek na
dwa kliknięcia, około 2 sekund, aż zobacze co jest na 12, który mnie nie
interesuje, do tego czasu dekoder ignoruje, lub nie, wciskanie klawiszy.
Kończysz na powolnym wciskaniu co kanał "up" i czekania za kazdym razem
na sygnał.

Wciśnięcie "13" wymaga spojrzenia na pilota i też trwa, bo jeszcze enter.

>> Cała sztuka pisania gui to udawanie responsywności.
> Mnie tam raczej wk* te numerki kanałów. I niewielkie mozliwosci
> zrobienia "ulubionych"/uporządkowania listy.
> A moze przy setce to sie juz po prostu nie da?

Zauważyłem, że szybko dostosowuje się do obsługui "cztery w górę" niż do
pamiętania cyferek.

> Osobna sprawa, ze takie wzorce są właśnie propagowane.
> Ale wlasnie usiłowałem program poprawić, żeby tak bardziej
> responsywnie chodził ... ciężkie zadanie :-)

Nikt nie twierdzi, że lekkie. Po 17 latach męczenia jako dev
komercyjnego UI, coś niby potafię w tym temacie, ale to jeszcze nie jest
moment kiedy mogę powiedzieć "wiem jak to zrobić".

>> Amiga z 7Mhz dawała radę, więc procesor 1000x szybszy też powinien, a
>> nie daje.
> Tu sie zawiesza na grube sekundy, to jest cos innego.

Widocznie przeładowuje 7 róznych biblitek obsługi XMLa. Gdzieś widziałem
zdekompilowaną jakąś aplikację bankową z takim felerem jako przykład do
czego doprowadza oszczędzanie i outsourcing. Każda część pisana przez
"kontraktorów", używała innej. Zlepili gumą do żucia. Bank bodaj hiszpański.

>> PS. Mam telefon z 4GB RAMu. Wydawał się całkiem spoko, do czasu aż
>> musiałem doinstalować firmowe oprogramowanie (głupi teams i outlook).
>> Teraz zastanawiam się czy 8GB wystarczy, bo 4 na 100% nie.
> Outlook to gdzies te emaile musi trzymac.

Tak, na serwerze.

> Teams to ch* wie, co teraz w sobie ma.

W obu przypadkach jest inny feler: aby zabezpieczyć prywatne dane, oba
programy (outlook i teams) działają - fanfary - w emulatorze androida.
Który allokuje sobie solidne GB na starcie. Taka rekurencja.

> No ale przeciez narzekasz na asemblerowców, to co się dziwisz :-)

W przypadku Androida narzekam na obiektowców.

Ja ogólnie narzekam.

Taka narodowość.

do góry

On Mon, 6 Nov 2023 08:38:21 -0800 (PST), Dawid Rutkowski wrote:
> 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
>
> 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.

https://www.orientdisplay.com/pdf/SC7283.pdf

na stronie 87 masz rozpisane. Jedna pionowa linia dociera do dwóch
pixeli, a dwie poziome linie wybierają co drugi - stąd ten "dual
gate". Jakos zrównoważyli ilosc linii sterujących.

J.

do góry

On 6.11.2023 17:38, Dawid Rutkowski wrote:

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

W tej sytuacji chyba do niczego nie będę podłączał. Wyświetlacz jest z
odzysku i myślałem żeby go ożywić dla zabawy, ale jak trzeba go karmić
cały czas to raczej mija się to z celem - za duży próg wejścia.
Pytanie jeszcze jak by to się zachowało jak się gdzieś pomylę w liczbie
cykli na linię albo w długościach sygnałów - jeśli pokaże cokolwiek,
nawet koślawy i trzęsący się obraz to pół biedy. Gorzej jak nie pokaże
nic dopóki sygnały nie będą tip-top.

--
Mirek.

do góry

On Mon, 6 Nov 2023 20:55:26 +0100, Mirek wrote:
> On 6.11.2023 17:38, Dawid Rutkowski wrote:
>> Aha, ważne - wyświetlacz jest na 3,3V, więc nie podłączaj do 5V!!!
> W tej sytuacji chyba do niczego nie będę podłączał. Wyświetlacz jest z
> odzysku i myślałem żeby go ożywić dla zabawy, ale jak trzeba go karmić
> cały czas to raczej mija się to z celem - za duży próg wejścia.

Atmega moze nie wydolic, ale jakies FPGA ...
A moze i Atmega wydoli, gdyby tak rzadziej zmieniac dane, w koncu nie
ma obowiązku co kazdy piksel ...

Raspberry nie ma odpowiedniego wyjscia?
Ekrany do R.Pi są, ale chyba mniej drutów.

> Pytanie jeszcze jak by to się zachowało jak się gdzieś pomylę w liczbie
> cykli na linię albo w długościach sygnałów - jeśli pokaże cokolwiek,
> nawet koślawy i trzęsący się obraz to pół biedy. Gorzej jak nie pokaże
> nic dopóki sygnały nie będą tip-top.

Zakresy jak widac ma pewne, nie za duze, nie za małe.

Bardziej bym sie bał, ze ekran sie uszkodzi, jak np
za rzadko będziesz wysyłał dane.

J.

do góry

On 06/11/2023 20:55, Mirek wrote:
> W tej sytuacji chyba do niczego nie będę podłączał.

Wypasione wyświetlacze z normalnym iface są relatywnie tanie.

https://pl.aliexpress.com/item/4000210180957.html

do góry

poniedziałek, 6 listopada 2023 o 20:55:28 UTC+1 Mirek napisał(a):
> On 6.11.2023 17:38, Dawid Rutkowski wrote:
>
> > Aha, ważne - wyświetlacz jest na 3,3V, więc nie podłączaj do 5V!!!
> W tej sytuacji chyba do niczego nie będę podłączał. Wyświetlacz jest z
> odzysku i myślałem żeby go ożywić dla zabawy, ale jak trzeba go karmić
> cały czas to raczej mija się to z celem - za duży próg wejścia.
> Pytanie jeszcze jak by to się zachowało jak się gdzieś pomylę w liczbie
> cykli na linię albo w długościach sygnałów - jeśli pokaże cokolwiek,
> nawet koślawy i trzęsący się obraz to pół biedy. Gorzej jak nie pokaże
> nic dopóki sygnały nie będą tip-top.

Ogólnie to podłączyć niełatwo, choćby z uwagi
na tą taśmę, choć jest w miarę "standardowa".
Można w miejsce innego wyświetlacza w jakiś
działający system - choćby po to, by sprawdzić,
czy ten odzysk działa.
A potem np. do jakiejś płytki z FT800 czy FT810,
były takie w elty.pl, nawet mam, ale jeszcze przed
kowitem kupowałem, albo we wczesnym kowicie,
jak jeszcze można było kupić, potem nie było, teraz nie wiem.
Fajne, bo jest złącze na taśmę, wlutowany chip
i jeszcze konwerter umożliwiający zasilanie całości z 5V
(chyba jeszcze drugi do podświetlenia?),
a że FT810 ma piny 5V tolerant to można
bezpośrednio do ATmegi przez SPI.
Tylko jeszcze trochę dupogodzin żeby
się nauczyć ten FT8x0 obsługiwać - najpierw
żeby dobrze ustawić wyjściowe przebiegi,
bo to dobra karta graficzna i obsługuje
wyświetlacze o różnych rozdzielczościach,
a potem jak coś wyświetlić - bo umie więcej
niż tylko framebuffer (a żeby był framebuffer
to też trzeba umieć ustawić).
Ogółem zabawa przednia z częstym wzywaniem
pań lekkich obyczajów - ale trza mieć czas.

do góry

poniedziałek, 6 listopada 2023 o 20:00:31 UTC+1 J.F napisał(a):
> On Mon, 6 Nov 2023 08:38:21 -0800 (PST), Dawid Rutkowski wrote:
> > 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
> >
> > 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.
> https://www.orientdisplay.com/pdf/SC7283.pdf
>
> na stronie 87 masz rozpisane. Jedna pionowa linia dociera do dwóch
> pixeli, a dwie poziome linie wybierają co drugi - stąd ten "dual
> gate". Jakos zrównoważyli ilosc linii sterujących.

Rzeczywiście w porównaniu do 480*3+272 zysk 1/3 mniej.
Hmm, ale jakby dać 272*3+480 to by było tylko troszkę więcej.
Ale może tak jest lepiej bo ciekły kryształ i tak wymaga?

do góry

On Mon, 6 Nov 2023 14:25:22 -0800 (PST), Dawid Rutkowski wrote:
> poniedziałek, 6 listopada 2023 o 20:00:31 UTC+1 J.F napisał(a):
>> On Mon, 6 Nov 2023 08:38:21 -0800 (PST), Dawid Rutkowski wrote:
>>> 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
>>>
>>> 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.
>> https://www.orientdisplay.com/pdf/SC7283.pdf
>>
>> na stronie 87 masz rozpisane. Jedna pionowa linia dociera do dwóch
>> pixeli, a dwie poziome linie wybierają co drugi - stąd ten "dual
>> gate". Jakos zrównoważyli ilosc linii sterujących.
>
> Rzeczywiście w porównaniu do 480*3+272 zysk 1/3 mniej.
> Hmm, ale jakby dać 272*3+480 to by było tylko troszkę więcej.

Oprócz zysku na ilosci jest jeszcze zysk na gęstosci - zamiast miec
1440 połączen na dłuższym boku, mamy tylko 720.
Pixel RGB jest kwadratowy, ale ma trzy "podpixele" koloru - czyli
z jednej strony 3 razy gęściej. A to chyba kolejne problemy przy
montażu.
A tak mamy bardziej wyrównane, bo z jednej strony 1.5, z drugiej 2
linie na kwadrat.

> Ale może tak jest lepiej bo ciekły kryształ i tak wymaga?

Chyba nie, to TFT jednak. Można różnie zrobić.

J.

do góry