Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Trzy porady, co zrobić, by mniej czasu marnować na debugowanie przy programowaniu MCU

ghost666 09 Dec 2022 12:16 1296 8
  • Inżynierowie oprogramowania wbudowanego uwielbiają rozwiązywać problemy. To właśnie podstawa, tego, co robią. Niestety jednym z największych ich mankamentów jest to, że tworzą oni wiele niedoskonałości, aby następnie stać się bohaterami, spędzając ogromną ilość czasu na ich usprawnieniu (debugowanie!). To dość typowe, bez przeszkód można znaleźć firmy, w których inżynierowie oprogramowania wbudowanego wykorzystują 20-40% czasu na samo tylko debugowanie kodu! Na szczęście istnieje wiele potencjalnych rzeczy, które zespoły mogą zrobić inaczej, aby ten period skrócić, zamieniając w jednocyfrową wartość procentową. W tym artykule przeanalizujemy kilka wskazówek dotyczących skrócenia okresu debugowania.

    Wskazówka nr 1 — uwzględnij rozwój oparty na testach (TDD)

    Programowanie sterowane testami to paradygmat pozwalający deweloperom na przyrostowe budowanie oprogramowania produkcyjnego, w którym polegają na weryfikacji, aby oceniać napisany przez siebie kod. Na przykład TDD pozwala programistom najpierw napisać przypadek testowy, sprawić, że zakończy się niepowodzeniem. A następnie stworzyć kod, który umożliwia zaliczenie. Proces jest dalej powtarzany dla kolejnych funkcji.

    Tradycyjnie twórcy oprogramowania wbudowanego piszą całe moduły kodu przed jego testowaniem. Możliwe jest wygenerowanie tysięcy linijek w ciągu kilku tygodni. Następnie, kiedy przychodzi czas na przetestowanie, gdzie jest problem, jeśli coś nie działa? Bóg wie! Deweloper musi skrupulatnie przejrzeć cały kod i odkryć, co stanowi mankament i oczywiście go naprawić. Wymagane może być do tego sporo czasu.

    Z drugiej strony, w przypadku programistów korzystających z TDD, jeśli zostanie popełniony błąd i znajdzie się on w kodzie, najbliższy przypadek testowy natychmiast o tym poinformuje! Ponieważ stopniowo piszą i jednocześnie testują oni swój kod, jest bardziej prawdopodobne, że dokładnie wiedzą, co zmienili i mogą błyskawicznie rozwiązać niedogodność. TDD może wydawać się bardziej pracochłonne, ale tworzy zbiór przypadków, które można uruchomić w testach regresji, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami. TDD dostarcza dwie pieczenie na jednym ogniu: skraca się czas debugowania i od razu zapewnia testy automatyczne dla całego kodu.

    Wskazówka #2 — rozwijaj możliwie jak najwięcej kodu poza docelową platformą

    Gdy projekt się rozpoczyna jednym z pierwszych odruchów niemal każdego dewelopera jest zaopatrzenie się w płytkę rozwojową i rozpoczęcie pisania kodu wbudowanego. Niestety w wielu przypadkach ten osadzony nie jest wyróżnikiem naszych aplikacji. Podczas gdy duża ilość kodu aplikacji ostatecznie musi wejść w interakcję ze sprzętem, wiele modułów można opracować poza platformą wbudowaną, tj. na komputerze, a nie mikrokontrolerze.

    Tworzenie kodu poza docelowym urządzeniem daje programistom sporo możliwości skrócenia czasu poświęcanego na każdy cykl debugowania. Na przykład zazwyczaj, aby napisać i przetestować go dla docelowego mikrokontrolera, programista musi:

    * Skompilować kod na docelową platformę (cross-kompilacja);
    * Rozpocząć sesję debugowania;
    * Zaprogramować urządzenie docelowe, np. przez SWD;
    * Uruchomić kod na właściwym układzie;
    * Sprawdzić, czy wszystko działa, uruchamiając całość w systemie (musi on również zawierać kod niskiego poziomu).

    Jeśli kod jest opracowywany na komputerze, deweloper musi go skompilować dla adekwatnej maszyny, a następnie użyć zestawu testów jednostkowych, emulatora lub niestandardowego programu w ramach zainicjowania. Jeśli problem zostanie znaleziony, naprawienie, ponowna kompilacja i uruchomienie jest znacznie szybsze. W przypadku wbudowanego celu, samo zaprogramowanie może dodać dziesiątki sekund do każdego cyklu, nie mówiąc już o pokusie wykonywania kodu krok po kroku.

    Istnieją określone błędy, które może spowodować tworzenie/debugowanie poza docelową platformą. Jednak mimo wszystko to podejście jest znacznie szybsze i wydajniejsze. Zamiast śledzić problemy przez system wbudowany, można je szybko wymusić lub określone zachowania w kodzie, określić przyczynę danych sytuacji, naprawić ją i przejść dalej. To prawda, że ​​niektóre rzeczy pojawią się dopiero na właściwej platformie wbudowanej, a nie na komputerze, jednak nadal nie ma ich na tyle dużo, by czynić takie ujęcie bezsensownym.

    Wskazówka #3 — opanuj strategie debugowania

    Najmniej wydajną metodą debugowania znaną ludzkości jest wykonywanie pojedynczych kroków przez wiersze kodu. Oczywiście... jest czas i miejsce, aby tak robić, ale często jest to po prostu bezwartościowe. Niestety, twórcy oprogramowania wbudowanego domyślnie stosują debugowanie za pomocą punktów przerwania i przeprowadzania pojedynczych kroków, aby lepiej sobie radzić. Programiści muszą opanować inne strategie dostępne w nowoczesnych mikrokontrolerach.

    Obecnie deweloperzy mają dostęp do co najmniej ośmiu różnych technik debugowania. Obejmują one od najprostszych do najbardziej złożonych:

    * Watch/Expressions: pozwala programiście na zbadanie rejestrów procesora i urządzeń peryferyjnych. Często mogą być używane do szpiegowania zmiennych, przeprowadzania obliczeń lub zatrzymywania procesora w przypadku zmiany.
    * Punkty przerwania: umożliwiają zastopowanie wykonywania procesora w określonym wierszu kodu. Mogą one służyć do ustawiania punktów z pomocą instrukcji warunkowych.
    * printf: zapewniają możliwość drukowania danych znakowych na zmapowanym interfejsie szeregowym. W zależności od implementacji może to mieć wpływ na wydajność w czasie rzeczywistym lub nie.
    * Asercje: są to instrukcje warunkowe wykorzystywane do weryfikacji założeń w określonym punkcie programu. Niepowodzenie często powoduje zatrzymanie procesora i podanie lokalizacji w kodzie i wiersza nieudanej asercji.
    * Profilowanie statystyczne: okresowe próbkowanie różnych rejestrów w aplikacji, które występują jednocześnie z jej uruchomieniem. Często nie wpływa na wydajność w czasie rzeczywistym. Na przykład można sprawdzać licznik programu (PC), aby zrozumieć, jakie moduły kodu są wykonywane.
    * Profilowanie danych: okresowe próbkowanie różnych lokalizacji pamięci, które zawierają zmienne dane. Profilowanie zasobów może być świetne, gdy jest używane z wizualizatorem w czasie rzeczywistym do monitorowania stanu systemu, zmian interesujących zmiennych i tak dalej.
    * Śledzenie zadań i danych: gwarantuje programistom możliwość obserwowania zdarzeń w aplikacji systemu operacyjnego w czasie rzeczywistym. W rezultacie można uzyskać wgląd w wydajność, opóźnienia zadań, czasy wykonywania i wiele więcej.
    * Śledzenie instrukcji: zapewnia sposobność rejestrowania każdej instrukcji przeprowadzanej na procesorze. Może to służyć do zrozumienia pokrycia kodu podczas testowania, debugowania problemów z kompilatorem i nie tylko.

    Opanowanie wszystkich tych technik i wiedza, kiedy ich użyć może znacznie ograniczyć zakres pracy przeznaczanej na debugowanie, gdy błąd dostanie się do systemu.

    Podsumowanie

    Można poświęcić dużo czasu na debugowanie oprogramowania wbudowanego. I czasami nie da się tego uniknąć, jednak programiści mogą obecnie czynić to częściej niż to konieczne. Przedstawiono powyżej w zarysie kilka obszarów, które można dokładniej zbadać, aby skrócić ten period. Jeśli dedykujecie więcej niż 20% swojego czasu pracy na debugowanie, warto wydzielić godzinę tygodniowo, aby określić, jakie zmiany można zacząć natychmiast wprowadzać do procesu tworzenia oprogramowania, by zminimalizować tę wartość.

    Źródło: https://www.embedded.com/3-tips-for-decreasing-time-spent-debugging/

    Cool? Ranking DIY
    About Author
    ghost666
    Translator, editor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    ghost666 wrote 11501 posts with rating 9721, helped 157 times. Live in city Warszawa. Been with us since 2003 year.
  • #2
    acctr
    Level 26  
    Do listy dobrych rad można dodać - pisz kod zgodnie z wzorcami, z podziałem na warstwy. To implikuje wskazówkę #2. Bez takiego podziału trudno wyodrębnić "logikę biznesową" spośród kodu machającego gpio.
  • #3
    Lukasr29
    Level 20  
    Niezła papka na wstępie... Przedstawione jakby w firmie pracowali tylko programiści i nikt więcej i nie robili nic więcej tylko pisali kod... Sytuacja ze wstępu raczej rzadko jest spowodowana przez programistów, taką sytuację powoduje nieodpowiedzialny zespół do zarządzania projektem (product owner / project manager / architekci / często też główni programiści - bo jest od nich zgoda na złe praktyki). Tam często można spotkać podejście że testy to nie kod funkcjonalny, nic nie wnosi itp, liczy się tylko to jak dużo funkcjonalności może dostarczyć zespół w czasie X, wtedy właśnie powstaje te tysiące linii kodu, bez testowania funkcjonalności w trakcie trwania projektu, w tragicznym całokształcie, bo przecież przetestuje się na koniec czy działa. Tak naprawdę wystarczy doliczyć 20% czasu na dopisanie testów jednostkowych, nawet bez myśleniu o TDD (ale takich sensownych, nie takie co sprawdzają czy 2+2=4), kilka % na testy funkcjonalne co jakiś czas i nawet podejście waterfall ma jakąś szansę na sukces.

    Co do samych porad - trochę są "podkolorowane" tu i tam ale co do zasady są dobre - im więcej dobrych praktyk i wiedzy w firmie / zespole tym lepiej dla wszystkich i dla projektów.

    -----
    Wiem że to tłumaczenie artykułu - odnoszę się do zawartej treści.
  • #4
    khoam
    Level 41  
    Lukasr29 wrote:
    Przedstawione jakby w firmie pracowali tylko programiści i nikt więcej i nie robili nic więcej tylko pisali kod...

    TDD to metodyka "zwinna" - piszą kod do wyczerpania budżetu, więc po co im testerzy ;)
  • #5
    DJ_KLIMA
    Level 19  
    A i tak zawsze przychodzi ktoś z księgowości i uwala testy, i szybko szybko na produkcje :)
  • #6
    __Maciek__
    Level 20  
    Tyle teorii .. czekam na artykuł z przykładami ..
  • #7
    jarek_lnx
    Level 43  
    Jak to czytam, to się zastanawiam, co było celem autora żeby takie coś napisać? Do kogo artykuł był skierowany? Raczej nie do elektroników czy programistów, bo za mało konkretów, tylko jakiegoś managera który wszędzie widzi marnowanie czasu i poganianie jest jego życiową pasją :)

    Początek brzmi jakby ludzie robili bugi celowo, a tytuł jest clickbajtowy.

    Pytanie do tłumacza, czym się kierujesz wybierając teksty do przetłumaczenia?
  • #8
    Nepto
    Level 16  
    ghost666 wrote:
    Inżynierowie oprogramowania wbudowanego uwielbiają rozwiązywać problemy. To właśnie podstawa, tego, co robią. Niestety jednym z największych ich mankamentów jest to, że tworzą oni wiele niedoskonałości, aby następnie stać się bohaterami, spędzając ogromną ilość czasu na ich usprawnieniu (debugowanie!). To dość typowe, bez przeszkód można znaleźć firmy, w których inżynierowie oprogramowania wbudowanego wykorzystują 20-40% czasu na samo tylko debugowanie kodu!


    W tym momencie przestałem czytać, bo to brzmi jak jakiś bełkot, inżynierowie tworzący problemy, żeby potem je rozwiązywać? No to może trzeba zwolnić inżynierów, problemy same znikną.

    W oryginalnej wersji językowej brzmi to tylko odrobinę lepiej, bo używana jest forma "my"
    Quote:
    Engineers love to solve problems. It’s what we do. Unfortunately, one of the biggest problems with embedded software engineers is that we create a lot of our problems and then make ourselves the heroes by spending ungodly amounts of time fixing them (Debugging!).


    No dobra, spojrzałem jednak na resztę artykułu i to są takie wysokopoziomowe gadki wujka dobra rada typu "lepiej być zdrowym, młodym i bogatym niż chorym, starym i biednym".

    Weźmy chociażby TDD. Oczywiście, że dobrze jest i należy pisać testy razem z kodem funkcjonalności, bo to wymusza pisanie lepszego kodu, ale diabeł tkwi w tym, jak to robić efektywnie. Jaki framework do testów użyć? Jak będą one odpalane automatycznie? Co w przypadku, kiedy część funkcjonalności zależy od wartości czytanych ze sprzętu, w jaki sposób rozwiązane jest podawanie wartości oczekiwanych od sprzętu (czy jest dobry polski odpowiednik słowa "mock")? Czy mamy modele symulacyjne sprzętu i możemy je używać w testowaniu? To są ciekawe pytania, ale niestety nic o nich w artykule nie wspomniano.
  • #9
    acctr
    Level 26  
    jarek_lnx wrote:
    Raczej nie do elektroników czy programistów, bo za mało konkretów

    W opisie dobrych praktyk zy metodologii nie podaje się konkretów. Artykuł dotyczy debugowania i tego co można zrobić aby debugowanie skrócić.
    Konkretny przypadek może być taki, że pracujesz nad jakimś układem z mcu, gdzie siedzi już 32 kB kodu. Po kolejnym wgraniu softu mcu zaczyna się restartować po kilku minutach pracy. I co wtedy robisz?
    Nepto wrote:
    czy jest dobry polski odpowiednik słowa "mock"

    Imitacja.