Monitor - praca krokowa
Masz problem? Zapytaj na forum elektroda.pl
From: "Maciej Wywrocki" <wywrocki_at_nospam_pnet.pl>
Subject: Monitor - praca krokowa
Date: Mon, 2 Jul 2001 23:51:20 +0200
W jaki sposób działa debugger współpracujący z systemem mikrokontrolerowym?
Czy ingeruje on w kod źródłowy? Domyślam się, że kontrola nad systemem
podczas pracy krokowej jest możliwa, gdy:
- kontroler będzie taktowany krokowo,
- po każdej instrukcji umieszczone zostanie wywołanie podprogramu monitora.
No, ale w jaki sposób odczytywane są rejestry wewnętrzne kontrolera?
Przecież wszystkie porty mogą być zajęte.
Z góry dzięki za objaśnienie.
Mw
From: "SpeedBit" <kula_at_nospam_polbox.com>
Subject: Re: Monitor - praca krokowa
Date: Tue, 3 Jul 2001 00:19:52 +0200
Użytkownik "Maciej Wywrocki" <wywrocki_at_nospam_pnet.pl> napisał w wiadomości
news:9hqr0a$oj2$2_at_nospam_news.tpi.pl...
W jaki sposób działa debugger współpracujący z systemem
mikrokontrolerowym?
Czy ingeruje on w kod źródłowy? Domyślam się, że kontrola nad systemem
podczas pracy krokowej jest możliwa, gdy:
- kontroler będzie taktowany krokowo,
- po każdej instrukcji umieszczone zostanie wywołanie podprogramu
monitora.
No, ale w jaki sposób odczytywane są rejestry wewnętrzne kontrolera?
Przecież wszystkie porty mogą być zajęte.
Z góry dzięki za objaśnienie.
Mw
Hmmm
Troche mało informacji o co dokładnie chodzi.
Z tego co ja zrozumiałem masz na myśli emulator?
W tym systemie praca procesora jest emulowana a w miejsce procka wkładany
jest kabelek do emulatora - urzadzenia które udaje ten procesor. kod "wlewa
się" do emulatora poprzez LPT lub RS i komunikacja odbywa się przez to łącze
z programem na PC, który pokazuje "na bieżąco" stan rejestrów które miałby
prawdziwy procek. Wszystkie porty są wolne. Widzi je przecież wprost
emulator. A praca krokowa jest wtedy bardzo prosta - wołana jest dana
instrukcja a informacje o zmianie stanu "wirtualnych rejestrów" wędruje do
PC -> tym zarządza już emulator wraz ze swoim programem na PC.
O to Ci chodziło?
Nie za bardzo zagmatwałem?
pozdrowienia
Sławek
From: "Maciej Wywrocki" <wywrocki_at_nospam_pnet.pl>
Subject: Re: Monitor - praca krokowa
Date: Tue, 3 Jul 2001 20:46:31 +0200
Użytkownik "SpeedBit" <kula_at_nospam_polbox.com> napisał w wiadomości
news:9hqs2c$sod$1_at_nospam_news.tpi.pl...
Z tego co ja zrozumiałem masz na myśli emulator?
Nie. Chodzi raczej o system mikroprocesorowy, dajmy na to "dydaktyczny",
który współpracuje np. z Keilem. W przypadku emulatora sprawa jest
oczywiście bardziej przejrzysta.
Mw
From: "Radzisław Galler" <rgaller_at_nospam_et.put.poznan.pl>
Subject: Re: Monitor - praca krokowa
Date: Tue, 3 Jul 2001 09:41:48 +0200
"Maciej Wywrocki" <wywrocki_at_nospam_pnet.pl> wrote in message
news:9hqr0a$oj2$2_at_nospam_news.tpi.pl...
W jaki sposób działa debugger współpracujący z systemem
mikrokontrolerowym?
Czy ingeruje on w kod źródłowy? Domyślam się, że kontrola nad systemem
podczas pracy krokowej jest możliwa, gdy:
- kontroler będzie taktowany krokowo,
- po każdej instrukcji umieszczone zostanie wywołanie podprogramu
monitora.
No, ale w jaki sposób odczytywane są rejestry wewnętrzne kontrolera?
Przecież wszystkie porty mogą być zajęte.
Z góry dzięki za objaśnienie.
Mw
Wszystko zalezy od rodzaju procesora. Emulator sprzetowy pozwala na duza
swobode i uniezaleznia programiste od ulatwien i ograniczen procesora
zwiazanych debugowaniem.
Niektore mikrokontrolery (np. Hitachi z rodziny SH) maja rejestry (UBCR),
ktore sa porownywane z licznikiem rozkazow i w momencie wystapienia
zgodnosci wywolywane jest przerwanie. Wtedy procedura przerwania moze sie
skomunikowac przez port szeregowy z debuggerem dzialajacym na PC-cie. W
czasie wywolania przerwania stan wszystkich rejestrow z programu glownego
jest przechowywany na stosie i mozna sobie wszystko podgladnac. Procedura
obslugi przerwania moze tez obliczyc nastepna zawartosc rejestru UBCR. Jesli
obliczanie jest zrobione inteligentnie to mozna debugowac na poziomie jezyka
C, jesli mniej inteligentnie - na poziomie assemblera.
Sa tez kontrolery lepiej wyposazone (czytaj drozsze). Posiadaja jednostke
zarzadzania pamiecia (MMU). Pozwala to na zastawienie pulapek na dostep
programu do zadanego adresu pamieci danych.
Kontrolery, ktore nie maja takich sprzetowych udogodnien mozna debugowac
uzywajac przerwania ktoregos z timerow. Trzeba nastawic timer na czas
wykonywania sie jednej instrukcji. W tym przypadku debugowanie na poziomie
jezyka C jest wlasciwie niemozliwe.
Co do ingerencji w kod programu, to nie zawsze jest to mozliwe (i
oplacalne), bo:
- pamiec programu jest ograniczona
- czesto program jest wykonywany z pamieci stalej (EPROM/FLASH itp.)
HTH
Radek
From: "Maciej Wywrocki" <wywrocki_at_nospam_pnet.pl>
Subject: Re: Monitor - praca krokowa
Date: Tue, 3 Jul 2001 20:54:32 +0200
Użytkownik "Radzisław Galler" <rgaller_at_nospam_et.put.poznan.pl> napisał w
wiadomości news:9hrsk0$oks$1_at_nospam_news.tpi.pl...
Kontrolery, ktore nie maja takich sprzetowych udogodnien mozna debugowac
uzywajac przerwania ktoregos z timerow. Trzeba nastawic timer na czas
wykonywania sie jednej instrukcji. W tym przypadku debugowanie na poziomie
jezyka C jest wlasciwie niemozliwe.
A jak jest w przypadku 8051 (całej rodziny)? Bo można przecież uruchamiać
programy wykorzystujące oba timery, a mimo to ustawienie pułapki w dowolnym
miejscu jest możliwe i obsługiwane poprawnie?
Mw
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: Monitor - praca krokowa
Date: Thu, 05 Jul 2001 20:45:58 GMT
On Tue, 3 Jul 2001 20:54:32 +0200, Maciej Wywrocki wrote:
Użytkownik "Radzisław Galler" <rgaller_at_nospam_et.put.poznan.pl> napisał w
Kontrolery, ktore nie maja takich sprzetowych udogodnien mozna debugowac
uzywajac przerwania ktoregos z timerow. Trzeba nastawic timer na czas
wykonywania sie jednej instrukcji. W tym przypadku debugowanie na poziomie
jezyka C jest wlasciwie niemozliwe.
A jak jest w przypadku 8051 (całej rodziny)? Bo można przecież uruchamiać
programy wykorzystujące oba timery, a mimo to ustawienie pułapki w dowolnym
miejscu jest możliwe i obsługiwane poprawnie?
Jakiej pulapki ? '51 w ogole nie maja zadnych pulapek :-)
J.
From: "Maciej Wywrocki" <wywrocki_at_nospam_pnet.pl>
Subject: Re: Monitor - praca krokowa
Date: Fri, 6 Jul 2001 00:43:16 +0200
Użytkownik "J.F." <jfox_at_nospam_friko6.onet.pl> napisał w wiadomości
news:3b57bbbf.16479572_at_nospam_nt...
A jak jest w przypadku 8051 (całej rodziny)? Bo można przecież uruchamiać
programy wykorzystujące oba timery, a mimo to ustawienie pułapki w
dowolnym
miejscu jest możliwe i obsługiwane poprawnie?
Jakiej pulapki ? '51 w ogole nie maja zadnych pulapek :-)
Pułapki w debuggerze.
Mw
From: "Radzisław Galler" <rgaller_at_nospam_et.put.poznan.pl>
Subject: Re: Monitor - praca krokowa
Date: Fri, 6 Jul 2001 09:48:56 +0200
"Maciej Wywrocki" <wywrocki_at_nospam_pnet.pl> wrote in message
news:9hvfe9$ndf$2_at_nospam_news.tpi.pl...
Użytkownik "Radzisław Galler" <rgaller_at_nospam_et.put.poznan.pl> napisał w
wiadomości news:9hrsk0$oks$1_at_nospam_news.tpi.pl...
Kontrolery, ktore nie maja takich sprzetowych udogodnien mozna debugowac
uzywajac przerwania ktoregos z timerow. Trzeba nastawic timer na czas
wykonywania sie jednej instrukcji. W tym przypadku debugowanie na
poziomie
jezyka C jest wlasciwie niemozliwe.
A jak jest w przypadku 8051 (całej rodziny)? Bo można przecież uruchamiać
programy wykorzystujące oba timery, a mimo to ustawienie pułapki w
dowolnym
miejscu jest możliwe i obsługiwane poprawnie?
Wspominales o systemie dydaktycznym - zdarzylo mi sie na takim pracowac.
Program jest ladowany do RAM i tam chyba rzeczywiscie w miejsce nastepnej
instrucji na biezaco jest wstawiany rozkaz skoku do procedury monitora.
Jesli zaladujesz program do EPROMu to juz jest niemozliwe.
Moj kolega wymyslil taka sprytnie spreparowana pamiec, ktora pozwala na czas
debugowania zagladac w program i zatrzymywac go w odpowiednim miejscu
wlasnie na '51. No ale pewnie za darmo pomyslu nie odda...
Radek
From: "Maciej Wywrocki" <wywrocki_at_nospam_pnet.pl>
Subject: Re: Monitor - praca krokowa
Date: Sat, 7 Jul 2001 00:32:29 +0200
Użytkownik "Radzisław Galler" <rgaller_at_nospam_et.put.poznan.pl> napisał w
wiadomości news:9i3q4m$l6c$1_at_nospam_news.tpi.pl...
Wspominales o systemie dydaktycznym - zdarzylo mi sie na takim pracowac.
Program jest ladowany do RAM i tam chyba rzeczywiscie w miejsce nastepnej
instrucji na biezaco jest wstawiany rozkaz skoku do procedury monitora.
No właśnie, też tak to sobie wyobrażam. W systemie, z którym miałem do
czynienia na końcu kodu należało zawsze umieścić 3 NOP-y. A to oznacza, że
w miejsce przez nie rezerwowane podstawiany jest LJMP lub LCALL.
Przy pracy krokowej zaowocuje to przetasowaniami pamięci wraz ze zmianą
wszystkich adresów zapisanych w JMP i CALL. Czyli dla dużych programów po
każdym kroku całe 64kB zostaje przeadresowane i rozsunięte.
Moj kolega wymyslil taka sprytnie spreparowana pamiec, ktora pozwala na
czas
debugowania zagladac w program i zatrzymywac go w odpowiednim miejscu
wlasnie na '51. No ale pewnie za darmo pomyslu nie odda...
Podejrzewam, że kruczek tkwi w adresowaniu, "udającym" pamięć ciągłą ;)?
Mw