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
Expert
Expert
Posty: 918
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
Expert
Expert
Posty: 918
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
User
User
Posty: 450
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.
Zapraszam na mojego pseudobloga z projektami itp: http://projektydmb.blogspot.com/

Awatar użytkownika
inż.wielki
User
User
Posty: 157
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: 124
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
User
User
Posty: 450
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?
Zapraszam na mojego pseudobloga z projektami itp: http://projektydmb.blogspot.com/

Awatar użytkownika
mokrowski
User
User
Posty: 124
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
User
User
Posty: 450
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
Zapraszam na mojego pseudobloga z projektami itp: http://projektydmb.blogspot.com/

Awatar użytkownika
mokrowski
User
User
Posty: 124
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
User
User
Posty: 450
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"
Zapraszam na mojego pseudobloga z projektami itp: http://projektydmb.blogspot.com/

Awatar użytkownika
rezasurmar
Expert
Expert
Posty: 996
Rejestracja: czwartek 03 wrz 2015, 23:46
Lokalizacja: Tychy
Kontaktowanie:

Re: Debugowanie oprogramowania

Postautor: rezasurmar » poniedziałek 07 sie 2017, 08:01

U mnie to nie ma 'typowych' procedur.

Testuje się urządzenie/program w warunkach jak najbardziej zbliżonych do warunków u klienta.
Następnie w jak najgorszych warunkach.
Czyli najgorsze możliwe napięcia/prądy. Testowanie szczelności (mycie myjką ciśnieniową/zanurzanie na odpowiednią głębokość na odpowiedni czas - zależnie od IPXX).
Przeciążenia masą, obciążenie udarowe itp. Nie mamy laboratorium, ot z własnej praktyki wiemy co może spotkać urządzenie.
W przypadku bardziej zaawansowanych projektów pod klienta, testujemy w docelowym miejscu instalacji.

Awatar użytkownika
inż.wielki
User
User
Posty: 157
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
rezasurmar
Expert
Expert
Posty: 996
Rejestracja: czwartek 03 wrz 2015, 23:46
Lokalizacja: Tychy
Kontaktowanie:

Re: Debugowanie oprogramowania

Postautor: rezasurmar » poniedziałek 07 sie 2017, 12:00

Tak na marginesie, na YT jest bardzo dużo filmów pokazujących różne techniki debugowania.
J-link w wersji EDU całkiem dobrze się sprawdza (czyli w zasadzie każdy j-link z zestawu ma to co EDU).
Dużo zależy od włączonej optymalizacji, oraz czy np. jest np. zaznaczona opcja (Debug Information - Keil).

Z tego co pamiętam można sobie na żywo podglądać rejestry, obszary pamięci, itp.

Na początek polecam po prostu pobawić się debugerem, zachowaniem przy seg/hard fault, przy wywołaniach przerwań itp.
Czyli na prostym programie zobaczyć zachowanie debugera w różnych sytuacjach.

U mnie częstym problemem były 'hazardy' przerwań (opanowanie grup rozwiązało problem).
Czyli np. czkawka przy obsłudze klawiatury/poleceń z uarta, gdzie w tle leciała obsługa danych z ADC.
Fajnie to na debugerze widać, że program w danym momencie wylatuje z obsługi np. UART/Klawiatury jak mu przylatuje przerwanie od SPI, przez co czkawki dostawał czasem.

Podobnie bardzo długa obsługa superdebouce (by mirek) powodowała wylatywanie ramek z uarta (AVR).

Awatar użytkownika
dambo
User
User
Posty: 450
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.
Zapraszam na mojego pseudobloga z projektami itp: http://projektydmb.blogspot.com/

Awatar użytkownika
rezasurmar
Expert
Expert
Posty: 996
Rejestracja: czwartek 03 wrz 2015, 23:46
Lokalizacja: Tychy
Kontaktowanie:

Re: Debugowanie oprogramowania

Postautor: rezasurmar » poniedziałek 07 sie 2017, 12:31

Zawsze możesz odpalić demo np dla STM32F7 DISCO. z TFT, odczytem SD, netem, dźwiękiem itd.

Trzeba zacząć od prostych, następnie sprawdzonych, a dopiero potem rzucać się na debugowanie skomplikowanych softów z błędami.

Awatar użytkownika
dambo
User
User
Posty: 450
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.
Zapraszam na mojego pseudobloga z projektami itp: http://projektydmb.blogspot.com/

Awatar użytkownika
rezasurmar
Expert
Expert
Posty: 996
Rejestracja: czwartek 03 wrz 2015, 23:46
Lokalizacja: Tychy
Kontaktowanie:

Re: Debugowanie oprogramowania

Postautor: rezasurmar » poniedziałek 07 sie 2017, 14:06

Ja cały czas się wypowiadam z poziomu mojego doświadczenia (czyli bliżej mi do sprzętu niż softu).

W dużych projektach masz już odpowiednie narzędzia wbudowane często w sam program, np. full asert, by przekazywać od razu błędne wywołania (o ile dobrze to nazwałem).
Odpowiednie definicje, w przypadku np. używania trybu debug, wyrzucanie zmiennych po SWD/SWO (sposób śledzenia na żywo, zmiennych itp.).

To dosyć złożone zagadnienie, pewnie kolega Mokrowski mógł by tutaj książkę napisać jako główny i doświadczony w pisaniu dużych projektów.

Dla mnie podstawową kwestią jest to jakie warunki musi program spełniać, co np. musi zrobić w przypadku napotkania błędu. Dla mnie debugowanie to zawsze mocno indywidualna kwestia.
Często wyrzucam sobie j.w po SWD/SWO zmienne, czy nawet jest możliwość analizy wizualnej danych z STMów (vide STMstudio http://www.st.com/en/development-tools/ ... stm32.html).
W np. freeRTOS są odpowiednie narzędzia wbudowane do obsługi błędów, czy debugowania.

I j.w dla mnie debugowanie to cały czas świetna zabawa, poznanie procesora, bez trybu debug nie wyobrażam sobie pisania softu.
Co do bardziej zaawansowanych technik to już muszą się wypowiedzieć koledzy.

Awatar użytkownika
mokrowski
User
User
Posty: 124
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 1 gość