Poniższy post jest pisany z myślą o czymś ambitniejszym niż embeded które polega na zrobieniu he he czujnika temperatury na Arduino [bo to w embedded level podobny do bycia wielkim wbdeveloperem stawiającym wszystkim strony na Wordpress].
Masz już solidną usystematyzowaną wiedzę o podstawowych konceptach budowy CPU, DMA, RAM? Wiesz jak są one realizowane w hardware? Wiesz czy kilka różnych CPU może zapisać jednocześnie coś w tej samej kości RAM?
Jeśli nie to są o tym imponującej grubości podręczniki. I raczej trzeba się z nimi zapoznać jeśli uczysz się sam i nie chcesz rozwlekać w czasie procesu nauki. Tak, serio. Bez solidnego zbioru opisującego kupę konceptów jakie się spotyka w low level będziesz wielokrotnie nadeptywał na grabie radośnie czekające by przywalić ci w czoło.
Przeczytałeś ze zrozumieniem przynajmniej ze dwa, kilka razy?
Kochasz czytać dokumentację CPU zajmującą 1000+ stron w optymistycznym przypadku [w mniej optymistycznych jest kilka razy tyle a w najgorszych tyle co kot napłakał i mało wyjaśnia]? Kochasz wyszukiwać kilka tygodni nie znając słów kluczowych informacji o tym jak wygląda wewnętrzna budowa jakiegoś elementu czy rozszerzenia CPU bez gwarancji że trafisz losowo na właściwy trop, bo nawet dokumentacja producenta potrafi się nie zagłębiać w takie detale [nawet produkty "wiodących producentów" mają takie momenty], ale musisz to wiedzieć by zaimplementować pewną funkcjonalność bo bez tej wiedzy nie układa ci się w głowie co w ogóle musisz naklepać w kodzie? Jeśli nie wystraszyłeś się na tym etapie to albo nie wiesz co to oznacza w praktyce albo może będziez z ciebie co najmniej low level code monkey.
Teraz pomedytujmy nad tym co trzeba robić by być czymś więcej niż code monkey.
Kochasz czytać research papers, które początkujący muszą czytać z jakimś solidnym podręcznikiem w ręku, by zdobyć wiedzę której inaczej nie zdobędziesz nie mając doświadczonego mentora (o którego trudno, a jak już się znajdzie takiego który jest jako tako komunikatywny to ma zazwyczaj kupę innych rzeczy na głowie równolegle z opieką nad twoimi postępami)? Myśl o synchronizacji dostępu kilku podzespołów do wspólnych zasobów brzmi jak coś o czym chciałbyś myśleć przed snem czy w czasie kąpieli? Traktujesz poznawanie architektur procesorów, które są martwe od kilku dekad jako hobby? Masz w ogóle jakąś wiedzę czego brakuje w branży czy ogólnie na rynku i co można by zaimplementować lub zaimplementować coś co już istnieje wydajniej? Jeśli tak, to możesz ewentualnie dojść do wyższego levelu niż owe code monkey. Acz gwarancji nie ma, a spocić się można ostro już na etapie bycia zielonym jak trawa na wiosnę.
A i czy wspominałem, że praca z codebase na wiele milionów linii jak Linux (który jest kernelem, a nie systemem operacyjnym bo sobie Torvalds zredefiniował pojęcie systemu operacyjnego) potrafi być tym bardziej uciążliwa im dalej w popularności odsuwamy się od Linuksa, bo dokumentacji mało i po kilku latach się deaktualizuje, a pewne części nie były nigdy dokumentowane bo pracowała nad nimi jedna osoba od lat? Nawt wieloletni commiterzy potrafią się zgubić albo nie rozumieć co palili jak coś pisali dekadę wcześniej a teraz muszą to przerabiać i nie do końca widzą na pierwszy rzut oka z czym będą interferencje jak coś zmienią. Tak, piszę na podstawie tego co widziałem w praktyce tak obserwując z boku jak i w rozmowach z nimi.