Witam,

programuję ATMEGA8 od zaledwie kilku dni w ECLIPSE, napisałem już kilka programów do migania diodami i jak na razie wszystko działa . Instalacje ECLIPSE przeprowadziłem wg wideoporadników. Pojawił się następujący problem. Chciałem przypisać do zmiennej "a" wartość rejestru portu i podejrzeć wartość tej zmiennej przez debugowanie. Jednakże debugowanie nie działa. Wyczytałem, że trzeba doinstalować debuger MinGW, próbowałem już 3 różne wersje i dalej nie mogę debugować, co trzeba zrobić?

Jak chcesz w ten sposób debugować to pozostaje Atmel Studio - ma wbudowany symulator (Nie potrzebujesz zewnętrznego debuggera). "Normalny debugger" bez symulatora potrzebuje programatora z wbudowanym JTAGiem/DebugWire - najtańszy około 220 zł (ATMEL-ICE-BASIC)
http://pl.farnell.com/atmel/atatmel-ice ... dp/2407172

Ewentualnie możesz uruchomić UART i tam wyświetlać sobie zawartość rejestru.

Oj, a ja przezwyczajony pisaniem kodu w C na studiach (ale bez udziału mikrokontrolerów) myślałem, że debugowanie to czynność standardowa, tzn. zaznaczamy kropeczką gdzie program ma się zatrzymać i najeżdżamy myszką żeby podejrzeć wartość zmiennej, a tu tak pod górę .
Czyli na moim obecnym etapie zaawansowania w programowaniu avrów przyjmuję, że debugowanie to wyższa szkoła jazdy.
Tak mnie jeszcze ciekawi, jak w późniejszym etapie radzić sobie w takim razie z debugowaniem: w głowie, bez debugowania, inaczej? Bez debugowania pisanie dużych programów wydaje mi się niemożliwe. Czy powinienem się zapoznać również z Atmel Studio, czy może nastawiać się na zakup zewnętrznego debuggera?

Witam
Kol.Mirek demonstrował taki debuger za 0,25PLN ( LED + rezystor )
A na poważnie: moim zdaniem (mimo niewątpliwie obszernej "postudenckiej" wiedzy) rozpoczynanie zabawy z uC od zakupu jakiegoś bandyckiego sprzętu nie wydaje mi się celowe.
Po pierwsze nie pisze się całego programu, wgrywa i patrzy gdzie przystawi, tylko małymi kroczkami - wtedy łatwo wychwycić błąd.
Po jakimś czasie odwykniesz od śledzenia postępu programu na ekranie czy symulatorze, a będziesz to widział "wewnętrznie" i wtedy gdy coś przystawi - wracając do mojego wstępu: Kol.Mirek....
Debuger jest to pomocne urządzenie, ale może nie aż tak niezbędne?

Pozdr.

Spoko, czyli wnioski są takie:
- debugowanie nie jest kluczowe przynajmniej na początku,
- to że guzik "debug" nie działa w eclipse jest normalne,
- debugowanie nie jest kluczowe też w późniejszych etapach. Po pewnym czasie jest już jak w matrixie widzisz obdudowe atmegi i wyczuwasz gdzie jest stan niski, a gdzie wysoki .

Ja też nie mam zamiaru inwestować na początku drogi w jakieś "bandycko" drogie urządzenia.
Na razie tylko dokupuje atmegi8 i diody, czyli tego co się najczęściej pali

Przypomnę ten debuger, za 0,25 zł
http://mirekk36.blogspot.com/2014/04/pu ... ednej.html
Poważnie - obejrzyj ten poradnik

debugowanie jest bywa kluczowe nawet na początku ale żeby zaraz strzelać z armaty do komara ? czyli zasadzać się z debugerami sprzętowymi na tak małe procki ? Oczywiście to co piszę wcale nie znaczy, że odradzam komukolwiek takie debugery i takie podejście - jak ktoś chce to przecież ma możliwość debugowania wprost pod Atmel Studio i ew z niego trzeba korzystać aby się tym bawić na upartego. Tam to działa tak jak należy a w Eclipse ... hmmm no cóż ....


Można to skonfigurować i nawet na tym forum kolega SunRiver zrobił dwa spore poradniki na ten temat - ale jak wspominałem wyżej, i tak wolałbym już na miejscu kogoś kto chce debugować sięgnąć po to narzędzie w Atmel Studio



Aby umieć dobrze pisać i co ważniejsze analizować kod dla procków warto przede wszystkim poznać najprostsze metody jakie się ma pod ręką od diody LED po wyświetlacz LCD jeśli akurat jest w układzie albo zrozumieć jak się to robi z udziałem RS232, który od zawsze był do tego wykorzystywany, jest wykorzystywany i będzie wykorzystywany - to naprawdę bardzo dużo daje szczególnie w procesie nauki tego programowania mikrokontrolerów

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Serdecznie wszystkim dziękuję za pomoc.

Poradnik obejrzałem - wszystko na prawdę pięknie wytłumaczone.
Jako ciekawostkę, w celu wywołania uśmiechu bardziej doświadczonych na wspomnienie początkowych dni nauki programowania, powiem czemu ten poradnik okazał się niepomocny w programie, który aktualnie piszę - choć później na pewno się przyda, bo nie wpadłbym na taki sposób debugowania.

Ciężko żeby dioda robiła za debugger, gdy człowiek zastanawia się właśnie czemu dioda na wyjściu nie świeci

A teraz ta część rozweselająca. Napisałem prosty program:
PORTD wyjścia i 8 podpiętych diód przez rezystory oczywiście, anoda do portu, katoda do masy,
PORTC wejścia, 4 z podciągnięciem do Vcc mają podłączoną masę przez przełączniki, pozostałe 4 bez podciągnięcia do Vcc.

Efekt:

diody 0,1,2,3 działają jak trzeba - wciskam guzik gasną
diody 4,5 migają jak chcą - to mnie bardzo dziwiło, wszak dla mnie brak podciągnięcia do Vcc oznaczał 0V, więc chciałem podejrzeć ten rejestr i stąd cały temat
dioda 6 zgaszona - to pewnie przez specyfikę PC6, na razie nie wnikam
dioda 7 zgaszona - przypuszczam że dla tego, że nie ma wyjścia PC7

już rozumiem miganie diód 4,5 - jak nie jest podciągnięte do Vcc, to procesor odczytuje losowy stan, no ale parę godzin minęło jak z bicza strzelił

Pozdrawiam jeszcze raz dziękuję za życzliwą pomoc, a temat do zamknięcia