Strona 1 z 1

Debugowanie oprogramowania

: piątek 04 sie 2017, 19:06
autor: StaryAnoda
Hej

Macie jakieś materiały na temat debugowania oprogramowania z naciskiem na mikrokontrolery?
Pytam gdyż debuger w tych środowiskach bazujących na Eclipse nie ma dużo funkcji (a może ma wszystkie wystarczające ? Tylko mi się wydaję, że jest ich mało).
Umiem odczytać wartości zmiennych, założyć pułapkę programową co jeszcze daję nam debuger ?
Oprócz tego że widzimy gdzie program zatrzymuję się ?
Czy jest na przykład możliwość podglądu niektórych zmiennych bez zatrzymywania programu ?
Czy jest możliwość podglądania zawartości rejestrów ?

Re: Debugowanie oprogramowania

: piątek 04 sie 2017, 19:54
autor: Antystatyczny
StaryAnoda pisze:Czy jest na przykład możliwość podglądu niektórych zmiennych bez zatrzymywania programu ?

Jest
StaryAnoda pisze:Czy jest możliwość podglądania zawartości rejestrów ?

Jest

Poza tym można zmieniać zawartość zmiennych i rejestrów. Np. zaświecać lub gasić bity w rejestrach, wywoływać w ten sposób przerwania (flagami) i mnóstwo innych możliwości. Ja programuję hobbystycznie i wykorzystuję dobrodziejstwa debuggera zaledwie w promilu. Zakładam pułapki (nawet tych warunkowych nie używam), podglądam zmienne i rejestry, a czasem manipuluję bitami w rejestrach. No i chyba tyle...
Tutaj musiałby się wypowiedzieć jakiś fachowiec, który zawodowo korzysta z takich narzędzi.

Re: Debugowanie oprogramowania

: piątek 04 sie 2017, 20:05
autor: StaryAnoda
O modyfikacja wartości zmiennych i rejestrów to wiem, a w jaki sposób podglądać zmienne w czasie rzeczywistym ?

Re: Debugowanie oprogramowania

: piątek 04 sie 2017, 20:07
autor: Antystatyczny
W Atollicu tego nie używałem (nie miałem takiej potrzeby), ale Acid ostatnio bez problemu z tego korzystał. Proponuję go "pomolestować", by w kilku słowach opisał, jak się z tego korzysta.

Re: Debugowanie oprogramowania

: piątek 04 sie 2017, 20:16
autor: StaryAnoda
Acid jutro od rana będzie programował, więc pewnie nie będzie stanowiło problemu zrobić parę screenów z okna debugera projektu nad którym aktualnie pracuję :)

Re: Debugowanie oprogramowania

: piątek 04 sie 2017, 22:40
autor: dambo
Atollic niestety dużo fajnych opcji ma zablokowanych w darmowej wersji. Można napisać do producenta o 30dniową wersję testową.

Fajnym narzędziem do podglądu działania aplikacji jest STMStudio.

Re: Debugowanie oprogramowania

: piątek 04 sie 2017, 23:46
autor: inż.wielki
Jeżeli pracujesz w linuxie to proponuje zapoznać się z narzędziem "gdb" oraz jego wersją konsolowo-okienkową "gdbtui" :) Jeżeli miałbyś jakieś pytania albo nie wiesz jak to ugryźć to pisz, postaram się wtedy wyjaśnić pokrótce, jak to uruchomić, jak się podłączyć oraz jak wykonać podstawowe operacje :)

Pozdrawiam

Re: Debugowanie oprogramowania

: sobota 05 sie 2017, 00:24
autor: mokrowski
gdb, pułapki sprzętowe i czytanie noty. Tyle już żółci wylałem na narzędzia IDE->zintegrowane_dbg_GUI że... mam dość.. "Gołe gdb" jest świetne. Daje się skryptować, łączy ze zdalnym celem, ma możliwość definiowania makr. Np. dla C++ to jak najbardziej potrzebna właściwość.

CLI nie jest takie złe. Przecież CLI można przetłumaczyć jako Całkiem Ludzki Interfejs :-)

Re: Debugowanie oprogramowania

: sobota 05 sie 2017, 10:53
autor: StaryAnoda
Ok trochę mi się rozjaśniło.
inż. mały chwilowo nie mam komputera z linuxem, ale jak będę miał to się przypomnę,
W dalszym ciągu czekamy na Acid-a :)

Jeszcze jedno pytanie czy to prawda, że debugowanie oprogramowania pod RTOS-em jest bardziej trudne ?

Re: Debugowanie oprogramowania

: sobota 05 sie 2017, 11:11
autor: dambo
W Atollicu są opcje podglądu stosów dla tasków we FreeRTOSie, jakby menedzer ile % zużycia mają poszczególne itp... ale w płatnej wersji.

To tu pytanko do wielkiego i mokrowskiego - dla mnie jak na po breakpoincie chcę podejrzeć wartość zmiennej w zupełności wystarczy możliwość z atollica oferująca wstawienie beakpointa i podglądu kilkoma kliknięciami. I wtedy wklepanie w konsolę trwa dłuzej - na jakim etapie/przy jakich zastosowaniach już bardziej warto tylko z konsoli? Bo jak przeglądałem poradniki o gdb itp to wszystko pokazują na prostym programie z ifem, pętlą i printami, a gdzie tu przełożenie na prawdziwe bardziej rozbudowane projekty?...

Jakieś testy jednostkowe w ten sposób też kodzicie?

Re: Debugowanie oprogramowania

: sobota 05 sie 2017, 13:22
autor: mokrowski
Hmm... odpowiedź jest troszkę bardziej skomplikowana niż "co wybrać". Co do zasady, badania (MIT, MS, IBM.... i chyba QSM tego ostatniego nie jestem pewien) doprowadziły do wniosku że znalezienie błędu technikami debugowania i technikami testu to 6:1. Czyli na debugowanie poświęcisz 6 x więcej czasu niż na znalezienie błędu testem. Stąd nie optymalizuję szczególnie pracy z debuggerem jeśli mam testy i preferuję test ponad debugowanie :-)
Jest jednak pewna kategoria testów które dobrze wykonuje się debuggerem. To są testy wielowątkowości, wyścigu danych, blokad i innych prymitywów synchronizacyjnych. Wtedy skryptowanie debuggera bardzo pomaga.
Nie sądzę także że "wsparcie RTOS'a w moim IDE" może być dla mnie osobiście "killer-ficzerem" danego IDE. Jak nie wspiera, piszę skrypt debuggera który wyświetli mi strukturę :-) Tym bardziej że ostatnio gdb ma dobre wsparcie w postaci skryptowania pythonem.

Reasumując IDE traktuję jako wysokopoziomowego zarządcę kodu. Debugger i tak wyciągam wtedy gdy testem nie jestem w stanie zrozumieć co działa inaczej niż powinno więc CLI w debuggerze mi nie przeszkadza. No ... ale to moje przyzwyczajenie.... i nie znaczy to że GUI z debuggerem jest złe.... szczególnie jeśli ... działa :-)

Re: Debugowanie oprogramowania

: sobota 05 sie 2017, 13:46
autor: dambo
a może kiedyś podzielilibyście się taką podstawową wiedzą na temat właśnie debugowania/testów z punktu widzenia jak to wygląda w firmach itp? Wydaje mi się, że cieszyłoby się to sporym zainteresowaniem

Re: Debugowanie oprogramowania

: sobota 05 sie 2017, 13:48
autor: mokrowski
A precyzyjniej... Co Cię dokładniej @dambo interesuje?

Re: Debugowanie oprogramowania

: sobota 05 sie 2017, 13:58
autor: dambo
Faktycznie tak będzie najlepiej, więc od siebie mogę dodać:
- testy dla uC - dal jakich przypadków je piszecie itp na przykładzie jakiegoś projektu - co tam warte jest otestowania
bo dla systemów powiedzmy webowych może wyjść tak, że nagle zmieni się technologia "na dole" i wtedy testy zrobione wcześniej się mega przydadzą, a jak to jest w przypadku uC/embedded? Tworzycie wtedy osobny projekt, który testuje tylko tą jedną rzecz?

- odnośnie debugowania - to wszystko co napisałeś - teraz wystarcza mi if z warunkiem i breakpoint w środku, żeby podejrzeć co się dzieje w danej chwili, czy np ramka komendy jest dobrze rozpoznana itp - czy można to zrobić lepiej itp
Większość umiejętności programistycznych zdobyłem sam i mam dużo takich wątpliwości typu "czy tak sie powinno robić, czy można jakoś lepiej"

Re: Debugowanie oprogramowania

: poniedziałek 07 sie 2017, 10:50
autor: inż.wielki
Jeżeli chodzi o różnicę pomiędzy konsolowym GDB a tym zintegrowanym w jakieś IDE, to mi osobiście nie udało się zmienić np jakiejś wartości podczas pracy programu. Taki przykład: kiedyś miałem projekt, w którym mikroprocesor po paru przejściach lądował w hardfoult_hander, żeby zrozumieć o co chodzi musiałem przejść krok po kroku, ale już w wersji asm, wystarczyło jedno polecenie żeby pojawił się ekranik podzielony na pół z wersją asm i z wersją kodu w C. Wtedy na przykład kładłem pętle while(zmienna) przed wybranym kodem (z jakiegoś powodu nie mogłem postawić tam pułpaki, sam nie pamiętam dlaczego) i podczas pracy programu zmieniałem komendami GDB wartości w rejestrze, który był porównywany instrukcjami ASM.

Ale ja najczęściej programuje mikrokontrolery STM32 i do tego nie korzystamy z żadnych zewnętrznych edytorów, edytujemy oprogramowanie MCedit, kompilujemy "make" a wgrywamy skryptem :) kwestia dobrych Makefile. Dlatego właśnie przyzwyczaiłem się do konsolowego GDB, co potem zresztą pozwala na awaryjne korzystanie w środowisku bez jakiś edytrów czy zintegrowanych środowisk programistycznych z GDB a również umiejętności przekładają się na zintegrowane Debbugery w środowiskach Atolic czy Eclispe :)

Re: Debugowanie oprogramowania

: poniedziałek 07 sie 2017, 12:08
autor: dambo
zgadzam się, że na YT jest bardzo dużo poradników, ale jak pisałem - jest tam zazwyczaj prosty program z ifem, pętlą i jakimś printfem i średnio (moim zdaniem oczywiście) to ma odniesienie do "normalnych" rozbudowanych projektów.

Re: Debugowanie oprogramowania

: poniedziałek 07 sie 2017, 12:46
autor: dambo
oczywiście - wiadomo, ze trzeba zacząć od podstaw itp.
Przykład z nauki uc - zaczynamy od podstaw i wszędzie wstawiamy delaye. Później się dowiadujemy, że to źle i trzeba zmienić podejście.
Tymi pytaniami chcę uniknąć tej zmiany podejścia do debugowania w przyszłości - mogę sobie przejrzeć jak na YT dodają breakpointy szukając danej linijki pliku itp na programie 100 linii, tylko czy to się robi DOKŁADNIE tak samo w wielkich projektach, czy jakoś inaczej się do tego podchodzi.
Była mowa w tym wątku o skryptach/testach w normalnych projektach - o tym już taki łatwo info nie znajdę stąd pytam.

Re: Debugowanie oprogramowania

: poniedziałek 07 sie 2017, 18:23
autor: mokrowski
Hmm.. ogólnie...
Warto popatrzeć na techniki pracy doświadczonych programistów. Wszystko co wymaga zbędnego zdejmowania ręki z klawiatury (np. na myszkę) czy w celu debug czy w celu uruchomienia jest natychmiast przez nich zmieniane na wywołanie skrótem klawiszowym lub sprawdzone jaki skrót do tego służy. Stąd "mizianie myszą GUI" jest ... bezproduktywne a wpisanie 4-5 liter o wiele szybsze niż "celowanie kursorem".
To taka uwaga co do ergonomii (bo może od tej strony także warto wspomnieć o problemie GUI vs CLI).
Teraz co do skryptu debuggera to.. pierwsze wyniki w google :-)
https://stackoverflow.com/questions/107 ... ng-session
https://stackoverflow.com/questions/109 ... ed-written

To wcale nie jest takie straszne i nieprzystępne :-)