7 porad dotyczących debugowania oprogramowania wbudowanego

Debugowanie to jedno z zadań, którego każdy programista chce uniknąć, ale jest niestety koniecznym złem w tworzeniu oprogramowania.
W rzeczywistości, projekty oprogramowania osadzonego pochłaniają średnio ponad 20% całkowitych nakładów na samo debugowanie.
Kiedy nadejdzie czas na podwinięcie rękawów i rozpoczęcie sesji debugowania, oto kilka wskazówek, które mogą okazać się bardzo pomocne.
Tip # 1 – Podejmij kontrolowane malutkie kroki
Kiedy błąd wkrada się w oprogramowanie wbudowane, pierwszym instynktem programistycznym jest często „wskoczenie” do kodu i rozpoczęcie wprowadzania zmian.
Zamiast dokonywać zmian w sposób kontrolowany i ukierunkowany, podejście programisty jest zwykle chaotyczne i zupełnie przypadkowe.
Wbudowane oprogramowanie nie jest „dzikim Zachodem”. Rozwiązanie nawet najprostszych błędów powinno obejmować przeglądanie dostępnych danych, ich ocenę, postawienie hipotez dotyczących najbardziej prawdopodobnej przyczyny, aktualizację kodu, a następnie testowanie aktualizacji.
W przypadku, gdy zmiana nie rozwiązuje problemu, należy przynajmniej odkryć nowe dane, co pomoże powtórzyć proces.
Tip # 2 – Zwiększenie gęstości asercji
Makro ASSERT jest doskonałym narzędziem, które zwraca komunikat o błędzie w czasie wykonywania, jeśli warunek jest fałszywy. Programiści mogą używać tego makra do sprawdzenia, czy założenia w ich kodzie są prawdziwe.
Co zaskakujące, wielu programistów nie poświęca czasu na umieszczanie asercji (forma zdaniowa w danym języku, która zwraca prawdę lub fałsz) w swoim kodzie. Gęstość makra ASSERT w podstawie kodu często może być różnicą pomiędzy długimi i bolesnymi sesjami debugowania lub pułapką nieudanego założenia w momencie, gdy się to stanie.
Predykat ASSERT może pomóc programistom natychmiast odkryć błędy lub nieprzewidziane założenia. Jaka jest gęstość ASSERT w bazie kodu?
Tip # 3 – Użyj rejestratora danych
Informacja o działaniu oprogramowania jest największym narzędziem, jakie może mieć inżynier podczas debugowania wbudowanego oprogramowania. Posiadanie informacji o wydajności, na przykład, kiedy zadania są uruchamiane i kończone, czy są one zastępowane i podobne szczegóły mogą być krytyczne.
Rejestr podjętych działań jest świetnym sposobem dla programisty na uzyskanie wglądu w zachowanie oprogramowania. Zapis może być tak prosty jak bufor pamięci RAM, plik zapisany na zewnętrznej pamięci flash lub złożony, jak zakodowane dane przesyłane do zdalnej lokalizacji.
Tip # 4 – Użyj zaawansowanych punktów przerwania
Programiści znają standardowe punkty przerwania, które można włączyć w IDE, po prostu klikając dwukrotnie lewy margines kodu. Jednak wiele środowisk IDE (Integrated Development Environment) ma również znacznie bardziej zaawansowane możliwości breakpointów (punkty przerwań), których programiści rzadko używają.
Przykładem zaawansowanego punktu przerwania jest ustawienie linii przerwania, gdy zmienna osiągnie określoną wartość.
Korzystanie z zaawansowanych punktów przerwania może drastycznie zmniejszyć czas debugowania i sprawić, że trudne do uchwycenia błędy będą znacznie łatwiejsze do wykrycia.
Tip # 5 – Ponowne przejrzenie arkuszy danych
Debugowanie urządzeń peryferyjnych może być szczególnie trudne. Nowoczesne mikrokontrolery mogą mieć dziesiątki rejestrów zaangażowanych w tworzenie jednego urządzenia peryferyjnego, a te ustawienia urządzeń peryferyjnych nie zawsze są oczywiste lub dobrze udokumentowane.
Co gorsza, szczegółowe informacje dotyczące prawidłowego ustawienia urządzeń peryferyjnych zwykle nie mieszczą się w jednym arkuszu danych.
Zamiast tego informacja ma formę „bułki tartej” rozproszonej po rodzinie i peryferyjnych arkuszach danych, a czasami nawet w danych aplikacyjnych. Patrzenie tylko na jeden dokument to za mało. Gdy sprzęt działa nieprawidłowo, musisz wielokrotnie sprawdzać arkusze danych.
Tip # 6 – Konieczność monitorowania stosu wywołań
Programiści czasami mają wątpliwości, w jaki sposób dotarli do konkretnej linii kodu.
Środowiska IDE zawierają okno stosu wywołań, które może ujawnić dokładnie te informacje. Stos wywołań pokazuje, jakie funkcje zostały wywołane i w jakiej kolejności, ujawniając informacje, które mogą być bardzo przydatne do śledzenia błędu.
Tip # 7 – Zrób sobie przerwę
Debugowanie może być wymagającym wysiłku ćwiczeniem. Nurkowanie w głąb działania oprogramowania i sprzętu może dać programiście widzenie tunelowe (zawężone spojrzenie).
Programista czasami musi cofnąć się, przechodząc do innego zadania lub robiąc sobie przerwę. Odejście od systemu poprzez pójście na spacer lub zrobienie czegoś relaksującego pozwoli podświadomości pracować nad rozwiązaniem, podczas gdy świadomy umysł odpoczywa, więc gdy nadejdzie czas, aby zacząć ponownie przeglądać kod, pojawią się dodatkowe spostrzeżenia.
Wniosek:
Niezależnie od tego, czy poświęcasz dużo czasu na debugowanie, czy bardzo niewiele, faktem jest, że twórcy oprogramowania wbudowanego nie mogą tego uniknąć. Korzystanie z porad zawartych w tym artykule może pomóc w zwiększeniu skuteczności debugowania, a przez to nieco „smaczniejszym”.
Autor: Jacob Beningo

pełny materiał w pliku pdf

Komentarze z Facebooka

Komentarze obecnie - OFF.