Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[ATmega32][Bascom] Dokładny pomiar czasu trwania przerwania

wicy 03 Jun 2010 12:47 3462 12
  • #1
    wicy
    Level 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.
    Code:

    Do
       Portc.7 = 0                                              'stan wysoki
       Waitms 1
       Portc.7 = 1                                              'stan niski
       Wait 5
    Loop

    Drugim uP mierzę czas tego trwania impulsu.
    Code:

    $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ą.
    Kamery 3D Time of Flight - zastosowania w przemyśle. Darmowe szkolenie 16.12.2021r. g. 10.00 Zarejestruj się
  • #2
    tadzik85
    Level 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
    atom1477
    Level 43  
    Zobacz w symylacji ile taktów zajmuje przejście od:
    Portc.7 = 0
    do
    Portc.7 = 1.
    Oczywiście symuluj to bez dyrektywy $sim.

    A dwa, to niekoniecznie ta niedokładność wynika z czasu trwania obsługi przerwania.
    Jeżeli to 8MHz to jest taktowanie z wewnętrznego generatora RC to błąd pochodzi od niego.
  • #4
    janbernat
    Level 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"
  • #5
    wicy
    Level 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.
  • #7
    janbernat
    Level 38  
    wicy wrote:
    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
    atom1477
    Level 43  
    janbernat wrote:
    Inżynierowie oprócz tego że są najbardziej konserwatywną grupą w społeczeństwie to są jeszcze najbardziej wierzący.

    To też muszę sobie zapamiętać :D

    Dodano po 5 [minuty]:

    U mnie było tak (kwarc 20MHz):
    [ATmega32][Bascom] Dokładny pomiar czasu trwania przerwania
    [ATmega32][Bascom] Dokładny pomiar czasu trwania przerwania

    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.
  • #9
    janbernat
    Level 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
    wicy
    Level 22  
    atom1477 wrote:

    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
    atom1477
    Level 43  
    Kwarce nie są aż tak niestabilne. Powinny mieć 50ppm.
    Przy okresie 8000 daje to błąd 0,4.
    Ale to jest błąd stały.
    A Ty masz zmienny. Taki Jitter. To wynika prędzej z jakości sygnału i dokładności próbkowania.
    1 cykl można stracić na próbkowanie (jest filtr cyfrowy na wejściach INTx).
    I z 1 na zwłokę wywołania przerwania (Zależnie od instrukcji wykonywanej w programie głównym. Zakładam że masz tam tylko pętlę Do..Loop. Czyli skok trwający 2 cykle. Zależnie od tego czy przerwanie wyskoczy w środku czy od koniec skoku stracisz 1 albo 0 cykli.).
    Oczywiście nie chodzi o samą stratę, ale o to że ona raz może być a raz nie.
  • #12
    rpal
    Level 27  
    Uzyj kolego bramek TTL oraz liczników a procka do odczytu ich stanu i ew. wyzwalania nie będziesz mieć takich dylematów.
  • #13
    Radkoo
    Level 11  
    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