On 15.07.2022 21:20, heby wrote:
[...]
> https://elinux.org/S3C2440
>
> O, w takiej formie:
>
> https://aliexpress.ru/item/512714460.html?sku_id=166
610012
>
> Wydajnościowo to bodaj epoka PII.
A kiedy to pisałeś? Mogę się mylić, ale wydaje mi się, ze ta kość 20+
lat ma. Gdy zaczynałem się interesować LPC2000 Philipsa (czyli
ARM7TDMI), to te Samsungi już były.

do góry

On 15.07.2022 21:03, Piotr Gałka wrote:
[...]
> Przyglądam się dyskusji. Nie ogarniam o czym się mówi :).
> Nigdy nie pisałem nic embedded, ale brat pisze.
> On pisze w sposób na pewno bardzo krytykowany przez Ciebie (100%
> samouk). Czyli tkwimy sobie w takim kokonie ale człowiek 60+ już nie tak
> łatwo się uczy.
Tu nie chodzi o samouctwo, tylko mentalność, w wyniku której odrzuca się
obiektywnie lepsze rozwiązania z powodów typu ,,a bo to nowe, po co mi
to" czy ,,eee, uczyć się trzeba". No i dochodzi do patologi takich jak
kontrola wersji w postaci zip-ów przechowywanych na serwerze FTP (ja,
już w XXI wieku, spotkałem się z wersją na serwerze SMB, w znanej
polskiej firmie, potentata w swojej branży :-D ), chociaż systemy
kontroli wersji istnieją od dziesięcioleci.

> Abym choć trochę ogarniał co piszesz sprecyzuj co znaczy 'maleńki
> procesor'.
> Rozmiar pamięci dla programu?
>
> My standardowo używamy 8-bitowców ze 128k albo 256k flasha i to są te
> duże. Maleńkie (32k flasha też używamy).
Maleńki to może być np. 32 bitowy MIPS w obudowie 28-pinowej z ilością
flasha jak wyżej i zapewne ze sporo większą ilością RAM-u. W każdym
razie chodzi o to, że producenci krzemu nas rozpieścili. Oferują coś co
jest szybsze, ma więcej zasobów, jest mniej problemów z jego
oprogramowaniem i kosztuje tyle samo co stary ośmiobitowiec. Stawia to
więc pod znakiem zapytania sensowność użycia ośmiobitowca w nowym
projekcie. Absolutnie nie twierdzę, że jest to złe, ale IMO trzeba się
zastanowić, czy nie warto zrezygnować ze starej dobrej i dobrze znanej
'51 czy AVR i zainwestować trochę czasu w poznawanie czegoś nowego.
Tylko uwaga, nie MIPS-a - ta architektura właśnie umarła:
https://www.eejournal.com/article/wait-what-mips-bec
omes-risc-v/.

do góry

czwartek, 14 lipca 2022 o 14:39:49 UTC+2 Piotr Wyderski napisał(a):

> > Co dokładnie robisz, i co oni robią?
> Pomagam zrobić najszybszą cloudową bazę danych na świecie. Co implikuje
> równoległość na wszystkich poziomach: wiele maszyn, wiele rdzeni, wiele
> równoległych jednostek arytmetyczno-logicznych (SIMD).

Jeśli to nie podpada pod NDA - interfejs do tej bazy też wymyślają nowy czy czarują,
ale pod nieśmiertelny SQL?

do góry

piątek, 15 lipca 2022 o 20:52:33 UTC+2 Piotr Wyderski napisał(a):
> Arnold Ziffel wrote:
>
> > Jak to w praktyce wygląda? Masz konto walutowe w polskim banku?
> No niestety, i to jest kolejny trudny problem do rozwiązania. Nie chcę
> ukrywać dochodów przed skarbówką, tylko trzymać je poza zasięgiem
> lepkich łapek rządu, który może zdecydować o zamrożeniu dostępu do nich,
> jak będzie na musiku. Całkiem dobrze pamiętam konta A i B, jak i bony
> dolarowe PKO.
> > Dostajesz pensję i przewalutowujesz część na PLN (bo przecież żyjąc w PL masz
różne
> > opłaty w PLN, zakupy też robisz w PLN) a reszta zostaje na oszczędności w
> > GBP?
> Dokładnie tak, przy czym chodzi o USD, nie GBP. Z GBP "nie pykło", więc
> zakończyłem współpracę.

Hmm, a silicon valley nie pomaga jakoś w założeniu konta w cywilizowanym kraju?
Czy banki USAńskie wymagają jednak rezydencji?
Bo chyba nie obywatelstwa?
No bo chyba doliniarze pozwolenie na pracę załatwiają,
a "zdalna" praca niczym nie różni się chyba od "zwykłej" green card?
Oczywiście nie namawiam do ukrywania dochodów,
ale wypłacanie wszystkich dolarów przez ocean i trzymanie oszczędności w $ w polskim
banku jest bez sęsu.
Z euro łatwiej, można zdalnie założyć konto w niemieckum N26 i nawet w celu płacenia
nie trzeba kupować złotówek - placisz kartą, i to nawet podobno, jak się chwalą, po
kursie EBC.

do góry

piątek, 15 lipca 2022 o 14:44:50 UTC+2 heby napisał(a):

> 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?
- musiał być kolor? I touch (choć pewnie jednopunktowy i rezystywny)?
- i linux po coś innego niż java?
- jaki był "pośrednik" między javą/swingiem a sprzętem graficznym - X, console
framebufer, jeszcze coś innego?
- po co wątki?
- jakie zagadnienia realtime? To był tylko panel kontrolny czy też sterownik tego
urządzenia (samo urządzenie nie miało innego komputera)?

do góry

On 16/07/2022 00:18, Dawid Rutkowski wrote:
>> Ale była mowa o Linuxie. Więc to nie jest *taki* mały CPU. On jest
>> maleńki, jak na (współczesnego) Linuxa. Ma bardzo mało RAMu, wydajności
>> obliczeniowej, brak koprocesora i ma mało wydajną grafikę. I na tym
>> odpalasz Javę. W/g wielu, to nie ma prawa działać. A działa. Zaskakująco
>> sprawnie, z GUI i obsługującej urządzenie wymagające responsywnosci.
>> Java nie gryzie.
> Ej, mowa o linuxie czy o windows?

O Linuxie, w moim wyapdku.

Urządzenie pracuje na WinCE, QTopia i Linux.

> I o "współczesnym" kernelu czy też może przeglądarkach (przeglądających durne
strony - bo skądś się bierze popularność apek na androida)?

Współczesny kernel ręcznie kompilowany aby się zmieścił, z buxyboxem.

> Po co kernelowi koprocesor?

Połowa prostych poleceń z busybox wymaga FPU. Jak nie masz, wyleci
wyjątek. W tym wypadku wymaga wkompilowania emulacji.

> I "wydajna grafika"?

Widziałeś kiedyś grafikę wpiętą przez SPI, taką pod 320x256x16? Ta nie
jest wpięta w SPI, ale odczucie podobne - refresh rate poniżej 10fsp. To
oznacza, że dla uzytkownika "działa wolno".

> Więc co ma w sobie "współczesny" linux że ten komputerek ma nie dawać rady kernela
z busyboxem?

FPU, wiecej RAMu, więcej mocy obliczeniowej.

Podobno Java klęka na super-serwerach.

No więc nie klęka na takim maleństwie.

> Na moim OmniBooku 800CT, pentium 166MMX z 48MB RAM i 2GB HDD
> linux działal ponad 20 lat (póki dysk nie zdechł).

A odpalasz tam jakąs Javę do sterowania procesów przemysłowych?

>>> Chcę tylko zrozumieć co nazywasz maleńkim procesorem.
>> Taki, ma którym z trudem dział kernel z busybox a tu jeszcze jakiś świr
>> pakuje tę paskudną Jave i mu działa.
> A to J2SE czy J2ME?
> J2ME, no niech będzie, że bez ekranu, mieliśmy na siemensowskich modułach TC45 i
TC65.

Z ekranem. Mówie, że wyświetla GUI na Swingu.

do góry

On 16/07/2022 08:51, JDX wrote:
>> https://aliexpress.ru/item/512714460.html?sku_id=166
610012
>> Wydajnościowo to bodaj epoka PII.
> A kiedy to pisałeś? Mogę się mylić, ale wydaje mi się, ze ta kość 20+
> lat ma. Gdy zaczynałem się interesować LPC2000 Philipsa (czyli
> ARM7TDMI), to te Samsungi już były.

~2009.

Zaznaczam, że nie ja wybierałem hardware. Było *zastane*.

do góry

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.

do góry

Arnold Ziffel wrote:

> Hej,
>
> Chcę się przebranżowić. Od dawna o tym myślę, ale ostatnio jakoś tak
> intensywniej. Niby programuję (C++), ale nie jest to embedded, które
> zawsze mnie interesowało. Dawno już nic nowego nie stworzyłem (poza
> projektami hobbystycznymi), a jedynie robię bugfixing na platformach,
> które mnie nie interesują. Dlatego zacząłem uczyć się programowania
> STM32.
>
> Czy ktoś tutaj programuje zawodowo STM32 i może opowiedzieć, jak wygląda
> rynek pracy? Jest w czym wybierać, są tam sensowne pieniądze? Szukam ofert
> pracy i jest z tym biednie, ale może źle szukam.
>
> Mam duże (choć tylko hobbystyczne) doświadczenie z AVR, ale mam wrażenie,
> że poważne firmy robią poważne projekty w sumie tylko na STM32 (co jeśli
> porównamy możliwości nie jest ani trochę dziwne).
>

Musisz się spieszyć bo to ostatni dzwonek może być (sądząc po wieku).

Po 40 trudniej jest. Ale, na pocieszenie powiem, że po 50 to się nabiera
dystansu do życia. :)

jp


--
jp

www.flowservice.pl
www.flowsystem.pl

do góry

On 18/07/2022 09:57, jacek pozniak wrote:
> Po 40 trudniej jest.

Korpo zatrudni wszystkich. Nie ma co wybrzydzać, na rynku jest dziura
nie do zasypania.

Na początku roku człek którego znam, lat 61 został zatrudniony na
stanowisku programisty. Ne managera, nie dyrektora, nie architekta. W korpo.

Tam jest zakaz dyskryminacji ze względu na wiek.

do góry