Czego inżynierowie oprogramowania układowego mogą się nauczyć od inżynierów oprogramowania? [zamknięte]

Pracowałem zarówno jako inżynier oprogramowania wbudowanego, jak i jako programista. Będąc w obu światach, nauczyłem się, że bez względu na to, jak mało zasobów ma Twój system i jaki język programujesz, istnieje wiele rzeczy, które mogą ułatwić Ci życie.

Pierwszą rzeczą są narzędzia, których używasz. W oprogramowaniu wbudowanym masz do czynienia tylko z kompilatorem/linkerem przez większość czasu. Jest ich więcej. Narzędzia Diff, wyrażenia regularne język skryptowy, narzędzia do dokumentacji oszczędzają dużo czasu.

Kolejną rzeczą jest jakość kodu. Trzeba przestrzegać konwencji stylów, przechodzić regularne cykle refaktoryzacji i ogólnie pamiętać, że czytanie kodu odbywa się częściej niż pisanie kodu i naprawdę opłaca się mieć bardziej czytelny kod.

Czasami w oprogramowaniu wbudowanym brakuje nam fazy projektowania. Projekty Embedded zazwyczaj nie są tak duże jak desktopowe / serwerowe, ale to nie jest usprawiedliwienie dla nie robienia WŁAŚCIWEGO design.

Oprogramowanie musi być testowane samodzielnie, a nie tylko jako część urządzenia. To naprawdę oszczędza dużo czasu, aby zbudować symulator oprogramowania systemu, tylko do testowania, że oprogramowanie spełnia wymagane specyfikacje. Jest to znacznie droższe, gdy całość, sprzęt i oprogramowanie są gotowe.

• Kontrola Źródła
• testy jednostkowe (TDD)
• Continuous integration (or nightly builds)
• śledzenie błędów

Inżynierowie oprogramowania, z którymi pracowałem, nie robią żadnego z nich.

Testy jednostkowe mogą nie mieć zastosowania do wszystkich rodzajów oprogramowania układowego. Wyobrażam sobie, że trudniej jest przetestować coś, gdy działa na fizycznym sprzęcie. Zależy, czy masz dostępne emulatory.

Zakładając, że przez "inżynierów oprogramowania" masz na myśli "inżynierów oprogramowania wbudowanego", moja odpowiedź brzmiałaby: oni są inżynierami oprogramowania, więc powinni - tam, gdzie to możliwe - robić te same rzeczy, co każdy inny inżynier oprogramowania.

Oczywiście pisanie oprogramowania dla systemów wbudowanych wymaga różnych umiejętności, takich jak szczegółowa znajomość procesora docelowego i umiejętność radzenia sobie z ograniczonymi zasobami (w porównaniu z komputerem PC lub podobnym).

Jak wspomnieli inni, testowanie jednostkowe jest skomplikowane przez fakt, że może to być wykonane na symulatorze działającym na komputerze, który choć jest bardzo przydatny, nigdy nie może zastąpić dokładnego testowania rzeczywistego systemu - zwłaszcza biorąc pod uwagę asynchroniczny charakter zdarzeń, którym podlega system wbudowany.

Jednym z moich obaw, dlaczego oprogramowanie wbudowane może wydawać się "za krzywą", jest to, że inżynieria oprogramowania-a w związku z tym oprogramowanie wbudowane-nie jest ogólnie nauczane w żadnej głębi na temat dyplom inżyniera elektronika. Biorąc pod uwagę, jak wiele z kariery inżyniera elektronicznego może być spędzone kodowanie w dzisiejszych czasach, wydaje się to ogromnym niedopatrzeniem.

Na szczęście są tacy, którzy próbują to nadrobić. Polecam lekturę artykułów Jacka Ganssle ' a (na jego stronie internetowej, oraz w jego regularnej rubryce na embedded.com).

DODATKOWO, MISRA-C został stworzony jakiś czas temu, aby uniknąć typowych źródeł błędów w C oprogramowanie dla przemysłu motoryzacyjnego, a jego od tego czasu został przyjęty przez wielu w świecie oprogramowania wbudowanego. Dodaj kontroler analizy statycznej, taki jak PC-Lint , a już w jakiś sposób ulepszyłeś swój kod.

Dostawcy narzędzi również nie pomogli, w wielu przypadkach tworząc własne IDE, kiedy być może lepiej byłoby skoncentrować się na kompilatorze i debugerze, a pozostawić IDE innym, np. Eclipse.

Nawiasem mówiąc, więcej na temat nieużywania C++ w systemy wbudowane zobacz to pytanie .

Wreszcie: ponieważ inżynierowie oprogramowania układowego są inżynierami oprogramowania, mamy do czynienia z wieloma tymi samymi problemami, wyzwaniami i problemami, więc powinniśmy korzystać z tych samych zasobów; w końcu jest ich mnóstwo, a ty czytasz jedną z nich!

Niektóre z innych stron internetowych, które często zawierają:

• Stack Overflow blog i podcast
• Dziennik WTF
• Talk About Jakość
• Kodowanie Horror
• Secret Geek
• Joel on Software
• inny Stack Overflow blog ; ten jest dedykowany systemom embedded.

EDIT: w odpowiedzi na komentarz Gabe 'a:" jakie narzędzia powinniśmy dostosować?", kilka przykładów nasuwa się na myśl:

IDE niezależne od kompilatora: Istnieje mnóstwo IDE dla C, ale z tego co wiem, nieliczne z nich mogą być wykorzystane do ich nielicznego potencjału bez kompatybilnego kompilatora. Chciałbym, aby zarówno Programiści kompilatora, jak i Programiści IDE zbierali się tak, aby idealnie, każdy kompilator mógł być używany z dowolnym IDE.

W przypadku braku kompatybilnego kompilatora, chciałbym móc używać PC-Lint (lub jego odpowiednika) jako mojego "oficjalnego" kompilatora z wybranym przeze mnie IDE.

Symulacja i modelowanie: narzędzia symulacyjne, takie jak Simulink umożliwiają symulację, modelowanie i testowanie oprogramowania dla komputerów PC i niektórych procesorów wbudowanych wyższej klasy. Takie narzędzia byłyby równie przydatne dla mniejszych chipów, więc miło byłoby zobaczyć je rozszerzone na ten obszar rynku.

PS: kolumna Jacka Ganssle ' a w tym tygodniu nosi tytuł: " co wyróżnia embedded?", i tak jest (luźno) związane z powyższym pytaniem.

Nie wiem, jaki stopień oprogramowania jest uważany za oprogramowanie układowe( bios, sterownik lub narzędzia), ale standardowa skarga, którą słyszę, jest to, że interfejs jest niestandardowy. Uświadomienie sobie, że interfejs ma znaczenie i że powinien być zgodny z niektórymi standardami lub tradycją byłoby dobrą rzeczą.

Jeśli chodzi o C++, to jest zrozumiałe, aby wahać się, aby dostać się do niego, ponieważ jest dużo narzutu w porównaniu do C. C jest prawie jak język asemblacji z libc, podczas gdy w C++ nawet proste wywołanie funkcji może być wirtualne. Implementacja pełnego środowiska wykonawczego C++ nie może być tak łatwa, biorąc pod uwagę złożoność języka.

Jest zbyt wiele rzeczy, aby wymienić w kategoriach "najlepszych praktyk" rozwoju oprogramowania (nienawidzę tych słów). Dlaczego nie zacząć od The Joel Test: 12 Kroków do lepszego kodu.

Test Joela

1. Czy używasz kontroli źródła?
2. Czy można zbudować w jednym kroku?
3. czy tworzysz codzienne budowle?
4. do you have a bug baza danych?
5. czy naprawiasz błędy przed napisaniem nowego kodu?
6. Czy masz aktualny harmonogram?
7. masz spec?
8. czy programiści mają ciche warunki pracy?
9. Czy używasz najlepszych narzędzi, które można kupić za pieniądze?
10. Czy macie testery?
11. Czy nowi kandydaci piszą kod podczas rozmowy kwalifikacyjnej?
12. czy wykonujesz testy użyteczności przedpokoju?

Inżynieria oprogramowania jest dość szeroka. Od PIC do DSP wszystkie mają różny stopień zasobów fizycznych. W dzisiejszych czasach DSP są dość potężne (porównywalne z procesorami ~5 lat), mogą obsługiwać dużą ilość pamięci itp. Ale znowu masz zdjęcia, które działają z kilkoma kilobajtami. Bardziej skromne zasoby, programista musi użyć pomysłowych hacków, aby uzyskać jak najwięcej z urządzenia. Skupiamy się na "get it to work", a nie na "write elegant code".

What I would like aby zobaczyć to dobre narzędzia do zarządzania projektami, które zawierają kod, a także dokumenty, ponieważ musisz odnosić się do wielu arkuszy danych, dokumentów projektowych, które są rozrzucone po sieci i na blobach e-mail itp..

Chciałbym również zobaczyć lepsze narzędzia dev dla DSP (ti: proszę przekazać CCS komuś, kto jest dobry w tworzeniu IDE), i więcej twórców bibliotek korzystających z C++ (patrzę na Ciebie ATEME) do budowania lepszych bibliotek.

A także inżynierowie sprzętu, aby lepiej oceniali obiekt Orientacja, a nie wygadywanie się, "jeśli to C++ to będzie wolno".

Pozwól, że najpierw zajmę się założeniem w twoim pytaniu. Zakłada się, że inżynierowie oprogramowania wbudowanego (ESE) nie znają lub nie są świadomi nowoczesnych praktyk inżynierii oprogramowania i muszą uczyć się nowych praktyk. To założenie powinno być odrzucone od razu. Uważam, że można znaleźć taki sam rozkład statystyczny ESE, którzy utrzymują swoje umiejętności i techniki na bieżąco, jak niezabezpieczone SEs.

Więc może twoje pytanie stanie się tablicą pytań typu:

1. Dlaczego czy ESEs używa osobnego edytora kodu i kompilatora wiersza poleceń, a nie IDE?
2. Dlaczego C jest preferowane od C++ w większości projektów wbudowanych?
3. Dlaczego w świecie embedded nie ma tyle eksperymentów w praktykach programistycznych?

Poniższe akapity odpowiadają na te pytania.

1. ESE zwykle używają określonego edytora kodu, ponieważ jest to osobiste preferencje lub to, co jest używane przez jego firmę. Idy nie są tak powszechne, ponieważ ESEs współpracuj bardzo blisko z silikonem i nie wszyscy producenci chipów opracowują IDE dla swojej linii chipów. Tylko chipy, które osiągają najwyższą penetrację rynku, takie jak ARM, mają wystarczająco dużo rozmachu, aby uzasadnić rozwój narzędzi opartych na IDE. Co więcej, IDE nie zapewnia tak dużej pomocy ESE, jak na przykład deweloperowi komputerów. Ide pomagają w tworzeniu kleju do GUI lub wypełniania kodu dla dużych interfejsów API; żaden z nich nie jest powszechnie spotykany lub tak standardowy, jak w osadzony świat.

2. Jestem pewien, że są lepsze zapisy, dlaczego C jest preferowane niż c++ w systemach wbudowanych, niż mogę nadrobić na miejscu. Krótko mówiąc, używasz tego, co działa. C działa i jest bardziej powszechne (więcej programistów zna C niż C++). Innym powodem może być to, że metodologia OO została opracowana, aby pomóc programistom w rozwiązywaniu dużych problemów poprzez abstrakcję rozwiązania do zarządzalnych obiektów koncepcyjnych. W świecie osadzonym problemy są zazwyczaj do jak najmniejszego problemu (i rozwiązania), tak aby system wbudowany stał się bardziej niezawodny dzięki mniejszej bazie kodu.

3. Jest mniej eksperymentów ze strony ESE, ponieważ produkt wbudowany, w ogóle, musi być znacznie mniej podatny na błędy i mieć większą niezawodność niż program komputerowy. Oznacza to sztywne stosowanie sprawdzonych praktyk i więcej czasu spędzonego na testowaniu. Dlaczego? Ponieważ często nie ma wykonalnej ścieżki do aktualizacji oprogramowania wbudowanego urządzenie; jest to albo niemożliwe ze względu na to, że system jest wdrażany poza zasięgiem, albo niewykonalne ze względu na koszt aktualizacji milionów urządzeń.

Podsumowując, ESE używają narzędzi i praktyk, które najlepiej odpowiadają ich potrzebom, tak jak nie wbudowane SEs. jako praktykujący ESE, wierzę, że dyscyplina oprogramowania wbudowanego różni się znacznie bardziej niż moi przyjaciele spoza ESE uważają, że jest. Tak więc pozorna rozbieżność praktyk programistycznych nie jest kwestią konieczności uczenia się nowoczesne praktyki, ale nie-Esy muszą zrozumieć, jak różne jest programowanie wbudowane.

Automatyczne testy
Nie skanuj wizualnie wyjść symulacji, aby sprawdzić, czy wszystko jest w porządku. Potrzebujesz kompleksowego zautomatyzowanego testu, ponieważ zawsze będziesz czegoś brakowało w tej masie przebiegów.

Kontrola Wersji
Nie będziesz pamiętał, jaka była wersja robocza. Użyj oprogramowania do kontroli wersji, aby wiedzieć, czym zaprogramować tę płytę.

Śledzenie Błędów
Prędzej czy później zapomnisz. Dziennik błędów powinien zawiera wersję (Patrz Kontrola wersji), w której problem został wykryty po raz pierwszy oraz wersję, w której został naprawiony.

UPS myślałem, że masz na myśli firmware jak w FPGA, ale to samo dotyczy oprogramowania wbudowanego. Jeśli masz już te procesy w miejscu great else zapomnij o unconventional approaches, dopóki nie uzyskać podstawy prawo.

To chyba trochę wyrwane z kontekstu.
Krótkie odniesienie do kolumny firmware w Embedded,

• Bug-killing standards for firmware coding
• Niektóre strony przechodzą do artykułu, dziesięć zasad usuwania błędów

Zawsze znalazłem dobre artykuły na temat inżynierii oprogramowania układowego w Embedded.
Które zapewne wielu zainteresowanych tym pytaniem również...