Rynek pracy STM32

W dniu 2022-07-16 o 09:24, JDX pisze:

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

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ę

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

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

Reply to
Piotr Gałka
Loading thread data ...

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

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

Reply to
Piotr Gałka

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.

Reply to
Piotr Gałka

Piotr Gałka snipped-for-privacy@cutthismicromade.pl napisał(a):

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

Windowsowe udostępnianie plików.

Reply to
Grzegorz Niemirowski

W dniu 2022-07-18 o 21:20, Grzegorz Niemirowski pisze:

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.

Reply to
Piotr Gałka

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.

Reply to
heby

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.

Reply to
heby

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

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

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.

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

Reply to
Piotr Gałka

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

Przez kilka lat nie było takiego przypadku.

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.

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

Reply to
heby

W dniu 2022-07-18 o 22:11, heby pisze:

Opis możliwości bardzo mi się podoba. Ja nie piszę embedded tylko czasami (bardzo czasami) coś na PC. Przypominam sobie tylko jeden raz kiedy cofałem się do stanu z jakiegoś dnia przed kilku laty. Podejrzewam, że CVS choć ma możliwości imponujące to chyba nigdy bym z nich nie skorzystał.

Nie pracuję w ten sposób. Najpierw długo się zastanawiam, a potem jak już robię to .... nigdy nie musiałem się z niczego wycofywać.

Brzmi bardzo groźnie, chaotycznie i jakby mnie ktoś gonił :)

Częściej nie pamiętam w którym programie to było (mam takich różnych programików około 100). Jak już znajdę który to jest na tyle krótki, że od razu znajduje to co potrzebuję. Podejrzewam, że kontrola wersji raczej dotyczyłaby każdego z nich z osobna - chyba by mi w tym nie pomogła.

Jesteśmy niezastąpieni i to się może zemścić.

Poczekaj, a gdzie to CVS ma te zmiany? Nie na dysku?

Z naciskiem na 'programistów'. Jak ja coś piszę góra miesiąc w roku....

Same się nie pojawią. Nie czuję dlaczego bez CVS nie mają sensu.

Napisz proszę parę haseł o tej higienie. P.G.

Reply to
Piotr Gałka

Nie, to działa odwrotnie. Ponieważ nie masz takich możliwości, to przyzwyczaiłeś się z nich nie korzystać.

Znowu dokładnie ta sama odpowiedź: ponieważ nie masz takiej możliwości, to tego nie robisz.

Nie. Dam przykład:

1) projektujesz PCB. Za tydzień będa płytki. Pliki w CVS z tymczasem: 2) poprawiasz firmware, aby był gotowy na nowe połaczenia, ale Stasiek zachorował i nie możesz kontynuować wiec: 3) dorabiasz miganie diodą. Miganie rzecz ważna, więc dorobić warto, ale w połowie: 4) O przyszły płytki! I to z błędem! Poprawiasz wiec, miganie może zaczekać. 5) Stasiek przyszedł.

Jak widzisz, multitasking nawet w 2 osoby może być wielowątkowy. W jedną też i to jak.

A gdzie go znajdujesz? I czy to coś ma backup? A jak umrzesz, to ktoś się w tym połapie?

Nie. Możesz je mieć wszystkie razem. Możesz mieć wiele niezależnych ale w jednym repozytorium. Możesz mieć wiele repozytoriów. Co tam uważasz.

To jakiś powazny bład organizacyjny. Ludzie nie mogą być niezastąpieni.

Na *jednym* filesystemie, którym łatwiej się zająć pod wzgledem bezpieczeństwa niż 10 dyskami w 5 latpopach z 7 wirusami.

Aby była jasnośc: CVS maja w nosie co w nich trzymasz. Z jednym wyjątkiem: nie lubią plików binarnych. Możesz je tam trzymac, ale sam sobie jesteś wtedy winien, bo pojęcie mergowania, blame itd nie pracują na plikach binarnych i tracisz. Stąd tak duży nacisk na to, aby *źródła* czegokolwiek (programu, pcb, cad) trzymać w formie tekstowej, a nie binarnej i jeden z wielu powodów dla których ludzie porzucają CVS bo ... maja pliki binarne.

Mają sens, ale są trudne w kontroli.

Dam przykład.

1) wrzucam coś w CVS na "główny poziom" 2) automatycznie w tyle, dedykowany serwer, widzi tą wrzutę, ściąga źródła i puszcza na nich testy 3) po chwili dostaje maila że program się kompiluje i przeszedł testy 4) po drodze nie ma białka/galaretki

Gdyby, nie posiadał CVS mógłbym dalej puszczać to ręcznie, ale to jest elemen białkowy, który należy eliminować. Bo testy możesz puścić nie te, nie tu, nie tymi i nie tak. Białko to poważny problem w IT.

1) wszystko co prowadzi do działania programu/urządzenia jest trzymane w CVS. WSZYSTKO. Po bombie atomowej, jesli tylko CVS przetrwa, ma byc możliwosc odtworzenia bit-w-bit całości produktu. 2) nie ma "bo Stasiek to ma jeszcze taki pliczek na c: co ustawia...". Stasiek idzie na dywanik do managera 3) nawet narzędzia, bibliteki zewnętrzne, opcje kompilacji, obrazki, pliki konfiguracyjne IDE. WSZYSTKO. Ale patrz 6) 4) istnieje "główny branch" na którym obowiązkiem programistów jest utrzymanie spójności. Nie ma "wrzucę ten pliczek, a te dwa jutro bo już po 16". Albo wszystko albo nic. Bałagan można sobie robić na swoich branchach eksperymentalnych. Na głównym ma być perfekcyjnie i atomowo. 5) Każda wrzuta w głowny branch jest prawidłowo opisana. Nie ma "poprawka" albo "już działa". Jest "Poprawiono generację PWM dla trybu 16 bit w związku z bugiem L000872 zmieniajac współczynnik podziału kwarcu". 6) CVS trzyma źródła. Nie binaria. Wrzucenie binariów == dywanik u managera. Jeśli coś jest binarne (np. gcc w wersji X) to w CVS jest wrzucona informacja że gcc jest w wersji X. 7) wszyscy używają CVS. Używanie lewych środków przesyłania "poprawek i fixów" jest niedopuszczalne.

Większosc o restrykcje, których zadaniem jest niezrobienei sobie kuku. Są bolesne, szczególnie dla ludzi którzy wczesniej odwalali byle jak, czyli trzymali pliki na c:, pakowali do zipów, chowali pod nazwami "2022_fg_nowy_7_z_popawkami.zip" itp dziadostwo.

Restrykcje są po to, aby było łatwiej.

I jest.

Serio.

PS. Zrobienie repozytorium i rozpoczęcie pracy, w przypadku Subverion, to 2 kliknięcia w pustym katalogu. Nie przesadzam. Nie ma wymówek.

Reply to
heby

W dniu 2022-07-18 o 22:23, heby pisze:

Nie. Wszystkie istotne dane są zapisywane do flasha. Zasilanie jest tak zrobione, że od przerwania (zaraz zabraknie ci prądu) do faktycznego zaniku jest dość czasu na dokończenie aktualnego zapisu do flasha. Przy resetach itp. w RAMie mogą zginąć jakieś ostatnio wysyłane ramki - ale to nic zostanie powtórzone.

Struktura danych jest taka, że w przypadku resetu (przerwa w zasilaniu, watchdog) stan wskaźników do flasha jest odtwarzany z jego zawartości a stan innych rejestrów stanów aktualnych zasadniczo daje się odtworzyć z danych z flasha i RTC. Stany chwilowe nie są odtwarzane (np. był impuls otwierania przejścia i miał jeszcze trwać 3s). Przerwa w zasilaniu, po jakimś czasie powrót zasilania. Impuls nie zostanie dokończony - byłoby bez sensu aby otworzyć drzwi dlatego, że włączono zasilanie. Gdybym to ja pisał to byłbym w stanie rzucić więcej dających pojęcie informacji. Ogólnie jak się wyłączy zasilanie i po jakimś czasie włączy to nasze urządzenia mają pracować jak gdyby nic się nie stało, nawet jak nie mają kontaktu z komputerem przez względnie długi czas (jak się przepełni bufor zdarzeń (chyba 32 tysiące) to albo nastąpi zgubienie najstarszych albo się zablokuje (chyba flaga ustawiana przez użytkownika)).

Jak nie zacznie wysyłać nam błędnych danych (prawidłowo szyfrowanych i podpisywanych) to nic poważnego się nie stanie.

Oczywiste.

....

W najmniejszym stopniu nie krytykuję tego urządzenia. Opisuję tylko dlaczego nam nie pasują tego typu rozwiązania, choć może jesteśmy w tym temacie trochę dinozaurami. P.G.

Reply to
Piotr Gałka

Nieprawda. Podczas pracy algorytmu dane są w RAM.

Są narażone na uszkodzenie. Na przykład od promieniowania kosmicznego. To nie żart - ludzie w ten sposób np. łamali zabezpieczenia kart SIM (hasło: nop slope). Z braku promieniowania kosmicznego używano żarówki...

To idealny świat.

Więc to bardzo specyficzny problem. Nic wspólnego z moim nie ma. przypominam, że odpowiedziałem na marudzenie "Java jest wolna straszliwie", a nie na "jak pisać soft do respiratorów".

Ale jak nikogo nie przekonuje do tych rozwiązań. Bo to nie są rozwiązania, tylko workaroundy. Powód dla którego pojawił się tutaj ten malutki system z Linuxem to postawienie się w opozycji do stwierdzeń "Java jest wolna". Java jest tak wolna, jak kiepscy są programiści. A java ma wyjątkowo kiepskich.

Reply to
heby

W dniu 2022-07-18 o 22:57, heby pisze:

Zdajemy sobie z tego sprawę, ale to jest chyba typowa bolączka wielu mikrofirm.

Pracuję na komputerze (jednym) bez dostępu do internetu. Na sieci wewnętrznej jest dysk (w środku chyba są dwa dyski zrównoleglone) do backupów.

Dzięki za opis.

Nie sztuka kliknąć. Sztuka wiedzieć gdzie.

Jak znam siebie to musiałbym z miesiąc postudiować jakieś opisy tego zanim w ogóle spróbowałbym użyć. A mam tyle innych rzeczy których powinienem się pouczyć - choćby te 32 bitowe procesory.

Jak się chciałem przenieść do KiCada to najpierw przeczytałem całą dokumentację. A teraz na forum widzę masę ludzi, którzy pytają o rzeczy które są jak byk w "Getting started". P.G.

Reply to
Piotr Gałka

W dniu 2022-07-18 o 23:13, heby pisze:

To i tak jest zabezpieczenie na wszelki (normalnie nie zdarzający się) przypadek bo zasilanie buforowe.

Nie zakonotowałem tego "Java jest wolna". Według mnie jesteśmy w ogóle poza kontekstem tego Twojego urządzenia. Ot po prostu staram się tropchę wytłumaczyć 'starych dziadków' - czyli siebie. P.G.

Reply to
Piotr Gałka

W dniu 2022-07-18 o 23:13, heby pisze:

Pora kończyć pracę i wybrać się do domu. P.G.

Reply to
Piotr Gałka

To zależy. Owszem, czasami cieżko zastapić talent. Ale nie może być tak, że człowiek umiera i nikt nie wie "jak on TO kompilował". Ta wiedza musi być dostepna i zazwczaj jest w CVS. Jesli jej tam nie ma to firma jest o jeden zawał od bankructwa.

Dalej, jeden dysk sieciowy łatwiej (automatycznie) backupować, niż dyski klientów.

Repozytorium możesz miec poza firmą. Wtedy ktoś inny dba o backupy.

"Create repository here" w TortoiseSVN na przykład.

Albo 1 osoba, która w niecała minutę przedstawi proces tworzenia repo i wrzucenia do niego pliku. No może w 2 minuty z popijaniem herbatki. Reszta elementów do ogarnięcia w godzinkę, z czego więskzość samodzielnie bez czytania instrukcji.

To bez sensu. Po pierwsze, to zbedna wiedza w większości, po drugie zazwyczaj dokumentacje do projektów darmowych nie są spójne do stanu apliakcji.

Niech pytają. Czytanie dokumentacji świadczy o braku intuicyjności obsługi programu. Akurat w przypadki KiCADa to faktycznie ma miejsce. Czuje ból głowy za każdym razem, kiedy dotykam czegokolwiek z CAD w nazwie.

Reply to
heby

Ale ja też jestem stary dziadek ;)

Może tylko roche bardziej obcykany w dużych projektach programistycznych. I troche mniej w małych, trudnych projektach embedded.

Grunt aby nie stawać w opozycji. To dwa różne światy.

Ale kontrola werji taka sama (być powinna ;)

Reply to
heby

mam jakieś nucleo w szufladzie... bawilem sie kilka lat temu ale to jeszcze były czasy przed ESP32. Dzisiaj to juz prawie nie ma sensu...

Tak z ciekawości... da się to jakoś ogarnąć pod linuksem (w sensie IDE, debugowanie i flashowanie)? U mnie windows poszedl w odstawke z 8 lat temu i nie chce wracać.

c.

Reply to
Cezar

Cezar snipped-for-privacy@tlen.pl.invalid> napisał(a):

Identycznie jak pod Windowsem: Eclipse + GCC + OpenOCD.

Reply to
Grzegorz Niemirowski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.