Debugowanie oprogramowania
Debugowanie oprogramowania
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 ?
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 ?
- Antystatyczny
- Geek
- Posty: 1168
- Rejestracja: czwartek 03 wrz 2015, 22:02
Re: Debugowanie oprogramowania
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.
Re: Debugowanie oprogramowania
O modyfikacja wartości zmiennych i rejestrów to wiem, a w jaki sposób podglądać zmienne w czasie rzeczywistym ?
- Antystatyczny
- Geek
- Posty: 1168
- Rejestracja: czwartek 03 wrz 2015, 22:02
Re: Debugowanie oprogramowania
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.
Re: Debugowanie oprogramowania
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
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.
Fajnym narzędziem do podglądu działania aplikacji jest STMStudio.
Nowy blog o tematyce embedded -> https://www.embedownik.pl/
- inż.wielki
- User
- Posty: 307
- Rejestracja: niedziela 20 gru 2015, 23:11
Re: Debugowanie oprogramowania
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
Pozdrawiam
- mokrowski
- User
- Posty: 190
- Rejestracja: czwartek 08 paź 2015, 20:50
- Lokalizacja: Tam gdzie Centymetro
Re: Debugowanie oprogramowania
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
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
Re: Debugowanie oprogramowania
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 ?
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
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?
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/
- mokrowski
- User
- Posty: 190
- Rejestracja: czwartek 08 paź 2015, 20:50
- Lokalizacja: Tam gdzie Centymetro
Re: Debugowanie oprogramowania
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
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
Re: Debugowanie oprogramowania
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/
- mokrowski
- User
- Posty: 190
- Rejestracja: czwartek 08 paź 2015, 20:50
- Lokalizacja: Tam gdzie Centymetro
Re: Debugowanie oprogramowania
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
Re: Debugowanie oprogramowania
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"
- 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/
- inż.wielki
- User
- Posty: 307
- Rejestracja: niedziela 20 gru 2015, 23:11
Re: Debugowanie oprogramowania
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
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
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/
Re: Debugowanie oprogramowania
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.
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/
- mokrowski
- User
- Posty: 190
- Rejestracja: czwartek 08 paź 2015, 20:50
- Lokalizacja: Tam gdzie Centymetro
Re: Debugowanie oprogramowania
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
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
Kto jest online
Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość