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][Bascom] Dokładny pomiar czasu trwania przerwania

wicy 03 Cze 2010 12:47 3624 12
REKLAMA
  • #1 8149627
    wicy
    Poziom 22  
    Nie jestem za biegły w timerach i się ciut pogubiłem. Proszę zatem o podpowiedzi.
    Próbuję ustalić ile czasu będzie trwał impuls podawany na INT procesora a jednocześnie zmierzyć czas od początku tego impulsu do początku następnego.
    Jednym uP podaję impulsy na drugi uP.
    
    Do
       Portc.7 = 0                                              'stan wysoki
       Waitms 1
       Portc.7 = 1                                              'stan niski
       Wait 5
    Loop
    

    Drugim uP mierzę czas tego trwania impulsu.
    
    $crystal = 8000000
    Config Timer0 = Timer , Prescale = 256
    Config Timer1 = Timer , Prescale = 1                        'zlicza czas impulsów
    On Int1 Impuls_int                                          'przerwanie impulsów
    On Timer0 Pomiar_czasu                                      'pomiar impulsów w czasie 1sek
    Load Timer0 = 250
    Stop Timer0
    Stop Timer1
    
    '== PRZERWANIE WYZWALANE NA POCZATKU I NA KONCU IMPULSU
    Impuls_int:
       'początek impulsu
       If Pind.3 = 0 Then
          Stop Timer1
          Czas_miedzy_impulsami = Timer1
          Load Timer1 , 0
          Zmienna_pomocnicza = 0
          Start Timer1
       End If
       'koniec impulsu
       If Pind.3 = 1 Then
          Zmienna_pomocnicza = 1
          Czas_impulsu = Czas_impulsu + Timer1
       End If
    Return
    
    Pomiar_czasu:
       Load Timer0 , 250
       Incr Co6ms
       If Co6ms = 125 Then
          Co6ms = 0
          Wynik_wyswietlany_na_lcd = Czas_impulsu
          Czas_impulsu = 0
          Zmienna_pomocnicza_2 = 0
       End If
    Return
    

    Przy podanym impulsie o długości 1ms układ teoretycznie powinien zliczyć w Timer1 8000 impulsów. Zlicza jednak 8088-8093 impulsów.
    Rozumiem, że pewna niedokładność pomiaru może wynikać z niedokładności w podawanych impulsach (Waitms 1). Jednak nadal jest pewna stała niedokładność ~80 taktów. Takty te to pewnie czas procesora "marnowany" w obsłudze przerwania? Mam rację? Jednak nie wiem, które linie uwzględnić i ile one tak naprawdę trwają.
  • REKLAMA
  • #2 8149671
    tadzik85
    Poziom 38  
    Takie rzeczy zwykle robi się tylko na liczniku wykorzystując jego odpowiednie wejścia. A skoro zauważyłeś stały błąd uwzględnij go w wynikach.
  • #3 8149908
    Konto nie istnieje
    Poziom 1  
  • REKLAMA
  • #4 8150006
    janbernat
    Poziom 38  
    Można zrobić tak aby oba mikroprocesory miały wspólny zegar- to po pierwsze.
    To że instrukcje wykonywane w przerwaniach zabierają jakiś czas- to po drugie.
    To że przy wywoływaniu przerwania coś jest odkładane na stos a po powrocie coś jest zdejmowane ze stosu- a to też zajmuje czas- to po trzecie.
    To co proponuje tadzik85 to jest taki "wytrych".
    Jak nie działa dokładnie- to nie zastanawiamy się dlaczego ale- "tu się doda, tu odejmie- i będzie prawie pasować".
    Zacznij od pierwszego- w datasheecie jest jak wyprowadzić sygnał zegarowy z jednego procesora na zewnątrz a drugi ustawić w "external RC"
  • REKLAMA
  • #5 8150061
    wicy
    Poziom 22  
    Oba procesory taktowane są kwarcami zewnętrznymi. Co prawda mają różne MHz, ale to nie ma znaczenia. Pierwszy uP jest tylko testowym sygnałem podającym impuls. Docelowo ma liczyć drugi uP i zupełnie inne impulsy.
    Spróbuję jeszcze dokładniej zrobić podanie impulsu z uP1 na przerwaniach. Powinno to chyba wyeliminować zmienny błąd pomiaru i dać stałą błędu do uwzględnienia w uP2.
  • #6 8150092
    Konto nie istnieje
    Poziom 1  
  • #7 8150381
    janbernat
    Poziom 38  
    wicy napisał:
    Oba procesory taktowane są kwarcami zewnętrznymi. Co prawda mają różne MHz, ale to nie ma znaczenia.

    Ma.
    Dawno, dawno temu w ramach "praktyk studenckich" ciąłem te kryształy przez pierwszy tydzień praktyk a w ostatnim tygodniu mierzyłem.
    W zakładzie na dolnym Mokotowie w Warszawie.
    Te z poniedziałkowej produkcji miały największy rozrzut parametrów.
    Inżynierowie oprócz tego że są najbardziej konserwatywną grupą w społeczeństwie to są jeszcze najbardziej wierzący.
  • #8 8150481
    Konto nie istnieje
    Poziom 1  
  • #9 8150650
    janbernat
    Poziom 38  
    No najpierw trzeba wyeliminować błędy sprzętowe- czyli ma być ten sam zegar.
    A potem sprawdzać program.
    No a procesor to nie jest model idealny- pewne operacje robi szybko- ale- jednak jakiś czas na to poświęca.
    P.S.
    Atom- to nie jest takie oczywiste.
    Po prostu wierzysz w wyniki pomiaru.
    Ale tylko dlatego że dotychczas się sprawdzały.
    No- trochę filozofii.
    Fizycy- czyli inżynierowie- są konserwtystami, wierzącymi w swoje pojmowanie świata- i to najważniejsze- są oportunistami.
    No ale jest to sprawa wiary- przecież wierzysz w to co widzisz.
    Jak im dany model świata nie pasuje- to zaraz przechodzą na inny.
    Dlatego filozofowie nie mogą ich złapać na błędzie.
  • #10 8151536
    wicy
    Poziom 22  
    atom1477 napisał:

    czyli 1,00135 razy za dużo.
    U Ciebie te 1,00135 raza * 8000 = 8010,8 więc trochę błędu to też wprowadza.
    Pozostałe 70 to pewnie wina czasu wykonywania się przerwania.

    U mnie przy 16Mhz wyszło 1,0017, czyli błąd jeszcze większy. Co ciekawe, pomiar na uP2 za każdym razem wychodzi inny. Raz jest to 8083, raz 8087 a jeszcze innym razem 8090. Teoretycznie instrukcje wykonują się tak samo długo, więc błędy pomiaru mogą wynikać faktycznie z niestabilności kwarców lub uP. Wychodzi na to, że w prostym układzie, bez stosowania precyzyjnych generatorów taktujących, pomiar precyzyjny i powtarzalny jest niemożliwy :cry:
  • #11 8151587
    Konto nie istnieje
    Poziom 1  
  • #12 8152615
    rpal
    Poziom 27  
    Uzyj kolego bramek TTL oraz liczników a procka do odczytu ich stanu i ew. wyzwalania nie będziesz mieć takich dylematów.
  • REKLAMA
  • #13 8223660
    Radkoo
    Poziom 12  
    Co do TTL'ów to proponuję bramki 74HC14 - mają one tpLH i tpHL rzędu 17ns - jest to stosunkowo mało nawet przy kwarcu 16MHz - wówczas takt zegara trwa ok 62,5ns - wprowadzi to oczywiście błąd stały ale jak myślę jest to błąd do wyeliminowania.

    http://www.nxp.com/documents/data_sheet/74HC_HCT14.pdf

    Co do twojego głównego problemu to ja bym to zrobił tak, że zaprzągłbym do pracy PWM. Wpisując do licznika powiązanego z PWM'em dokładnie odmierzysz żądaną długość czasu.. Odbiór na drugim procesorze też oczywiście na przerwaniu.

    Pozdrawiam
    Radek
REKLAMA