On 16/07/2022 13:00, Dawid Rutkowski wrote:
>> Dla równowagi: napisałem panel sterujacy urządzeniem, w Javie, na
>> maluteńkim procesorze Samsunga który ledwo ciągnie Linuxa. Wymagało go
>> kernelowania kompili, ale dało radę. Responsywnośc zaskakująca. Bazuje
>> na Swingu + touchscreen, sporo kontrolek, wskaźników, kilka wątków,
>> komunikacja z urządzeniem, zagadnienia realitme.
> Żeby nie było tylko flejmu, to techniczne pytania:
> - kiedy to było?

~2009. Przyznaję jednak, że trochę zgaduje, bo nie mam teraz dostępu do
lepszej estymacji.

> - musiał być kolor? I touch (choć pewnie jednopunktowy i rezystywny)?

Taki był zastany. Nie musiał być, ale ten panel pracował w warunkach
hali produkcyjnej, był już zamontowany i sens zmiany nie wydawał się
atrakcyjny finansowo i czasowo.

> - i linux po coś innego niż java?

Linux dlatego, że był gotowy kernel na ten CPU dostarczony przez chińczyków.

Java dlatego, że oprogramowanie sterujace wczęsniej pracowało na PC i
zostało (po lekkim dostosowaniu GUI do innego rozmiaru) przeniesione
prawie za darmo.

Najwięcej czasu pochłoneło uruchomienie Linuxa na tej maszynie tak, aby
działała Java. To nie było wcale trywialne, domyślna konfiguracja
kernela na tą maszynę nie zawiera wielu ważnych detali (emulacja FPU,
jakieś brakujące syscalle z których korzysta Java itp, mało już tego
pamietam).

> - jaki był "pośrednik" między javą/swingiem a sprzętem graficznym - X, console
framebufer, jeszcze coś innego?

X na framebuffer. Framebuffer jako element jądra dostarczony z
urządzeniem w postaci patchy na kernel. Osiągał bardzo słabe fps, miałem
nawet podejrzenia czy nie jest wpięty przez SPI, ale gdzieś potem
dowiedziałem się, że ten typ tak ma.

> - po co wątki?

Bo aplikacja obsługiwała 4 niezależne maszyny, a sam algortym sterujący
był napisany w JavaScript, odpalającym się pod Rhino (Javowy interpreter
JS). Urzedzenie ogarniało 4 niezlaeżne jednostki wymagajace osobnego i
niezależnego sterowania, z bardzo dużą ilością stanów i decyzji do
podjęcia po drodze. Całośc procesu była zapisana w języku JS.

> - jakie zagadnienia realtime?

Na przykład miałeś wąski czas kiedy mogłeś odczytać parametry
elektryczne silnika (moc/prąd itd). To tak pod 50ms.

Gdyby java była tak strasznie niedobra, to było by niemozliwe. Tymczasem
nie tylko Java dawała rade, ale dodatkowo te parametry odczytywał skrypt
w JavaScript pracujący jako embedowany język w środku aplikacji w Javie.
Czyli dodatkowa warstwa spowolnienia.

Kiedy się tego podejmowałem nie wiedziałem, czy to w ogóle możliwe.
Okazało się nie tylko możliwe ale relatywnie proste - po ogarnięciu
odpalania Javy wystarczyło dostosować GUI apliakcji do mniejszego
wyświetlacza i ruszyła bez zająknięcia. Tu była ogromna zaleta -
aplikacja wcześniej pracowała na PC i była sprawna, przetestowana,
dopieszczona.

> To był tylko panel kontrolny czy też sterownik tego urządzenia (samo urządzenie nie
miało innego komputera)?

To było jedno i drugie:
1) kilka niezależnych wątków obsługujących kilka niezależnych maszyn na
róznych etapach pracy
2) zbieranie danych pomiarowych i sterowanie układami wykonawczymi (RS485)
3) wysyłanie wyników do centralnej bazy danych przez sieć
4) obserwacja na żywo stanu na wyświetlaczu
5) kilka elementów interakcyjnych pozwalających na ręczne przejęcie
sterowania nad dowolną z maszyn.

Możesz założyć, że to był automatyczny tester produktów z dość
skomplikowanymi operacjami wymagającymi kilkunastu akcji i odczytów
parametrów elektrycznych i mechanicznych w określonym czasie.
Obsługujący dowolną ich liczbę (ale praktycznie tylko 4 z uwagi na
zwykłe gabaryty maszyny).

PS. Znalazłem sprawny egzemplarz w domu, a czkolwiek bez maszyny
niewiele na nim można zobaczyć bo uruchamia się w trybie raportujacym
błedy łaczoności.