Pytanie:
Czy w przyszłości będzie możliwe pisanie kodu w C ++ dla mikrokontrolerów PIC?
hkBattousai
2012-02-17 15:01:52 UTC
view on stackexchange narkive permalink

Czy kiedykolwiek będzie można używać C ++ do kodowania PIC? Czy są jakieś ograniczenia sprzętowe, które uniemożliwiają nam używanie C ++? O ile zwiększa się rozmiar generowanego pliku .hex i czas działania programu, gdy używamy C ++ zamiast C? Czy jest praktycznie możliwe użycie C ++ dla aktualnych PIC? Czy są jakieś plany na przyszłość lub stały rozwój w tej sprawie?

Myślę, że jest to możliwe i pozostanie możliwe, ale AFAIK nie jest to zalecane, ponieważ implementuje struktury wysokiego poziomu i funkcje, które nie są odpowiednie do programowania silnie związanego ze sprzętem
Do debaty na temat odpowiedniości - http://electronics.stackexchange.com/questions/3027/is-c-suitable-for-embedded-systems
Ponieważ odpowiedź brzmi „Tak, istnieją już kompilatory C ++”, pozwolę sobie na to, ale w przyszłości powinniście być świadomi, że pytania Stack Exchange powinny dotyczyć weryfikowalnych faktów, a nie przypuszczeń dotyczących przyszłości.
@clabacchio: Niekoniecznie prawda. W C ++ płacisz tylko za to, czego używasz. Zobacz moją odpowiedź na: http://electronics.stackexchange.com/questions/3027/is-c-suitable-for-embedded-systems/26940#26940
„PIC” to bezużyteczne uogólnienie. Na niektórych niższych PIC (myślę, że 10F200) C jest prawie niemożliwe do użycia. Mówi się, że na niektórych wysokiej klasy PIC (seria 32MX) C ++ jest obecnie używany i z pewnością nie ma technicznego powodu, dla którego nie mógł. Więc lepsze skupienie się może dać bardziej użyteczną odpowiedź, w tej chwili każdy w efekcie odpowiada na inne pytanie.
Pięć odpowiedzi:
Rocketmagnet
2012-04-01 03:01:31 UTC
view on stackexchange narkive permalink

Czy kiedykolwiek będzie możliwe używanie C ++ do kodowania PIC?

Tak, teraz jest to możliwe. Dla dsPIC istnieje kompilator IAR Systems C ++ (chociaż jest bardzo stary i nie jest obsługiwany).

Inną opcją jest użycie konwertera C ++ na C. Korzystając z etapu pre-build, przekonwertuj C ++ na C, a następnie przekaż (nieprzyjemnie wyglądające) C do swojego normalnego kompilatora C. Spójrz na LLVM lub kompilator C ++ Comeau, które to robią. Comeau kosztuje tylko 50 USD, ale prawdopodobnie będzie wymagało trochę wysiłku, aby cały zestaw narzędzi i biblioteki działały poprawnie.

Czy są jakieś ograniczenia sprzętowe, które uniemożliwiają nam używanie C ++?

Krótka odpowiedź, nie, nie ma ograniczeń sprzętowych. Długa odpowiedź, C ++ z pewnością zachęca do korzystania ze sterty i / lub stosu, z którymi borykają się mniejsze MCU z ograniczoną pamięcią RAM.

Dlaczego zmagają się ze stosem? Z dwóch powodów: A) wiele mikrokontrolerów ma ograniczoną pamięć RAM, z pewnością niewystarczającą na stertę i ledwo na stos. B) wiele MCU nie obsługuje dobrze wskaźników, więc użycie zmiennych na stosie naprawdę zabija wydajność.

Kiedy ludzie pytają o używanie C ++ na MCU, uważam, że konstruktywne jest porównywanie C ++ z C. dokładnie te same pytania były (i nadal są) zadawane na temat C na MCU. Ludzie wzdragali się przed tym pomysłem. Język wysokiego poziomu, na 256-bajtowym MCU RAM? Niemożliwy. Ale teraz wszyscy wiemy, że jest to możliwe. Napisałem C dla PIC12. Nie ma problemu. Jest to możliwe, ponieważ A) programiści wiedzą, że muszą być trochę ostrożni: nie używaj funkcji malloc () itp. Oraz B) kompilator został napisany specjalnie dla MCU. Kompilator będzie również bardzo ostrożny przy alokacji pamięci, nie będzie próbował utworzyć sterty i może nie utworzyć stosu. Niektóre kompilatory C po prostu nie pozwolą ci napisać kodu re-entrantowego (rekurencyjnego), który absolutnie wymaga stosu.

Wiedząc, że można napisać C dla MCU, te same odpowiedzi odnoszą się do pytania o pisanie C ++ na MCU. Dopóki kompilator rozumie ograniczenia urządzenia docelowego, a użytkownik rozumie również język, naprawdę nie ma problemu. W C ++ płacisz tylko za to, czego używasz. Całkiem możliwe jest napisanie C ++ (z obiektami i wszystkim), który generuje dokładnie takie wyjście asm, jakie otrzymalibyście, gdybyście użyli C.

Teraz PIC32 z pewnością poradzi sobie z C ++. Posiadają aż 64kB RAM i bazują na rdzeniu MIPS, czyli odpowiednio rozwiniętym 32-bitowym procesorze. Może radzić sobie ze wskaźnikami i stosem, a także z komputerem. Rzeczywiście, istnieją komputery PC oparte na MIPS (a przynajmniej były).

Niestety, wokół C ++ jest wiele nieporozumień. Wydaje się, że nawet bardzo doświadczeni programiści nie mają pojęcia, jak działa ten język. Zobacz moją odpowiedź, dlaczego C ++ jest odpowiedni dla wbudowanych procesorów.

O ile zwiększy się rozmiar wygenerowanego pliku .hex i czas działania programu, gdy zamiast tego użyjemy C ++ z C?

Jak powiedziałem, może nie być różnicy. Bjarne Stroustrup porównał kilka kompilatorów C / C ++, aby porównać wydajność w czasie i przestrzeni dla wielu operacji. Wyniki były bardzo zróżnicowane. W niektórych przypadkach C ++ wyszedł wolniej i większy, w innych wolniejszy i mniejszy lub szybszy i większy, a nawet szybszy i mniejszy! Tak więc odpowiedź na twoje pytanie jest taka, że ​​zależy to w dużej mierze od kompilatora, ale ogólnie nie musi to robić żadnej różnicy. Aby uzyskać więcej informacji, zobacz Raport techniczny o wydajności C ++

Czy są jakieś plany na przyszłość lub trwający rozwój w tej sprawie?

Tego nie wiem. Wiem, że kompilator Microchip C32 jest open source i możesz pobrać jego źródło. Wiem też, że ktoś, z kim pracowałem, znalazł instrukcje online i zdołał przekonać kompilatora do skompilowania kodu C ++. Ale odszedł z firmy, zanim był w stanie ustawić mi odpowiedni łańcuch narzędzi.

AKTUALIZACJA

Microchip ma teraz Kompilator C ++ dostępny dla serii wbudowanych mikrokontrolerów PIC32.

ze strony internetowej IAR: „Starszy produkt: IAR Embedded Workbench dla dsPIC jest starszym produktem. IAR Systems nie aktualizuje go i nie jest możliwe wykupienie dla niego umowy Support and Update Agreement”.
Wiem, że produkty IAR są świetne, ale niestety bardzo drogie i wydają się „stare”. Wiem, że C ++ jest możliwe na każdej platformie, o ile nie używasz wszystkich funkcji. Jednak dodaje możliwość dodatkowej abstrakcji z klasami. Nie używam często szablonów ani w ogóle nie używam dynamicznych alokacji pamięci. Czy zdarza się, że ktoś zna innego konkurenta C ++ na PIC24 / PIC32?
Tak, przepraszam, to nie było wspaniałe znalezisko. Pozwólcie, że dodam więcej rzeczy do mojej odpowiedzi.
Uznałbym C za konkurenta C ++ na mikrokontrolerze. Nie przychodzi mi do głowy nic, co chciałbym zrobić w C ++, czego nie mogę zrobić w C i jest mniej niewidocznych wywołań funkcji (konstruktory, destruktory itp.). Sprawia, że ​​kod jest bardziej deterministyczny i prosty. Jakie funkcje C ++ są niezbędne, których nie da się obejść z C?
Ktoś mógłby zapytać: „Jakie cechy C są koniecznością, których nie da się rozgryźć w ASM?” Odpowiedz: „Nic”. Korzyści to zwiększona zdolność projektanta do określenia projektu i sprawdzenie przez kompilator, czy implementacja jest poprawna. Zobacz moją odpowiedź http://electronics.stackexchange.com/questions/3027/is-c-suitable-for-embedded-systems/26940#26940, aby zapoznać się z listą rzeczywistych i natychmiastowych korzyści C ++ w tym względzie.
Szkoda, że ​​nie mogę znaleźć żadnych plików binarnych dla LLVM. Comeau wygląda na dziwny program, w którym używa się słów takich jak `` zapierający dech w piersiach, niesamowity i bajeczny '' (czyli co MOŻE zrobić? - nie mam pojęcia, nie płacę za to 50 $!). Musiałbym przetestować LLVM w VMware, ale brzmi to bardzo bolesnie w codziennym użytkowaniu.
Tak, to bardzo smutne, że nie ma w pobliżu świetnych rozwiązań.
Możesz wypróbować kompilator Comeau online: http://www.comeaucomputing.com/tryitout/
Przyznałem ci nagrodę jako jedyną przydatną odpowiedź w okresie nagród. Zdarzyło mi się odkryć chipKIT32, który jest kompatybilny z Arduino i dlatego używa C ++! Widziałem nawet pic32-g ++. Exe, więc to trochę obiecujące. Napiszę tutaj, jeśli uda mi się coś z tego wyciągnąć. Dokumentacja nowych przyszłych kompilatorów firmy Microchip zmieniła status C ++ z „nieobsługiwany” na „jeszcze nieobsługiwany”.
Dzięki Hans. Dobre wieści o chipKIT32 i bardzo dobra wiadomość, że Microchip może pewnego dnia mieć kompilator PIC32 C ++!
Należy zauważyć, że procesory takie jak „klasyczne” PIC lub 8x51 nie są możliwe do wygenerowania dobrego kodu bez generowania wykresu wywołań bez pętli. Kompilatory dla takich maszyn są generalnie pesymistyczne w generowaniu grafów wywołań, ale w przypadku kodu napisanego w C zwykle nie stanowi to problemu. Nie próbowałem kodować C ++ na takich platformach, ale spodziewałbym się, że w wielu przypadkach może być trudniej udowodnić, że procedury nie można wywołać rekurencyjnie.
@supercat - To właściwie bardzo interesujący punkt.
Które kompilatory C nie pozwalają na kod rekurencyjny?
Link do kompilatora IAR C ++ jest teraz martwy.
@Dean - Myślę, że jest co najmniej jeden kompilator C dla PIC, który nie, może [CSS] (http://www.ccsinfo.com/). Również kompilator PSoC [generalnie nie zezwala na ponowne wprowadzenie kodu] (http://www.cypress.com/?id=4&rID=38637).
Jason S
2012-02-17 19:38:12 UTC
view on stackexchange narkive permalink

O ile zwiększa się rozmiar generowanego pliku .hex i czas działania programu, gdy używamy C ++ zamiast C?

Zależy, jakich funkcji używasz. Jeśli używasz podstawowych funkcji obiektowych (klasa + metody), prawdopodobnie będzie to miało bardzo mały wpływ (zniekształcone nazwy zmiennych / funkcji są dłuższe, więc tablica symboli prawdopodobnie nieco się zwiększy). Szablony też nie powinny wiele dodawać, jeśli masz dobry kompilator.

Jeśli oszalejesz i zaczniesz używać rzeczy takich jak Biblioteka szablonów standardowych i korzystasz z dynamicznej alokacji pamięci i wyjątków, prawdopodobnie napotkać rozdęty kod.

Justin ostrzeżenie dla OP, bądź bardzo ostrożny przy alokacji pamięci w małych architekturach pamięci i wbudowanych zawsze działających systemach.
czy „-1” może skomentować, dlaczego się nie zgadza?
Nie jestem -1er, ale szablony to funkcja, której należy używać z dużą ostrożnością, aby uniknąć nadużywania kodu.Możesz łatwo skończyć z wieloma kopiami algorytmu, jeśli wystarczy.
Aby to zrobić, faktycznie musiałbyś * użyć * szablonu z kilkoma różnymi typami danych, a jedna kopia ** NIE BYŁaby ** wystarczająca, chyba że używasz kodu polimorficznego, który ma wspólną klasę bazową.(W takim przypadku wiąże się to z kosztami czasu wykonania). Szablony nie powodują w magiczny sposób rozdęcia kodu, powodują one tylko rozdęty kod, gdy używasz ich z wieloma typami danych, gdy nie jesteś świadomy konsekwencji.
John Burton
2012-02-17 17:23:58 UTC
view on stackexchange narkive permalink

Istnieją już kompilatory c ++ dla pic, na przykład http://www.sourceboost.com/Products/BoostCpp/Overview.html

Nie używałem tego i nic o tym nie wiem poza tym, że istnieje ...

spearson
2012-02-18 05:20:46 UTC
view on stackexchange narkive permalink

Uogólniając nieco twoje pytanie, istnieją procesory ARM, które są zbudowane dla rynku urządzeń wbudowanych, które zawierają MMU (jednostkę zarządzania pamięcią). Rozmiar pamięci i alokacja sprawiły, że języki takie jak java i c ++ były słabo osadzone. Ponieważ procesory wbudowane stają się coraz szybsze i bardziej wydajne, a pamięć staje się gęstsza i tańsza, wybór języka dostępny dla inżynierów rozwiązań wbudowanych zmienia się dramatycznie. 32-bitowy procesor ARM 600 MHz z MMU i kartą Flash 64G to świetny kandydat do aplikacji C ++. To, czy pasuje do definicji klasycznego procesora wbudowanego, to inna kwestia.

Ktc
2012-04-02 06:57:00 UTC
view on stackexchange narkive permalink

Prawdopodobnie tak ... ale i tak nie powinieneś ... C jest językiem wbudowanym i nie ma żadnych zalet używania C ++. A raczej zalety języka C znacznie przewyższają zalety C ++ dla rozwiązań osadzonych. Nie trać czasu.

  • jeśli wiesz, jak używać wskaźników do funkcji itp. Możesz kodować jak C ++, nie ma w tym problemu.
Pozwolę sobie być innego zdania. Możesz używać wielu funkcji C ++ (klasy, szablony, przeciążanie operatorów, odwołania) przy niewielkich lub zerowych kosztach wykonania. Tak, możesz zrobić to wszystko w prostym C z hackerskimi konstrukcjami, ale to męczy twój mózg i wolałbym używać C ++. (oczywiście wolałbym używać lepszego języka, ale wybrałbym kompilator C ++ w mgnieniu oka, zamiast zwykłego C.)
Classes = structs (bez wbudowanych metod, ale jeśli chcesz, możesz przechowywać wskaźnik funkcji w strukturze i wywołać to). Szablony = używasz tych ??? Przeciążenie operatora = tak. Też bym chciał. Referencje = wskaźniki, nie? W C przynajmniej możesz używać tylko „funkcji” C ++, które chcesz, bez martwienia się o generowanie nadmiernego kodu lub konieczność dołączania losowej dużej biblioteki, aby uzyskać coś do skompilowania.
Ja też się różnię.
Tak, szablony to niezwykle skuteczny sposób generowania niezawodnego i wydajnego kodu. Referencje są bardziej niezawodnym wskaźnikiem. Dzięki C ++ płacisz tylko za funkcje, których używasz. Myślę, że naprawdę musisz lepiej rozumieć C ++.
Chłopaki, przepraszam .. C to język embedded. Tak, możesz zrobić C ++, ale korzyści zawsze będą marginalne. Dobrze napisany kod C jest na szczycie każdego kodu C ++ każdego dnia tygodnia. To przynajmniej moje doświadczenie. Czytałem gdzieś, trudniej jest strzelić sobie w C ++, ale jak już to zrobisz, zabiera ze sobą całą nogę. Całkowicie się zgadzam. Kiedy jesteś blisko metalu, nie chcesz niekończących się abstrakcji, przeładowań itp. Najlepszym sposobem jest trzymanie się podstaw.
Nie wiem, co masz na myśli, mówiąc „C to język osadzonych”. Jasne, jest bardzo popularne. Chcesz powiedzieć, że to najlepszy możliwy język? Na pewno nie.
@Rocketmagnet 90% osadzonego kodu to C. Czy jest najlepszy? Nie wiem, ale jest najczęstszy i najłatwiejszy w utrzymaniu. To kwestia gustu, uważam, że C ++ jest niesmaczny dla embedded .. Uważam, że jest jeszcze bardziej niesmaczny w programowaniu aplikacji, są lepsze języki, lua, java itp. To kilka przykładów. Potrafię dobrze kodować, ale nie jestem programistą, więc na tym poprzestaję.
@Rocketmagnet: Wywołanie metody C ++, która może generować wyjątki, nałoży znaczny narzut, niezależnie od tego, czy metoda faktycznie rzuca.O ile nie wyłącza się wyjątków na całym świecie, nie sądzę, że istnieje wygodny sposób płacenia za nie tylko tam, gdzie są używane.
@Ktc: Przeciążenia mogą być bardzo pomocne przy pisaniu wydajnego kodu.Jeśli funkcja jest zwykle przekazywana 8-bitową wartość, ale czasami jest przekazywana 16-bitowa, posiadanie oddzielnych metod dla przypadków 8-bitowych i 16-bitowych (nawet jeśli pierwsza po prostu łączy się z drugą) spowoduje zapisanie dwóch instrukcji nazadzwoń do witryny.W przypadku niektórych projektów może się to bardzo szybko zwiększyć.Przeciążenia mogą ułatwić korzystanie z oddzielnych metod.Chciałbym, żeby komitet normalizacyjny C pozwolił na przeciążenie metod * statycznych * i * wbudowanych *;Tradycyjny sprzeciw wobec przeciążania był historycznie taki, że wymaga zniekształcenia nazwy, ale ...
... byłby to problem tylko dla nazw, które były dostępne za pośrednictwem zewnętrznego kodu.Ograniczenie przeładowania do funkcji statycznych i wbudowanych w żaden sposób nie utrudniłoby jego użyteczności, ponieważ plik nagłówkowy mógłby z łatwością powiedzieć `inline int foo (unsigned char x) {return foo_byte (x);} `i zamienia każde wywołanie na` foo () `, które przekazuje` unsigned char` na wywołanie `foo_byte ()`.
@Ktc: przynajmniej, dzięki ludziom takim jak ty, ludzie tacy jak ja mają pracę.A tak przy okazji, wydaje mi się dość dziwne, że nie promujesz asemblera nad C, bo wiesz, jest bliżej metalu.Przepraszamy, ale twoja odpowiedź i komentarze to czysty BS.


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...