Rynek pracy STM32

Mam na LI informacje, że w powaznych sprawach proszę o kontaktmailem i mam ten mail podany jawnie od razu na początku opisu.

Dla HR to jednak za wysoki poziom intelektualny. Do tej pory miałem na kilkadziesiąt konaktów HR tylko dwa przez maila.

Oni w ogóle, mam wrażenie, nie szukają jakoś dokładnie. Odpalają wyszukiwarkę, wpisują "embedded" albo "C++" i Ty parzyste, Anetka nieparzyste. I jadą. Nawet baz danych nie mają, proszą aby dodać ich do kontaktów, aby wiedzili, że już Cie o coś pytali. Ja nie dodaje HR do kontaktów i mam odwrotny skutek: potrafią pisać po kilka razy do mnie w tej samej sprawie, ci sami ludzie. Popsułem Matrixa.

Tak więc zupełnie bez znaczenia co się tam wpisze, jak sie człowiek nazywa, czy ma fotkę itp bs. Mają być słowa kluczowe zadowalające filtry i już. Z rok temu odezwał się do mnie jakiś Anglik ze słowami "co prawda nie pasuje do opisu, ale pomyślałem, że warto zapytać bo może akurat". Desperacja.

Rekruterzy w dziejszych czasach mają inne problemy niż brak nazwiska. Na przykład brak ludzi na rynku ;) Tylko korzystać.

S3Trio64V+ leży za plecami w płycie z pentium mmx 166MHz - jakiś czas temu odkryłem w zastawionym rogu pokoju w robocie - a przez wiele lat się zastanawiałem, co ja z tą płytą zrobiłem... Jest tam też ISA-owa kart dźwiękowa z modułem wavetable i gniazdem joysticka. Tylko nie mam czasu, żeby sprawdzić, czy to jeszcze działa - a jak działa, to pograć sobie w Magic Carpet na moim kochanym joysticku optycznym (tylko gdzie z kolei on jest, chyba jakiś czas temu gdzieś go widziałem...). No i jeszcze muszę sprawdzić, czy mam gdzieś magic carpet no i jakiś DOS...

Herculesa zawsze chciałem mieć jeszcze w czasach 386, żeby na tym niedorobionym DOSie zrobić konfigurację 2-monitorową. Tata pożyczył od kogoś na polibudzie, ale szybko musiał oddać - było niestety "na stanie" i zapisane na jakąś wielką kwotę... No i i tak nie miałem monitora ;>

Ech, jak potem sobie odpaliłem dwa monitory na Linuxie to było coś...

Ale najciekawsze konfiguracja dual-head to była na serwerze w tramwajach - serwer alpha AXP z VMSem, to była maszyna, stała sobie pod biurkiem, kurzu masa w tej centrali ruchu, a ta działała i działała (no raz się zbuntowała jak było bardzo gorąco - szef firmy, która ten serwer dostarczyła, przywiózł wtedy pod pachą "zestaw naprawczy" czyli drugą płytę główną), no i przy upgrade dostała 2 karty radeon na PCI i wiele lat na tych dwóch monitorach wyświetlała, schemat sieci tramwajowej wypalił się luminoforze, pierwszy raz coś takiego widziałem (po zmianie monitorów na LCD też się wypalił - a teraz na tablecie mam wypalone google groups, to chyba w podświetleniu).

Ten sam soft, dalej na Motifie, nadal działa - teraz już na serwerze Xeon/x64 (luxusowo umieszczony w serwerowni), a wyświetla osobny X-Terminal.

Ty to chyba przecierałeś szlaki pracy zdalnej z dekadę przed tym, zanim to się stało modne. :)

Pozdrawiam, Piotr

W dniu 2022-07-14 o 14:14, Dawid Rutkowski pisze:

Firmę założyliśmy w 1988r. Do końca roku (korzystając z wypożyczanych na weekendy komputerów) opracowaliśmy i wyprodukowaliśmy 4 szt programatorów Piccolo (+ program na PC). Potem potrzebowaliśmy zrobić ich tester produkcyjny i to jego płytkę projektowałem już na naszym komputerze (bez HDD było taniej) pod RacalRedac-iem. Dlatego sądzę, że było to w 1989 lub 1990r.

Na pewno musiałem część z tych 640kB przeznaczyć na RamDysk. Z tego co pamiętam to 80kB. Wielkość była bardzo krytyczna - musiały tam wejść jakieś jego pliki, które potrzebował mieć cały czas dostępne, a jak ciut większy RamDysk to nie uruchamiał się - że RAMu za mało. Pozostałe cały czas potrzebne pliki były w A:. W B: były na przemian 2 dyskietki - jedna pełna a na drugiej oprócz jego plików było trochę miejsca na pliki robocze (nie były duże). Nie wszystkie pliki z dystrybucji były potrzebne przy pracy nad PCB. To, które są potrzebne ustaliłem eksperymentalnie - dogrywałem kolejno te o które się upominał.

Pracowałem na CGA, ale nie mieliśmy kolorowego monitora. W czasie studiów złożyłem 3 przenośne Neptuny. W Bomis-ie rzucili zielone kineskopy i płytki wejściowe monitora (wkładane chyba zamiast p.cz) to jeden z nich przerobiłem na monitor. Opornikami zmieszałem RGB tak, że różne kolory widziałem jako trochę różniące się odcienie.

Było ciężko, ale tester (płytka miała z 10x25cm - klucze analogowe do podłączania do poszczególnych pinów podstawki, jakieś sterowane obciążenie, przetwornik A/C itp) zrobiłem i stosowaliśmy go aż do wejścia do Unii kiedy stwierdziliśmy, że nie będziemy płacić za badania EMC Piccolo. P.G.

Ciężka praca :) Ciągle zaczynasz od nowa, za każdym razem musisz przeczytać idące już w tysiące stron dokumentacji, ogarnąć tysiące rejestrów etc.

Nagle okazuje się, że układ niedostępny i od nowa....

Warto też kupić jakiś STMowy kit (np. któryś Discovery - sam mam kilka, do różnych rdzeni) - kosztują niewiele, a bardzo ułatwiają testowanie stopniowo nabywanej wiedzy. Środowisko darmowe (STM32CubeIDE), podobnie jak (trochę "koślawy") program do podglądu zmiennych (STM32CubeMonitor).

To już Eclipse się nie nadaje ;) ?

Ach, gdyby jeszcze w embedded wynaleźli abstrakcje hardwareowe albo w ogóle jakieś techniki programowania znane od lat 80tych...

Ech, marzenia.

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

No właśnie się nadaje :) Toż STM32CubeIDE to nic innego jak Eclipse CDT Embedded

Swoją drogą, to oni długo nie oferowali żadnego IDE, ale jak zaczęli, to dostali jakichś drgawek. Najpierw kupili TrueStudio od Atollica. Potem im się znudziło i wzięli System Workbench (SW4STM32) od AC6. Ale kolejny raz się rozmyślili i zrobili teraz to STM32CubeIDE. Przy czym i tak te wszystkie środowiska to był po prostu opluginowany Eclipse CDT.

Czas na Visual Studio Code i może jeszcze QTCreator. Nadmiar możliwości jeszcze nikogo nie zabił choć osiwieć można.

Widzę "mrugnięcie", ale odpowiem: STM32CubeIDE oparty jest właśnie o Eclipse.

Tak wiem, najzwyczajniej zastanawia mnie co można spieprzyć w zwykłym debugu pod Eclipse że podgląd zmiennych jest koślawy...

W dodatku kolejne wersje STM32CubeIDE mają problemy z kompatybilnością wsteczną. Starsze projekty (np. z wersji 1.2.0) otwierane w wyższych wersjach (np. 1.9.0) wywalają błędy kompilacji. Oczywiście da się to ogarnąć, ale ... czas ucieka.

Pracowałem na wszystkich. STM32CubeIDE IMO jest najwygodniejszy, zwłaszcza po scaleniu z STM32CubeMX - radykalnie przyspiesza konfigurację uC.

1. Podgląd jest OK, koślawa (przynajmniej dla mnie) jest obsługa programu STM32CubeMonitor.

2. Nie wydaje mi się, żeby STM32CubeMonitor też był oparty o Eclipse.

stary grzyb snipped-for-privacy@onet.pl napisał(a):

Zależy od humoru IDE i fazy księżyca. Failed to execute MI command Nie mamy pańskiej zmiennej i co nam Pan zrobi? Co ciekawe po jakimś czasie samo się naprawia. Eclipse ma jeszcze inne niedoróbki, więc może trzeba będzie spróbować VSCode.

Akurat protokół MI to wina gdb. Troche to ogarniałem od strony programistycznej i MI po prostu jest spieprzony, więc nie wincie Eclipse że gdb pisze banda ignorantów nie potrafiących prawidłowo escapeować znaków specjalnych.

Można zgłosić buga na MI. Zazwyczaj olewają.

To nie wina Eclipse ;) Niektóre odpowiedzi MI z gdb wymagaja szklanej kuli. Niektóre debuggery mają lepsze od Eclispe.

Mnie się wydawało, że dowolny kernel z definicji jest bare metal. :-) Chociaż wiem, że ilość kodu zależnego od CPU i okolic w jądrze systemu ogólnego przeznaczenia, do tego potężnego ze względu na rozmiar kodu źródłowego, jest mała czy wręcz znikoma.

Na temat Go wiem tyle, że istnieje taki język programowania. W każdym razie zauważyłem, że istnieje jakaś „wojenka” Go vs. Rust, tzn. że często są one porównywane.

Dla mnie baremetal to raczej coś co działa bez OSa lub jakieś minimalistyczny OS. RTOS już się chyba nie zalicza do bare metal. Coraz więcej projektów wychodzi na RPI bare metal

W Go siedze głęboko od 8 lat a początki miałem jeszcze przed wersją 1.0 chyba.

Do Rusta miałem kilka podejść i jakoś nigdy sie nie mogłem przekonać. Zawsze wyszło że w Go zrobie to prościej a wydajność nie jest wielkim problemem.

c.