Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

ravmar 18 Mar 2013 21:53 1356 7
  • #1 18 Mar 2013 21:53
    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: cpp
    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)

    0 7
  • #2 18 Mar 2013 22:04
    tmf
    Moderator Mikrokontrolery Projektowanie

    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.

    0
  • #3 18 Mar 2013 22:15
    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.?

    0
  • #4 18 Mar 2013 22:40
    dondu
    Moderator Mikrokontrolery Projektowanie

    ravmar napisał:
    Zaraz, zaraz czy człowiek ukrywający się pod tym loginem, który tyle razy mi pomógł to nie jest p. Tomasz F.?

    Owszem jest :)

    0
  • #5 18 Mar 2013 22:52
    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.

    0
  • #6 18 Mar 2013 23:06
    tmf
    Moderator Mikrokontrolery Projektowanie

    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.

    0
  • #7 19 Mar 2013 00:16
    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.

    0
  • Pomocny post
    #8 21 Mar 2013 21:52
    tmf
    Moderator Mikrokontrolery Projektowanie

    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.

    0
  Szukaj w 5mln produktów