Niemniej dzielą się one na 2 podstawowe grupy:
--> Programowe debugowanie przy użyciu symulatora
--> Sprzętowe debugowanie poprzez złącze JTAG
Zaś obie te grupy zaś możemy podzielić na 2 grupy:
---> Używanie debugera wbudowanego w Eclipse
---> Korzystając z narzędzi zewnętrznych
Wszystkie wymienione maja swoje wady i zalety. Jednak wszystkie są oparte o serwer GDB i debuger GNU.
Dla nas oznacza to, że debugowanie odbywa się w systemie klient/serwer - niezależnie od użycia symulatora czy JTAG-a.
Niektóre zewnętrzne aplikacje do debugowania (np. AVR Studio, Proteus, VMLab) są zintegrowane z serwerem , a więc użytkownik będzie tylko działał po stronie klienta z ukrytym serwerem działającym w tle programu.
# SERWERY DEBUGERA
Zasadniczo istnieją dwa główne serwery gdb dla AVR są to:
>>> AVaRICE
Działa jako serwer gdb dla połączeń przez interfejs JTAG, czyli to taki pomost miedzy gdb, a sprzętowym JTAG.
Aby skorzystać z debugowania w systemie (JTAG) musimy oczywiście posiadać sprzętowy debuger, który
podłączymy do naszego układu przez port JTAG.
AVaRiace obsługuje trzy rodzaje interfejsów JTAG, a są to:
AVR JTAGICE mkII --- Na ta chwile to najlepszy obsługiwany JTAG dla AVR , Jest stosunkowo drogi, ale
są dostępne klony po znośnych cenach. Dysponuje:
---> podłączenie do PC przez -- USB / RS232
---> obsługuje JTAG i dW
---> obsługuje wszystkie obecne procesory AVR oraz AVR32
AVR Dragon --- Dragon to taka okrojona wersja MkII , reszta będzie opisana na jego przykładzie
bowiem akurat takowy posiadam, ale konfiguracja na inny nie będzie stanowić problemu.
---> USB
---> JTAG, dW, ISP, HV, i tryby PP
---> obsługuje prawie wszystkie AVR (oficjalnie max 32K Flash -- ale z m128 nie miałem problemów:)
AVR JTAG (MkI) --- Pierwszy interfejs JTAG teraz wycofany , i nie warty zakupu z powodu braku suportu
w nowszych środowiskach.
---> RS232 --część klonów posiadała USB
---> tylko JTAG
---> Nie obsługuje nowszych procesorów
---> Można go zbudować samemu ze względu na prostą konstrukcje np. wg tej strony:
http://www.m2uu.com/elektronika:avrjtag niemniej strata czasu i szkoda zachodu.
**** dW = debugWIRE to firmowy interfejs Atmela podobny do JTAG, ale przy użyciu tylko 1 przewodu (linia reset) Używany zwłaszcza przy małych procesorach tzw Pin Count AVR.
# Simulavr / Simulavrxx
Jest to Open Source-owy symulator programowy do symulacji procesorów AVR. Trochę już staruszek bo jego rozwój zatrzymał się na wydaniu z lutego 2005 , ale może być wciąż stosowany gdyż pozwala symulować większość popularnych procesorów, Jednak symulacja nie jest kompletna, brakuje wielu funkcji dla portów I/O, a na tych co są polegać za bardzo nie można. Nadaje się jednak dla początkujących jako zabawka do nauki pracy z symulatorem:)
Simulavrxx - to przepisany na C++ symulator Simulavr i też nic z nim się nie działo przez ostatnie 2 lata Jednak na początku 2008 podjęto działania za sprawą CVS wiec może się będzie rozwijać.
-------------------------------------------------------------------------------------------------------
No trochę przy nudziłem co ??
Niestety konieczne jest poznanie sprzętu i oprogramowania potrzebnego do
symulacji i debugowania bez tego ani rusz 
-------------------------------------------------------------------------------------------------------
# Debugowanie w ECLIPSE ---> teraz krzykniecie pewnie no wreszcie
Chociaż Eclipse dla AVR aktualnie (oficjalnie) nie obsługuje debugowania, to jednak wersja CDT posiada wszystko co jest wymagane i potrzebne do debugowania programów dla naszych Procków
ale wymaga to pewnej konfiguracji i jak zawsze w Eclipse jest więcej niż jeden sposób by to zrobić
Postaram się byśmy to zrobili jak najprościej:
----> Debugowanie AVR z Eclipse wymaga dwóch kroków :
>> inicjacji serwera gdb,
i
>> połączenia się z nim
JEDZIEMY -----------------------------------------------------------------------------------------------------------------------------
Poniższe kroki przeprowadzam na moim systemie przenośnym
-- Windows XP -- bo na moim warsztatowym IBMie nic innego nie działa:)
-- Eclipse 3.4 (ganymede) z CDT 5.0
-- WinAVR-20081124rc3 (zawiera AVaRiace oraz AVR-GDB)
-- Debuger AVR Dragon
-- a do testów użyłem AVR Butterfly (jest na sprzedaż) z ATmegą 169:)
Do testu również zostały użyte 2 programy:
>>> avrtest -- prosty program testowy z pusta nieskończona pętla main() dla M16 do testu z simulavr
>>> ButteeflyLCDTest -- równie banalny program do przetestowania debugera avariace dla M169
Obydwa zostały skompilowane bez modyfikacji konfiguracji kompilatora. Oznacza to że można użyć ustawień
domyślnych (standard debugging info (-GP)) dla poziomu debugowania i (stabs) dla formatu debug info.
Na razie mało jasne prawda ??
Spokojnie będzie jaśniej
Optymalizację ustawiłem dla testu na "No Optimizations (-O0)" bowiem wszystkie inne poziomy optymalizacji
mogą powodować wyjście z rzeczywistych instrukcji kodu maszynowego i niczym nie przypomina to przepływu danych z kodu źródłowego C, przez co debugowanie jest bez sensowne i nie praktyczne. Oczywiście można debugować zoptymalizowany kod , ale przejście dissasemblera w stosunku do kodu źródłowego C będzie bezużyteczne. Spokojnie pewnie myślicie teraz, że trzeba będzie zmienia konfiguracje optymalizacji za każdym razem Nic z tych rzeczy przecież mamy 2 konfigi RELASE i DEBUG, które sobie działają osobno i zależą od naszego wyboru To tez przewaga Eclipse nad innymi środowiskami IDE że możemy przechowywać wiele
różnych ustawień dla różnych rzeczy np programatorów
Oczywiście wasze ustawienia mogą się różnić gdyż ja mam Dragona a wy pewnie JTAGICE
Dlatego mogą wystąpić pewne różnice. Jednak mam nadzieje że instrukcja będzie na tyle dokładna że
częściowo obejmę te różnice.
# Uruchamiamy serwer gdb
Hmmm no tak jakby to prosto napisać w sumie założenie jest łatwe , ale wytłumaczyć trudno , bowiem
tak "krasousty" jak szanowny kolega MIrek nie jestem , ale się postaram
Najprostszym sposobem uruchomienia gdb jest startowanie go jako 'narzędzia zewnętrznego' w Eclipse,
a robimy to tak :
klikamy na mały trójkąt z teczuszką obok ikony zewnętrznych narzędzi i wybieramy opcje "External Tools Configurations"
W okienku które się otworzy klikamy prawym klawiszem myszy na:
i wybieramy 
teraz możemy wprowadzić dane konfiguracyjne naszego serwera gdb:
Pewnie nie chcesz przekazywać do gdb obrazu flash w wierszu poleceń ?? w takim razie przejdź do zakładki 
i odznacz opcję
>>>> AVaRICE
Konfiguracja dla niego powinna wyglądać następująco :
gdzie :
Name = Nazwa konfiguracji ja sobie nazwałem Start Avarice
Location = tu podajemy ścieżkę do avarice
Working Directory = tu avarice nic zwykle nie zapisuje, ale sporadycznie może użyć do zrzutu pamięci
--- jak widać ustawiłem na workspace:), ale może to być dowolny folder
Arguments = Tu umieszczamy argumenty poleceń avarice
--- w tym przypadku użyłem -dragon dla JTAG (można oczywiście ustawić JTAGICE mkI jak i MkII
- Ignore-intr - ten argument zapobiega zatrzymaniu się avarice na każdym przerwaniu
- Jtag usb - dragon pracuje na usb więc dlatego
- :4242 - to port TCP dla naszego serwera gdb
Zauważcie że celowo nie określiłem funkcji " --erase i --program -- xxx file" w argumentach by umożliwić programowanie procesora poprzez interfejs JTAG, zamiast tego używam avrdude do programowania procesora docelowego Postąpiłem tak z dwóch powodów:
1. avarice błędnie programuje przez Dragona
2. nie chcę uzależniać jakiegokolwiek projektu od zewnętrznych narzędzi (miałbym jak w AS fuuu)
Po zapisaniu konfiguracji gdy klikniemy na RUN zostanie uruchomiony AVaRICE:)
Jeśli avarice wyjdzie z sesji debugowania w Eclipse to Debuger zostaje zatrzymany. Musimy wtedy ponownie uruchomić nową sesję. Zobacz w perspektywie DEBUG , a sam się przekonasz ze avarice jest dalej uruchomiony to tylko taka mała niedogodność:(
# SimulAVR
konfiguracja dla simulAVR u mnie wygląda tak :
tu już tylko opiszę ważniejsze rzeczy jak pole ARGUMENTS :
-Gdbserver = informujemy symulator że będzie pracowała w trybie gdbserver
-Port 4242 = oznacza ze simulavr nasłuchuje na porcie 4242 podobnie jak i avarice - czyli używamy sobie konfiguracji Debugera dla obu i dla symulatora i dla avrice
-device atmeg16 = tu ustalam że simulavr powinien zasymulować ATmege16. Jak chcesz zobaczyć (krótką) listę
obsługiwanych procesorów to w cmd wpisz simulavr -L
Tu jak widzicie też nie przekazałem paru funkcji jak na przykład przesłania obrazu flash do symulatora. I jak sie domyślacie z 2ch powodów:
1. Simulavr niestety akceptuje tylko "surowe obrazy binarne" już chyba opisywałem na forum jak utworzyć plik bin w eclipse.
2. i jak zwykle ze nie lubie sobie uzależniać czegokolwiek od jakiejś konfiguracji
W tym przypadku musielibyśmy użyć konfiguracji sprzętowego debugera opisanej wyżej by wgrać obraz flash na początku sesji debugera a to mało wygodne rozwiązanie.
Po zapisaniu ustawień kliknięcie na RUN uruchomi simulavr
Niestety simulavr będzie nadal działał nawet jak sesja DEBUG zostanie zakończona. Ale tu mozna jej uzywać do wielu sesji , a by zatrzymać simulavr musimy przejść do perspektywy DEBUG i kliknąc prawym klawiszem myszki na wejściu simulavr i wybarć ZAKOŃCZ.
--------------------------------------------------------------------------------------------------------------------------------------------
To by było na tyle jeśli chodzi o serwery GDB dla debugera , teraz zajmiemy się narzędziami wbudowanymi w Eclipse
----------------------------------------------------------------------------------------------------------------------------------------------
# Konfiguracja Debugera z Eclipse
tu sprawa jest już prosta mamy już uruchomiony prawie serwer gdb wiec możemy ustawić sobie debuger Eclipse który jest bardzo fajny:) jak zwykle istnieją 2 typy konfiguracji debugera użyteczne dla AVR.
C/C++ Local Application i oczywiście GDB Hardware Debugging
Silnik i rdzeń jest taki sam w obu przypadkach i dla obu stron, a różnice występują jedynie w interfejsie użytkownika i w pierwszych poleceniach serwera gdb służących do uruchamiania zdalnej sesji debugera.
Obie konfiguracje są praktycznie identyczne i wam znane z pracy z avarice i simulavr, wiec możecie już przetestować sami , która konfiguracja będzie dla was najlepsza.
Na początek otwieramy okienko Debug Configuration , wybieramy projekt do debugowania i klikamy na ikonke trójkąta obok 
i wybieramy DEBUG CONFIGURATIONS... okno które sie pojawi powinno wyglądać tak:
Jesli opcja GDB Hardware Debuging nie jest widoczna oznacza ze nie zainstalowane masz opcjonalne fjuczery.
Trzeba zainstalować aktualizacje oprogramowania z Menu HELP i dodać CDT service (dla Eclipse 3.4 jest tu:
http://download.eclipse.org/tools/cdt/releases/ganymede ), a następnie przeglądnąć dostępne aktualizacje i zainstalować opcjonalna funkcję Eclipse C/C++ GDB Hardware Debugging.
Teraz należy 2klikiem na każdej konfiguracji aby utworzyć nową. Gdy będziecie mieli wybrany projekt przed otwarciem okna konfiguracji będzie ono miało nazwę np. "Nazwa_projektu Debug".
Pierwsza zakładka (główna) jest taka sama w obu przypadkach:
jak widać musimy wskazać nasz plik .elf -- nie wymaga to chyba tłumaczenia:)
teraz przechodzimy do ustawień specyficznych ---> robią się schody nie
>>>>> C/C++ Local Application
Dla tego typu konfiguracji wszystkie stosowne ustawienia znajdziecie na karcie DEBUGGER:
-- Debugger
Ustawcie na gdbserver Debugger
-- GDB debugger
zmienić na "avr-gdb". Ustawiony na "gdb" nie działa, gdyż będzie domyślnie debugował na i386.
-- GDB Command file
usuń z stąd wskazanie na plik ". gdbinit". Jeśli jednak nadal trzeba wgrać obraz flash do docelowego procesora (np. z simulavr), musisz napisać mały skrypt gdb i wpisz tutaj jego nazwę . Zobacz poniżej .
-- GDB command set
wybierzcie "Standard" lub "Standard (Windows)". Nie używamy "Cygwin", ponieważ avr-gdb nie jest aplikacją cygwin. Różnice w różnych zestawach poleceń są minimalne, dotyczą głównie obsługi bibliotek współdzielonych, które są nieistotne dla programowania AVR.
-- Protocol
Pozostaw na "mi". To jest to samo co "MI2". "Mi1" jest starszym protokołem gdbservera,a że nie ma żadnych zalet w avr-gdb rozumie mi jako MI2.
-- Verbose console mode
Jeśli macie problemy możecie wybrać tę opcję, aby zobaczyć komunikację pomiędzy Eclipse i avr-gdb.
Teraz należy kliknąć na kartę Connection i skonfigurować parametry komunikacji pomiędzy avr-gdb i gdbserver:)
Nie będę się tu rozpisywał po prostu ustawcie jak na obrazku
Nasza konfiguracja jest zakończona. Kliknijcie na przycisku Debug i jeśli wszystko jest w porządku sesji debugowania powinien rozpocząć i aplikacja powinna zatrzymać się na początku naszej funkcji main ().
Dodatkowo dla dopełnienia informacji dopowiem w tym miejscu że :
gdb init przesyła obraz flash do simulavr. Zapiszcie go sobie gdzieś (np. w folderze projektu jako "gdbinit")
i wprowadźcie pełna ścieżkę dostępu do pliku w polu File GDB Commands na karcie Debugger w oknie konfiguracji. U mnie gdb działa mimo skryptu simulavr, ale może działać lepiej przy sprzętowym debugerze konfiguracje którego opiszę za chwilę.
Code:
# make sure simuavr has code to run (it would complain Unknown opcode)
# change the filename as required, but with the name of the build configuration (here: Debug)
file Debug/avrtest.elf
#also don't forget to change the port number if you are using a different one.
target remote localhost:4242
load
# GDB Hardware Debugging
Dla debugowania sprzętowego w GDB musimy zmienić ustawienia w dwóch zakładkach
Zacznijmy od zakładki Debugger.
Tu większość opcji zostaje ustalona domyślnie przez przez Eclipse, a jedynymi opcjami, które musimy zmienić
zaznaczyłem na obrazku:
następnie przechodzimy na zakładkę STARTUP:
Jeśli wybraliście standardowy JTAG na poprzedniej stronie , te opcje można zignorować
Przesyłamy obraz flash na początku sesji debugowania. Plik obrazu może być. Elf lub. Hex, ale upewnijcie się, że wybraliście właściwą dla danego projektu. Uwaga: Ta funkcja nie działa u mnie na moim AVR Dragon, prawdopodobnie z powodu błędu w avarice. Zamiast z automatu muszę przesyłać obraz z avrdude przed rozpoczęciem sesji debugowania.
Pozostałe nie maja znaczenia:)
Set program counter at (hex)
jeśli nie jest ustawiony gdbserver zaczyna od 0x0000, która jest lokalizacją wektora reset . Więc chyba nie ma potrzeby ustawiania niczego tutaj.
Set breakpoints at:
Ustawiamy na "main" lub inną funkcję, na której chcemy zatrzymać wstępne wykonanie i rozpocząć debugowanie.
Resume
Wybieramy tę opcję. Jeżeli nie wybrano avarice i nie została uruchomiona jego aplikacja to trzeba wpisać "continue" dla avr-gdb w widoku konsoli, aby zadziałał debuger. Dlatego lepiej tą opcje zaznaczyć.
Ufff konfiguracja zakończona.Zapisujemy ustawienia. Kliknijcie teraz przycisk, Debug i jeśli wszystko jest w porządku sesja debugowania powinna się rozpocząć i aplikacja powinna zatrzymać się na początku naszej funkcji main ().
# PRACA Z DEBUGEREM
No teraz chyba najważniejsze prawda , co z tego ze uruchomiliśmy sesję debugera jak nie wiemy jak z nią pracować , a więc jeśli wszystko przebiegło bez zakłóceń i nasza konfiguracja jest prawidłowa to nasza perspektywa DEBUG w Eclipse powinna wyglądać tak:
Zapewne widzicie ze to prawdziwa sesja debugowania dla AVRBytterfly na AVR Dragon przez interfejs JTAG, którego użycie wam zakomunikowałem wcześniej Ten obrazek pokazuje jak działa i wygląda w Eclipse funkcja debugera z pakietu CDT.
BTW, Segment pamięci pokazany na obrazku zaczyna się na adresie 0x800020. To jest początek zakresu rejestrów dla I/O dla AVR , dzięki czemu możemy zobaczyć zawartość wszystkich wejść i wyjść rejestrów .
Aby znaleźć określony rejestr musicie zdobyć jego adres w eclipse można je znaleźć w w AVR Device Explorer i dodać do niego nasze 0x800020 czyli adres początkowy:)
I to by było na tyle na razie w tym temacie , mam nadzieję ze te informacje się komuś przydadzą , miłej lektury
i debugowania programów
CIĄG dalszy przynudzania : TUTAJ topic958.htmlStatystyki: Napisane przez SunRiver — 29 mar 2012, o 11:44
]]>
, czy za pomocą avr dragon i złącza jtag, można w jakiś sposób zapalać tj. ustawiać bity na poszczególnych portach procesora, czy jedynie debugować program?.
