Pisanie firmware: montaż czy wysoki poziom?

Większość producentów mikrokontrolerów dostarcza pewnego rodzaju kompilator krzyżowy, w którym można skompilować kod na komputerze, a następnie przenieść go do mikrokontrolera.

Dlaczego C?
Zaletą C jest to, że Twój kod będzie łatwiejszy do przeniesienia do innych mikrokontrolerów w przyszłości. Historia obliczeń pokazała, że kod zazwyczaj przewyższa implementacje sprzętowe.
Drugą zaletą są struktury kontrolne (if, for, while), które sprawiają, że kod jest bardziej czytelny i / align = "left" /

Dlaczego Język Assembly?
Możesz ręcznie tworzyć optymalizacje.

Werdykt
Jak to często bywa w przypadku tego rodzaju pytań, kompromisy są bardzo zależne od konkretnego zastosowania.
Należy pamiętać, że często można je mieszać, wykonując wywołania montażowe w kodzie C, dzięki czemu można znaleźć równowagę odpowiednią dla Twojego projektu.

Specyficzne dla sprzętu PIC
wydaje się że nie masz opcji GCC z większością sprzętu PIC. Z drugiej strony, jak zauważył komentator, kompilatorem Microchip C30 dla 16-bitowych PIC24 i dsPIC33 jest gcc.
PIC nie jest jeszcze wspierany przez SDCC .
Nowe Info: zgodnie z komentarzem, SDCC ma wykonalne wsparcie dla PIC.
Istnieje kilka innych opcji open source , ale nie mam z nimi doświadczenia.

Najlepszą opcją jest prawdopodobnie kodowanie w C, a następnie dla nielicznych przypadków, w których musisz ręcznie zoptymalizować i wykonać lepszą pracę niż kompilator, powinieneś zakodować zespół do swoich plików C.

Kodowanie Assembly należy do przeszłości dla komputerów PC, ale jest bardzo istotne w embedded.

Pisanie assembly w embedded różni się od pisania assembly na komputerach PC. Kompilatory PC są "lepsze od ludzi" w generowaniu zoptymalizowanych instrukcji. Systemy wbudowane często mają dziwne architektury, a ich Kompilatory optymalizujące nie są tak Dojrzałe jak kompilator optymalizujący Komputery PC.

Jednym z problemów, na który natknąłem się przy pisaniu assembly dla mikrokontrolera jest potrzeba Bardzo uważnego ułożenia kodu. Posiadanie tabeli skoków przekracza granice pamięci i powodowanie, że Twój kod przeskakuje do naprawdę dziwnych miejsc, jest raczej niepokojące. Kodowanie w C, kompilator pokrywa tę bazę dla Ciebie.

Zdecydowanie wybrałbym C. Jest szybszy i tworzy bardziej niezawodne oprogramowanie. Montaż ma bardzo mało do zaoferowania i w rzadkich okazjach. Należy pamiętać, że w C:

• będziesz w stanie łatwo portować kod z istniejących platform, nawet z komputerów.
• możesz rozwijać się w języku wysokiego poziomu bez uszczerbku dla szybkości wykonania lub rozmiaru kodu. Pod warunkiem, że dostępny jest wysokiej jakości kompilator (istnieje wiele opcji dla PIC18), te byłyby prawdopodobnie lepsze z C niż ręcznie wykonany montaż.
O wiele łatwiej jest debugować, testować i utrzymywać kod. C tworzy bardziej niezawodny kod.

Kolejna rzecz, która ma związek z PIC18. Nie będziesz musiał radzić sobie z nieintuicyjną architekturą PIC i takimi rzeczami jak banki pamięci.

Miałem dobre doświadczenie z iar kompilatorami C dla 8051 w przeszłości.

Moje ostatnie podejście zawsze było takie:-

Napisz to w C z dobrym kompilatorem optymalizującym i dopiero wtedy, Jeśli pojawi się problem z rozmiarem lub szybkością, rozważ przepisanie pewnych części w asemblerze.

Jednak od czasu zastosowania tego podejścia nigdy nie potrzebowałem do napisania jednej linii asemblera...

Go for c !

Pracowałem dla dużego producenta CE. Ostatni raz widziałem montaż był około 1996 w niektórych małych procedur obsługi przerwań dla dekodowania RC5 i RC6 i algorytmów strojenia TV. Po tym zawsze używane c i c++ (tylko używane klasy, bez stl, wyjątki lub rtti). Mam dobre doświadczenia ze starym kompilatorem KEIL dla 8051 oraz z kompilatorem greenhills (MIPS) i zestawem narzędzi VxWorks (opartym na PowerPC).

Jak mówi Roddy, najpierw napisz W C i zoptymalizuj w montaż później (w razie potrzeby).

Montaż może być w wielu przypadkach szybszy; gdy jesteś na pulpicie, Kompilatory są zoptymalizowane do tego stopnia, że montaż ręczny rzadko jest koniecznością, ale w świecie uC często tak jest. Ponadto, jeśli musisz napisać procedury obsługi przerwań i tego typu rzeczy, często nie możesz tego zrobić w C.

Jeśli chodzi o kompilację, poszukaj w Google kompilatora C dla swojego celu.

Definitywnie C, chyba że

• Pamięć programu jest bardzo ograniczona. Powiedzmy, że po skrupulatnej ręcznej optymalizacji kodu asemblera uda Ci się zmieścić swój program w tym 1024 bajtach flasha, z 0 bajtami w lewo. W tym przypadku żaden kompilator C nie będzie dobry.

• Chcesz mieć absolutną kontrolę czasu. Jeśli opóźnienie przerwania jest zbyt długie, musisz polegać na asemblerze.

Problem w dzisiejszych czasach polega na tym, że Wbudowany może być wszystkim, od ATTiny z 6 pinami i kilkoma bajtami pamięci RAM do wielordzeniowego SBC z wbudowanym systemem operacyjnym, który zawstydzi niektóre komputery stacjonarne.

Jako takie, wybór środowiska langauge / development musi brać pod uwagę, jak wydajny trzeba być vs jak skomplikowany system jest.

Po pierwsze off-C działa wszędzie i skaluje się całkiem dobrze, im wyżej pójdziesz tym bardziej skończysz dzwoniąc z zewnątrz biblioteki itp. aby poradzić sobie ze złożonością.

Dla bardzo małych Mikros (pomiar flash / ram w bajtach) najlepiej używać ASM, gdy osiągniesz zakres kb, C lub którykolwiek z innych tradycyjnych języków może być używany, ponieważ nie musisz liczyć każdego bajtu. Gdy masz megabajty do zabawy, masz zarówno możliwość, jak i coraz częściej wymóg korzystania z RTO, aby zająć się wszystkim i skrócić czas rozwoju. Do czasu, gdy masz sprzęt, możesz uruchomić pełny system operacyjny na pewno możesz się oderwać od sprzętu i po prostu napisać wszystko w wyściełanej komórce, takiej jak Java czy coś takiego, nie martwiąc się zbytnio o to, jak strasznie marnotrawstwo to wszystko jest i jak nie jesteś już prawdziwym programistą... ;)

Wyjątkiem od powyższego jest sytuacja, gdy potrzebujesz całej wydajności, którą możesz wycisnąć ze sprzętu, w którym to momencie możesz potrzebować obniżyć poziom lub dwa, aby utrzymać wydajność.

Jest jeszcze jeden raz, gdy zapis w assembly może być konieczny: jeśli potrzebujesz wykonać jakiś test pamięci RAM niskiego poziomu lub podobny, który wymaga absolutnej kontroli nad miejscem przechowywania danych.

Na przykład oprogramowanie, które potwierdza SIL -2 (poziom integralności bezpieczeństwa) i wyższy, może wymagać ciągłych kontroli pamięci RAM w celu wykrycia ewentualnych uszkodzeń danych. Obszar pamięci RAM, który sprawdzasz, nie może się zmieniać podczas sprawdzania, więc pisanie testu w asemblerze pozwala upewnić się, że jest to prawda, na przykład poprzez przechowywanie dowolnych zmiennych lokalnych w określonych rejestrach lub w innym obszarze pamięci RAM. To byłoby trudne, jeśli nie niemożliwe, w C.

Kod startowy, który zeruje PAMIĘĆ RAM i inicjalizuje niezerowe zmienne statyczne, może być również zapisany w asemblerze dla tego samego zapisu, chociaż ten rodzaj kodu jest zwykle dostarczany.

Jeśli piszesz kod, który jest wysoce zależny od urządzeń peryferyjnych, a łańcuch narzędzi, którego używasz, nie zapewnia niezbędnych elementów wewnętrznych, aby je efektywnie wykorzystać( jak gówniany kompilator Freescale DSP563CC), użyj assembly.

Poza tym, myślę, że niepisane zasady korzystania z assembly vs. języka wysokiego poziomu są mniej więcej takie same jak w przypadku tworzenia oprogramowania komputerowego: utrzymuj kod w czystości, konserwuj i optymalizuj gorący kod za pomocą maszyny język.

To jest dolna linia Jeśli używasz C można ręcznie zoptymalizować później, nie używam niczego innego niż C lub assembler (bez C++, itp).

Kluczem jest zestaw instrukcji mikrokontrolera, jeśli używasz PIC lub nawet 8051, użyłbym tylko assemblera. Jeśli jest to przyjazny dla kompilatora isa, taki jak arm, avr lub msp430, użyj C, aby zapisać pewne typowanie, ale prawdopodobnie będziesz miał pewne procedury w asemblerze z różnych powodów. Podobnie prawdopodobnie chcesz uniknąć biblioteki C, nawet newlib może być po prostu zbyt nieporęczne, pożyczyć kod lub pomysły od nich, ale nie tylko link jeden w. Wracając do pytania, zobacz jakie kompilatory C są dostępne dla celu, ponownie arm i avr nie będziesz miał żadnych problemów. Prawdopodobnie msp też jest w porządku. To, że Keil lub Iar sprzedadzą Ci kompilator, nie oznacza, że powinieneś go kupić lub użyć, wydajność zarówno płatnych, jak i darmowych kompilatorów może być straszna. Musisz być dobrze zorientowany w asm i sprawdzić wyjście (prawdopodobnie musisz napisać disassembler, aby to zrobić).

Bottom line (Kolejna dolna linia), nie ma globalnej odpowiedzi (dobrze unikać anyhthing wyższe niż C jest globalną odpowiedź) to zawsze zależy od tego, co platforma jest jakie są Twoje zasoby jakie jest twoje zadanie jakie są wymagania wydajności jakie są wymagania przenośności (jeśli jest naprawdę osadzony na mikrokontrolera wiele z nich jest z definicji nie przenośny) jakie Kompilatory, debuggery, jtag, itp są dostępne, nawet jeśli jaki system operacyjny hosta czy rozwijasz się może być dużym czynnikiem.

Szkoda, że nikt do tej pory nie wspomniał ani o schemacie. Oba mogą być odpowiednie dla małych środowisk i mogą przynieść imponujący wzrost wydajności.

Zwykły C lub Pascal, Modula2. Ale ze względu na dostępność kompilatora oznacza to C.

Dodatki C++ i podobne są interesujące tylko ze względu na styl, ponieważ dynamiczna alokacja i rozmiar programu są zwykle bardzo ograniczone.

Również bardziej skomplikowane środowisko uruchomieniowe może być uciążliwe, jeśli Twoje aplikacje będą napięte.

Asembler też może być przydatny, ale tylko jeśli sprzedasz naprawdę gigantyczne ilości, a mniejszy firmware oznacza mniejszy, tańszy chip (mniej Flasha) i rozmiar programu jest overseeable (Czytaj: istnieje pewna szansa, że dostaniesz go bugfree w czasie)