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.