logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Atmega32 - Wart. rejestru licznika przy debugowaniu jest inna niż w rzeczywistoś

ravmar 18 Mar 2013 21:53 1704 7
REKLAMA
  • #1 12079944
    ravmar
    Poziom 22  
    Staram się zoptymalizować kod. W tym celu chcę sprawdzić jak szybko zostaje wykonana instrukcja wysłania 16 bitowego słowa po sprzętowej szynie SPI. W tym celu zeruje i włączam timer1 (BEZ preskalera) na początku wysyłania i zatrzymuje na końcu. Zawartość licznika TCNT1 wysyłam po UARTcie. Wynik jaki otrzymuje to zawsze 278 cykli zegara (16MHz). Ciekawi mnie dlaczego po podpięciu JTAG'a i debugowaniu programu po krokowo, wyniki rejestru TCNT1 nie są w żadnym stopniu zbliżone do tego co pierwotnie uzyskiwałem na UARTcie. Domyślam się, że jest to spowodowane złym ustawieniem beakpointa, ponieważ ustawienie go poniżej komendy wyłączającej sygnał taktujący, powoduje,że wyniki się zgadzają. I moje pytanie brzmi.

    Jeżeli sygnał taktujący timer jest wybrany i program zostanie zatrzymany z poziomu PC(wykonywanie po krokowe) to czy licznik nadal zlicza ?

    Kod: text
    Zaloguj się, aby zobaczyć kod

    Czy warto pod względem optymalizacji, realizować to z funkcją czekania jw. czy wykonać na przerwaniu SPI_STC_vect(napisać procedurę dzielącą wiadomość na dwa słowa)
  • REKLAMA
  • #2 12080047
    tmf
    VIP Zasłużony dla elektroda
    Tak, w czasie debugowania sprzętowego licznik działa nadal. To zresztą można zmienić w opcjach debugowania. W efekcie mierzone wartości tracą sens. Z drugiej strony po co ci timer? Przecież jeśli wiesz jak jest taktowany SPI to dokładnie możesz wyliczyć ile trwa transmisja.
  • REKLAMA
  • #3 12080143
    ravmar
    Poziom 22  
    tmf napisał:
    Z drugiej strony po co ci timer? Przecież jeśli wiesz jak jest taktowany SPI to dokładnie możesz wyliczyć ile trwa transmisja.

    Tak dla sprawdzenia, poznawania uC i zrozumienia jak działa. Chyba jest to najprostszy sposób ponieważ licząc czasy czekania w pętli while muszę jeszcze uwzględnić czasy innych operacji, takich jak przypisanie, przesunięcie (patrz kod wyżej) i tu też zauważam różnicę w zależności od wyboru opcji optymalizacji. Bez optymalizacji otrzymuję 348 cykli.

    tmf napisał:
    Tak, w czasie debugowania sprzętowego licznik działa nadal. To zresztą można zmienić w opcjach debugowania.

    A gdzie tego szukać ?

    tmf napisał:
    tmf

    Zaraz, zaraz czy człowiek ukrywający się pod tym loginem, który tyle razy mi pomógł to nie jest p. Tomasz F.?
  • REKLAMA
  • REKLAMA
  • #5 12080392
    ravmar
    Poziom 22  
    No właśnie jakoś teraz przez przypadek zobaczyłem stopkę "Większość odpowiedzi na nurtujące cię pytania znajdziesz tu: Język C dla mikrokontrolerów AVR. Od podstaw do zaawansowanych aplikacji." Spojrzałem na książkę leżącą na biurku ;) i zacząłem dopasowywać jej autora do loginu. Kiedy spotkanie z czytelnikami ? Już mam dwie kartki A4 zapisanych pytań swoich i uwag dot. książki.
  • #6 12080475
    tmf
    VIP Zasłużony dla elektroda
    Jeśli taka opcja jest dostępna (nie każdy AVR to potrafi i nie każdy JTAG to udostępnia) to w zakładce właściwości (DEBUG) okna debugowania będzie opcja Run timers in stopped mode. Czasami pojawia się to w zakładce PWM i wtedy można to wybrać dla indywidualnych timerów. Z drugiej strony jeśli nie masz takiej opcji to wybierz tryb symulacji - w tym trybie timery działają synchronicznie ze śledzeniem. Masz też licznik instrukcji, który umożliwia łatwe określenie czasu pomiędzy dwoma punktami, w efekcie nie trzeba bawić się timerami.
    Co do pytań i uwag - prześlij na PW.
  • #7 12080743
    ravmar
    Poziom 22  
    tmf napisał:
    Z drugiej strony jeśli nie masz takiej opcji to wybierz tryb symulacji - w tym trybie timery działają synchronicznie ze śledzeniem. Masz też licznik instrukcji, który umożliwia łatwe określenie czasu pomiędzy dwoma punktami, w efekcie nie trzeba bawić się timerami.

    Tylko dlaczego symulacja wykonywana jest dla zegara 1MHz, a nie jak zadeklarowem 16MHz. Wynik cykli zegara będzie ten sam, zmieni się tylko czas ale można go przemnożyć przez 16.

    ravmar napisał:
    tmf napisał:
    Z drugiej strony jeśli nie masz takiej opcji to wybierz tryb symulacji - w tym trybie timery działają synchronicznie ze śledzeniem. Masz też licznik instrukcji, który umożliwia łatwe określenie czasu pomiędzy dwoma punktami, w efekcie nie trzeba bawić się timerami.

    Tylko dlaczego symulacja wykonywana jest dla zegara 1MHz, a nie jak zadeklarowem 16MHz. Wynik cykli zegara będzie ten sam, zmieni się tylko czas ale można go przemnożyć przez 16.


    Możesz sobie zmienić częstotliwość zegara w symulacji. Zamiast 1MHz wpisać 16MHz i nacisnąć enter :)

    Nie wiem dlaczego podczas symulacji w zakładce Procesor mam dostępne pozycje Cycle Counter, Frequency, Stop Watch, a podczas debugowania już nie.
  • Pomocny post
    #8 12093861
    tmf
    VIP Zasłużony dla elektroda
    Dlatego, że podczas symulacji Atmel Studio symuluje procesor, w efekcie wie ile wykonał instrukcji i jakich - program jest wykonywany instrukcja po instrukcji, nawet jeśli dajesz mu run. W trybie debugowania sprzętowego pomiędzy pułapkami sprzętowymi może minąć dowolna liczba, dowolnych instrukcji. W efekcie nie ma jak ich policzyć i cycle counter nie zawierałoby żadnej sensownej wartości. Podobnie, podczas debugowania sprzętowego hardware (JTAG) nie ma szans ustalić z jaką częstotliwością działa MCU. Raz, że musiałby ją mierzyć, dwa, że wiele AVRów zawiera preskalery zegara, a nowsze (XMEGA) ma różne źródła zegara przełączane programowo, stąd też różne części programu mogą być wykonywane przy różnych częstotliwościach zegara. Także przy debugowaniu sprzętowym używa się timera (o ile da się zrobić tak, żeby był stopowany po natrafieniu na pułapkę).
    Z "trzeciej" strony, ponieważ rdzeń AVR jest dosyć prosty i zawsze dokładnie wiadomo ile taktów wykonywana jest konkretna instrukcja, stąd też nie trzeba robić sztuczek z timerami.
REKLAMA