Mam ponad 20 lat systemów wbudowanych, głównie 8 i 16 mikrosów. Krótka odpowiedź na twoje pytanie jest taka sama jak w przypadku innych programów - nie optymalizuj, dopóki nie będziesz wiedział, że musisz, a następnie nie optymalizuj, dopóki nie dowiesz się, co należy zoptymalizować. Napisz kod, aby był najpierw niezawodny, czytelny i łatwy w utrzymaniu. Przedwczesna optymalizacja jest równie dużym, jeśli nie większym, problemem w systemach wbudowanych
Kiedy programujesz „bez marnowania zasobów”, czy uważasz swój czas za zasób? Jeśli nie, kto płaci za twój czas, a jeśli nikt, nie masz z tym nic lepszego do roboty. Po dokonaniu wyboru, każdy projektant systemów wbudowanych musi dokonać wyboru kosztu sprzętu w stosunku do kosztu czasu inżynierskiego. Jeśli będziesz wysyłał 100 jednostek, użyj większej mikro, przy 100 000 jednostek, oszczędność 1,00 USD na jednostkę to tyle samo, co roczny rozwój oprogramowania (ignorowanie czasu wprowadzenia produktu na rynek, kosztów alternatywnych itp.), Przy 1 milionie jednostek zaczynasz uzyskiwanie zwrotu z inwestycji za obsesję na punkcie wykorzystania zasobów, ale bądź ostrożny, ponieważ wiele projektów osadzonych nigdy nie osiągnęło wartości 1 miliona, ponieważ zamierzały sprzedać 1 milion (wysoka początkowa inwestycja przy niskich kosztach produkcji) i zbankrutowały, zanim tam dotarły.
To powiedziawszy, rzeczy, które musisz wziąć pod uwagę (małe) systemy wbudowane, ponieważ przestaną one działać w nieoczekiwany sposób, a nie tylko spowolnią.
a) Stack - zazwyczaj masz mały rozmiar stosu i często ograniczony rozmiar ramki stosu. Musisz zawsze mieć świadomość tego, jakie jest twoje wykorzystanie stosu. Ostrzegamy, problemy ze stosami powodują jedne z najbardziej podstępnych wad.
b) Sterty - znowu, małe rozmiary sterty, więc uważaj na nieuzasadnioną alokację pamięci. Fragmentacja staje się problemem. Dzięki tym dwóm musisz wiedzieć, co robisz, gdy zabraknie - nie dzieje się tak w dużym systemie, ponieważ system stronicowania zapewnia system operacyjny. tzn. kiedy malloc zwraca NULL, czy sprawdzasz to i co robisz. Każdy ślaz potrzebuje kontroli i obsługi, wzdęcia kodu ?. Jako przewodnik - nie używaj go, jeśli istnieje alternatywa. Z tych powodów większość małych systemów nie korzysta z pamięci dynmaicznej.
c) Przerwy sprzętowe - Musisz wiedzieć, jak sobie z nimi radzić w bezpieczny i terminowy sposób. Musisz także wiedzieć, jak zrobić bezpieczny kod do ponownego wejścia. Na przykład standardowe biblioteki C na ogół nie są ponownie uruchamiane, więc nie należy ich używać w programach obsługi przerwań.
d) Montaż - prawie zawsze przedwczesna optymalizacja. Co najwyżej niewielka ilość (wstawiona) jest potrzebna do osiągnięcia czegoś, czego C po prostu nie może zrobić. W ramach ćwiczenia napisz małą metodę w ręcznie wykonanym zestawie (od zera). Zrób to samo w C. Zmierz wydajność. Założę się, że C będzie szybszy, wiem, że będzie bardziej czytelny, łatwy w utrzymaniu i rozszerzalny. Teraz część 2 ćwiczenia - napisz użyteczny program w asemblerze i C.
Jako kolejne ćwiczenie, zobacz, ile jądra Linuksa stanowi asembler, a następnie przeczytaj poniższy akapit o jądrze Linux-a.
Warto wiedzieć, jak to zrobić, może nawet warto biegle posługiwać się językami dla jednego lub dwóch popularnych mikrofonów.
e) „register unsigned int nazwa_zmiennej”, „register” jest i zawsze była wskazówką dla kompilatora, a nie instrukcją, na początku lat 70. (40 lat temu), miało to sens. W 2012 r. Marnuje się naciskanie klawiszy, ponieważ kompilatory są tak inteligentne, a zestawy instrukcji mikros tak złożone.
Wracając do twojego komentarza na temat Linuksa - problem, który tu masz, polega na tym, że nie mówimy tylko o 1 milionie jednostek, mówimy o setkach milionów, z czasem życia na zawsze. Warto poświęcić czas i koszty inżynierii, aby uzyskać optymalny poziom, jak to tylko możliwe. Chociaż jest to dobry przykład najlepszych praktyk inżynieryjnych, komercyjne samobójstwo dla większości twórców systemów wbudowanych byłoby tak pedantyczne, jak wymaga jądro Linuksa.