On Mon, 18 Jul 2022 19:01:51 +0200, Piotr Gałka wrote:
> W dniu 2022-07-15 o 21:20, heby pisze:
>>> 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.
>
> Kompletnie nie znam się na systemach operacyjnych. Nie mam bladego
> pojęcia ile potrzeba pamięci na najprostszego Linuxa. Myślałem, że może
> względnie mało.

Wpolczesnego?

Nie pamietam ... chyba odpalalem na 8MB.
Ale to bylo 20+ lat temu -)

Byl jeszcze minix, chyba chodzil na AT z 1MB.

Raspberry Pi mialo kiedy 256MB RAM.
Dzis ma 4GB.

J.

do góry

W dniu 2022-07-16 o 09:24, JDX pisze:
> 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.

System kontroli wersji - tylko słyszałem to pojęcie.
Hasło zipy na serwerze ftp i na serwerze SMB (nie wiem co to serwer SMB)
sugeruje mi, że to ogólnie jest jakaś wymiana informacji. Czyli
potrzebne jak coś robi więcej niż jedna osoba (nas nie dotyczy).

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

Co rusz trzeba rozpoznawać coś nowego. Kolejno rozpoznawane:
- 48-ka,
- 51-ka,
- Jakiś Microchip OTP - totalna porażka.
- jakiś Zilog chyba (nie pamiętam - był to pierwszy dostępny z flashem)
- AVR (Atmega)
- AtXmega - na tym bazujemy obecnie.

Microchip nam tak podpadł że zapadła decyzja - nigdy więcej. Polegliśmy
na projekcie z powodu nieudokumentowanych błędów w procesorach.
Znaleźliśmy i zrozumieliśmy 3 błędy. Wysłaliśmy fax-a do nich (do
Stanów) - zero odpowiedzi. Jak mieli pierwszą prezentację w W-wie to
obiecali, że przyślą erratę. Przysłali po 2 miesiącach. Było 6 błędów w
tym nasze 3. Jeden z pozostałych nas rozłożył - obejściem był układ
synchronizujący na zewnątrz. Nie wpadliśmy sami aby coś takiego
spróbować, choć teraz wydaje mi się logiczne, aby tak próbować jak
procesor losowo przegapia przerwanie.

Łatwo się pisze - poświęcić trochę czasu. Tego ciągle brakuje.

W tej chwili brat rozpoznaje USB jednego z EFM32HG (i się trochę
wścieka, choć czasem go słucham to nie umiem opisać o co mu chodzi), a
ja próbuję się zorientować jak wygodnie sobie zorganizować projektowanie
płytek pod to - w sensie wybierania co do której nogi podłączyć.
Na czwartek mam mieć płytkę prototypową (promocja w Techno).

Dla wybranych EFM32TG, EFM32GG i EFM32HG zrobiłem sobie spis co na
której nodze może być. Analogówka w sensie tych szyn jest poplątana. Jak
coś w karcie katalogowej według mnie było zdecydowanie źle to zadałem
pytanie na jakimś ich forum to w zasadzie się dowiedziałem "niezłe
trafienie" - czyli że jest źle. Ale nie przybliżyło mnie to do celu,
choć chyba wiem, że błąd pochodzi z ^C^V z jakiejś innej karty i dlatego
nic się nie zgadza. Ale wtedy akurat musiałem zająć się czymś innym i
nie wiem co dalej.

Właśnie nabrałem wątpliwości. Jak weźmiemy taki USART0 to załóżmy, że RX
może mieć na 5 nogach i TX na 5. Oni te poszczególne możliwości numerują
od 0 do 4. No i do tej pory (patrząc tylko na spis możliwości)
zakładałem, że to jest niezależne. Ale w jakimś opisie płytki
prototypowej napisali coś w stylu, że USRAT0 jest połączony na pozycję
0. Czyżby to było zależne - jak RX na określonej nodze to TX na innej
ale ściśle określonej.
Czyli muszę znaleźć jak to jest zapisywane w rejestrach aby zrozumieć
czy zależne, czy niezależne.
A jak będzie zsynchronizowane to jak to sobie na symbolu procesora
zapisać, abym wiedział co jak mogę łączyć (zakładam, że symbol ma mi
mówić praktycznie wszystko w czasie projektowania).

> Tylko uwaga, nie MIPS-a - ta architektura właśnie umarła:
> https://www.eejournal.com/article/wait-what-mips-bec
omes-risc-v/.

Nigdy nie słyszałem o MIPS.
P.G.

do góry

W dniu 2022-07-18 o 19:19, heby pisze:

>> Już wiem - u nas duży ma tyle k flasha co u Ciebie maleńki ma M flasha :)
>
> Problemem nie jest flash, tylko RAM ;)

Czyli u Ciebie program nie chodzi z flasha ?! :)
P.G.

do góry

W dniu 2022-07-18 o 19:54, J.F pisze:
> On Mon, 18 Jul 2022 19:01:51 +0200, Piotr Gałka wrote:
>> W dniu 2022-07-15 o 21:20, heby pisze:
>>>> 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.
>>
>> Kompletnie nie znam się na systemach operacyjnych. Nie mam bladego
>> pojęcia ile potrzeba pamięci na najprostszego Linuxa. Myślałem, że może
>> względnie mało.
>
> Wpolczesnego?
>
> Nie pamietam ... chyba odpalalem na 8MB.
> Ale to bylo 20+ lat temu -)
>
> Byl jeszcze minix, chyba chodzil na AT z 1MB.
>
> Raspberry Pi mialo kiedy 256MB RAM.
> Dzis ma 4GB.
>

Dla mnie to są rozmiary komputerowe, a nie urządzeniowe :)
W tej chwili robimy urządzenie w którym będzie procek (już 32 bitowy)
ale z 8kB RAMu.
P.G.

do góry

Piotr Gałka <p...@c...pl> napisał(a):
> System kontroli wersji - tylko słyszałem to pojęcie.

Warto zacząć używać, nawet jeśli jest się jedynym programistą w projekcie.

> na serwerze SMB (nie wiem co to serwer SMB)

Windowsowe udostępnianie plików.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

W dniu 2022-07-18 o 21:20, Grzegorz Niemirowski pisze:
> Piotr Gałka <p...@c...pl> napisał(a):
>> System kontroli wersji - tylko słyszałem to pojęcie.
>
> Warto zacząć używać, nawet jeśli jest się jedynym programistą w projekcie.

Jak ktoś inny niż ja będzie tym rządził to nie stracę możliwości powrotu
do stanu z konkretnego dnia (tak jak teraz mam)?
P.G.

do góry

On 18/07/2022 20:55, Piotr Gałka wrote:
>> Problemem nie jest flash, tylko RAM ;)
> Czyli u Ciebie program nie chodzi z flasha ?! :)

To działa tak:

1) Flash
a) mocno obcięty kernel linuxa
b) z wkompilowanym initrd (w sensie to część jądra, taki magiczny tryb)
c) w initrd wkompilowany busybox
d) w initrd trywialny skrypt wyszukujący urządzenia blokowe
e) jak znajdzie urządzenie blokowe z "vmLinux" to robi kexec na tym
pliku

2) RAM odpala się drugie jądro Linuxa (właściwe, "normalne")

3) Dalej wszystko jest z RAM.

Innymi słowy w ROM siedzi sobie bootloader będacy de facto kernelem
linuxa przyciętym do minimum.

Dlaczego tak? Bo pozwal to prosto wymieniać kernel (ten drugi), który
siedzi sobie na karcie SD, bez jakiegoś rocket-science z ubootem. A
uboot z jakiegoś powodu jest tak prymitywny, że nie startuje kernela z
niczego innego niż NAND.

do góry

On 18/07/2022 21:55, Piotr Gałka wrote:
>>> System kontroli wersji - tylko słyszałem to pojęcie.
>> Warto zacząć używać, nawet jeśli jest się jedynym programistą w
>> projekcie.
> Jak ktoś inny niż ja będzie tym rządził to nie stracę możliwości powrotu
> do stanu z konkretnego dnia (tak jak teraz mam)?

Nie ma znaczenia ilu ludzi używa systemu kontroli wersji.

Masz mozliwosć wysofania się z dowolnej poprawki, wliczając w to
detalicznie pojedyncze linie, całe wrzuty, stan z konkretnego dnia,
grupy plików, całe implementacje itd itp. Możesz w ułamku sekund
przełaczyć się na źródła tydzień wstecz, coś sprawdzić, i wrócić do
pracy na aktualnym stanie.

Dodatkowo pozwala Ci tworzyć osobne "sandboxy eksperymentalne" nazywane
zazwyczaj branchami. Sprawdzasz coś, robisz przez 3 tygodnie i na koniec
albo dobre (i mergujesz) albo złe (porzucasz). Robisz 7 rzeczy
jednoczesnie? Branche pilnują niezależnie ich stanu, nie ma mowy o pomyłce.

Robiłes coś 6 lat temu i nie pamiętasz jak? NIe szkodzi, branch tam
dalej jest, można sprawdzić, albo przenieśc zmiany.

Zachorowałeś? Kolega kontynuuje pracę nad problemem, bez grzebania Ci w
prywatnych plikach.

Dysk się popsuł w laptopie? Nie szkodzi, zmiany są w CVS.

Systemy kontroli wersji są super ważne w pracy w grupie, ale dla 1
programisty są bardzo ważne.

Po jakimś czasie okazuje się, że jak masz taki system, to nagle
pojawiaja się automaty budujące, eliminujące bugogenne białko z procesu
produkcji, pojawia się testowanie automatyczne, pojawia się masa innych
elementów inzynierii oprogramowania, które nie mają sensu, jesli nie
masz CVS.

Na świecie jest wielu którzy nie używają CVS. Na 99% z powodu
niepojmowania zalet i mylenia ich z wadami. A niepojmowanie polega na
tym, że CVS wymagają porzucenia głupich nawyków - szczególnie, że
wymagają higieny pracy. A o to w embedded bardzo cieżko.

do góry

W dniu 2022-07-18 o 21:59, heby pisze:

>> Czyli u Ciebie program nie chodzi z flasha ?! :)
>
> To działa tak:
>
> 1) Flash
>    a) mocno obcięty kernel linuxa
>    b) z wkompilowanym initrd (w sensie to część jądra, taki magiczny tryb)
>    c) w initrd wkompilowany busybox
>    d) w initrd trywialny skrypt wyszukujący urządzenia blokowe
>    e) jak znajdzie urządzenie blokowe z "vmLinux" to robi kexec na tym
> pliku

To możesz sobie darować - większości słów nie rozumiem :)

> 2) RAM odpala się drugie jądro Linuxa (właściwe, "normalne")
>
> 3) Dalej wszystko jest z RAM.
>
> Innymi słowy w ROM siedzi sobie bootloader będacy de facto kernelem
> linuxa przyciętym do minimum.
>
> Dlaczego tak? Bo pozwal to prosto wymieniać kernel (ten drugi), który
> siedzi sobie na karcie SD,

Mamy być może irracjonalne obawy i założenia:
- nie mamy zaufania do gniazd na karty SD.
- nie mamy zaufania do programu w RAM - zakładamy, że jest większe
ryzyko przekłamania spowodowanego jakimś zakłóceniem niż ryzyko
przeprogramowania przez to zakłócenie flasha.
- jak po jakimś przekłamaniu zadziała watchdog to pewnie urządzenie nie
wstanie w 50ms.

> bez jakiegoś rocket-science z ubootem. A
> uboot z jakiegoś powodu jest tak prymitywny, że nie startuje kernela z
> niczego innego niż NAND.

Dalszy ciąg używania obcych słów :)
P.G.

do góry

On 18/07/2022 22:11, Piotr Gałka wrote:
>> Innymi słowy w ROM siedzi sobie bootloader będacy de facto kernelem
>> linuxa przyciętym do minimum.
>> Dlaczego tak? Bo pozwal to prosto wymieniać kernel (ten drugi), który
>> siedzi sobie na karcie SD,
> Mamy być może irracjonalne obawy i założenia:
> - nie mamy zaufania do gniazd na karty SD.

Najwyżej przestanie działać. To nie respirator.

Przez kilka lat nie było takiego przypadku.

> - nie mamy zaufania do programu w RAM - zakładamy, że jest większe
> ryzyko przekłamania spowodowanego jakimś zakłóceniem niż ryzyko
> przeprogramowania przez to zakłócenie flasha.

To i tak Ci nie uratuje tyłka: struktury danych są w RAM. rejestry są
"zrobione z ram". Masz ten sam problem. PC też może się przestawić bez
powodu i program pójdzie w maliny.

Gdybym rozmawiał o urządzeniu typu respirator, nie miało by takiej budowy.

To nie jest klasyczny układ automatyki do sterowania promem kosmicznym.
To urządzenie testujace. Najwyżej nie przetestuje. Przyjdzie operator i
wciśnie reset.

> - jak po jakimś przekłamaniu zadziała watchdog to pewnie urządzenie nie
> wstanie w 50ms.

Nie musi.

Nie myl urządzenia do robienia rzeczy nieważnych z rozrusznikami serca.

To "normalny komputer" ale w wersji która jest w zasadzie embedded. Ma
dokładnie takie same problemy jak każdy duży komputer. I zalety też.

do góry