Systemy Wbudowane. Kompilator

    Uwaga! W artykule wyrażono opinie w których porównuje się ze sobą marki i ich produkty. Opinie tu zawarte są wyłącznie prywatną opinią autora i mają na celu jedynie określenie jak odbiera to autor-inżynier zajmujący się na co dzień tego typu zagadnieniami.

    Oprogramowanie wbudowane, bo tak na ogół nazywa się programy pisane z przeznaczeniem do mikroprocesorów lub ogólniej urządzeń elektronicznych, jest to zbiór funkcji dzięki któremu możemy zarządzać zasobami dostępnymi z poziomu mikroprocesora.

    Podobnie jak na komputerach PC tak i tu używa się języków programowania takich jak C, C++, Pascal czy Basic. Można również tworzyć oprogramowanie w asemblerze, jednak dzięki kompilatorom języków wysokiego poziomu teraz nie jest to już koniecznością.

    Nie inaczej jest w przypadku zaprojektowanego w pracy urządzenia pomiarowego. Wprawdzie urządzenie nie posiada żadnego systemu operacyjnego, jednak dzięki bogatej bibliotece funkcji kompilatora, programista nie powinien narzekać na ograniczenia wynikające z użytej architektury.

    Wybierając procesor jaki zostanie użyty w projekcie urządzenia należy zwrócić uwagę na zagadnienia opisane w rozdziale dotyczącym projektowania PCB ale również należy szczególnie przeanalizować zagadnienia związane z tworzeniem oprogramowania na dany procesor. Należą do nich:

• Czy procesor jest dostatecznie wydajny. Najłatwiej jest to sprawdzić poprzez zaopatrzenie się w darmową lub ewaluacyjna wersje kompilatora i symulatora. Następnie należy przygotować kilka krytycznych czasowo funkcji. W tym momencie pozostaje już tylko programowe przesymulowanie skompilowanego kodu i określenie czy wyniki mieszczą się założeniach projektu
• Czy istnieje kompilator C dla układu. Na ogół każdy dostawca procesorów zapewnia również kompilator dla języka wysokiego poziomu. Ze względu na dominującą pozycję języka C to właśnie ten język jest najczęściej wspierany
• Czy procesor posiada wsparcie do debugowania. O ile sam procesor posiada wbudowaną w krzem jakąś formę „On-Chip Debug” to najczęściej dostawca układu zapewnia również wsparcie do debugowania dla przynajmniej jednego kompilatora/symulatora.
  O debugerze ogólnie można powiedzieć tyle, że jest to cecha narzędzi programistycznych bez których można się obejść. Jednak są sytuacje gdzie bezpośredni wgląd w rejestry procesora i możliwość ich modyfikacji znacząco skraca czas projektowania. Tak więc decydując się na procesor należy określić czy w sytuacjach awaryjnych będzie możliwe użycie którejś z form debugowania w sprzęcie
• Koszt narzędzi programistycznych. Kompilator C i C++ RealView firmy ARM wraz z symulatorem i sprzętowym debugerem kosztuje duuuuuużo dolarów. Inne firmy takie jak Keil czy IAR Systems są alternatywą ale też oferują inne możliwości i w mojej ocenie wszystkie one są warte swojej ceny ale, ale dla kogoś Kto chce zredukować koszty do minimum to na pierwszy rzut oka sprawa wygląda nieciekawie. Jednak na szczęście jest darmowy kompilator gcc, który swoimi niektórymi cechami przewyższa kompilatory opisane wcześniej. Istotną wadą gcc jest stosunkowo słabe wsparcie dla debugowania. Oczywiście istnieje gdb, różne postacie sprzęgów do interfejsu procesora oraz graficzne nakładki, jednak trudno znaleźć stabilne i wydajne połączenie tych narzędzi
• Czy istnieje wsparcie techniczne w przypadku wykrycia błędu w narzędziach programistycznych. Często zadawane pytanie brzmi „po co projektować kompilator skoro istnieje darmowe sprawdzone rozwiązanie?” Owszem, na pierwszy rzut oka taka inwestycja nie ma sensu. Jednak firmy projektowe na ogół kładą duży nacisk na wsparcie w przypadku wykrycia błędu w kompilatorze/symulatorze. W przypadku wykrycia błędu komercyjne firmy starają się usunąć usterkę jak najszybciej. Podobnie jest gdy potrzebna jest nowa cecha do kompilatora czy symulatora. Reakcja firm na ogół jest natychmiastowa. Często wiąże się to ze sporym wydatkiem jednak w firmie czas dość łatwo da się przeliczyć na zyski lub straty. W przypadku gcc wygląda to nieco inaczej

    Poza wymienionymi cechami są również inne takie jak wsparcie dla C++, udostępnienie graficznego środowiska, rodzaj interfejsu do sprzętowego sprzęgu itp. Jednak są to sprawy mniej istotne i mają dopiero znaczenie przy bardziej zaawansowanych pracach.

Podsumowanie i literatura:

Pozycje wykorzystane bezpośrednio do opracowania treści artykułu:
    [1] brak

Autorem artykułu jest Krzysztof Fijak