Debugowanie oprogramowania

Pytania dotyczące problemów z wyborem, konfiguracją i pracą w wybranym środowisku programistycznym dla mikrokontrolerów ARM firmy STMicroelecreonics.
StaryAnoda

Debugowanie oprogramowania

Postautor: StaryAnoda » piątek 04 sie 2017, 19:06

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 ?

Awatar użytkownika
Antystatyczny
Geek
Geek
Posty: 1168
Rejestracja: czwartek 03 wrz 2015, 22:02

Re: Debugowanie oprogramowania

Postautor: Antystatyczny » piątek 04 sie 2017, 19:54

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.
"The true sign of intelligence is not knowledge but imagination" Albert Einstein.

StaryAnoda

Re: Debugowanie oprogramowania

Postautor: StaryAnoda » piątek 04 sie 2017, 20:05

O modyfikacja wartości zmiennych i rejestrów to wiem, a w jaki sposób podglądać zmienne w czasie rzeczywistym ?

Awatar użytkownika
Antystatyczny
Geek
Geek
Posty: 1168
Rejestracja: czwartek 03 wrz 2015, 22:02

Re: Debugowanie oprogramowania

Postautor: Antystatyczny » piątek 04 sie 2017, 20:07

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.
"The true sign of intelligence is not knowledge but imagination" Albert Einstein.

StaryAnoda

Re: Debugowanie oprogramowania

Postautor: StaryAnoda » piątek 04 sie 2017, 20:16

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ę :)

Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

Re: Debugowanie oprogramowania

Postautor: dambo » piątek 04 sie 2017, 22:40

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.
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

Awatar użytkownika
inż.wielki
User
User
Posty: 307
Rejestracja: niedziela 20 gru 2015, 23:11

Re: Debugowanie oprogramowania

Postautor: inż.wielki » piątek 04 sie 2017, 23:46

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

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Debugowanie oprogramowania

Postautor: mokrowski » sobota 05 sie 2017, 00:24

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 :-)
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek

StaryAnoda

Re: Debugowanie oprogramowania

Postautor: StaryAnoda » sobota 05 sie 2017, 10:53

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 ?

Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

Re: Debugowanie oprogramowania

Postautor: dambo » sobota 05 sie 2017, 11:11

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?
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Debugowanie oprogramowania

Postautor: mokrowski » sobota 05 sie 2017, 13:22

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 :-)
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek

Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

Re: Debugowanie oprogramowania

Postautor: dambo » sobota 05 sie 2017, 13:46

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
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Debugowanie oprogramowania

Postautor: mokrowski » sobota 05 sie 2017, 13:48

A precyzyjniej... Co Cię dokładniej @dambo interesuje?
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek

Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

Re: Debugowanie oprogramowania

Postautor: dambo » sobota 05 sie 2017, 13:58

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"
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

Awatar użytkownika
inż.wielki
User
User
Posty: 307
Rejestracja: niedziela 20 gru 2015, 23:11

Re: Debugowanie oprogramowania

Postautor: inż.wielki » poniedziałek 07 sie 2017, 10:50

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 :)

Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

Re: Debugowanie oprogramowania

Postautor: dambo » poniedziałek 07 sie 2017, 12:08

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.
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

Re: Debugowanie oprogramowania

Postautor: dambo » poniedziałek 07 sie 2017, 12:46

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.
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

Awatar użytkownika
mokrowski
User
User
Posty: 190
Rejestracja: czwartek 08 paź 2015, 20:50
Lokalizacja: Tam gdzie Centymetro

Re: Debugowanie oprogramowania

Postautor: mokrowski » poniedziałek 07 sie 2017, 18:23

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 :-)
,,Myślenie nie jest łatwe, ale można się do niego przyzwyczaić" - Alan Alexander Milne: Kubuś Puchatek


Wróć do „Jakie IDE dla STM?”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 5 gości