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

ATMega32A - Niedokładne zliczanie impulsów do T1 bramkowane przez T0

trebuch1 01 Lip 2013 20:05 1617 13
  • #1 12476523
    trebuch1
    Poziom 26  
    Poczyniłem programik w C do zliczania impulsów z zewn. wejścia T1.
    Program zlicza impulsy do T1 w czasie ustalanym przez T0. Sterowanie jest tak ustawione że pierwsze odliczanie wpisywane jest do F1, drugie do F2, trzecie do F3 i tak w kółko.
    Na czas wyświetlania na LCD wyłączyłem przerwania. Wszystko działa ale nie do końca prawidłowo.
    Problem polega na tym że podczas stabilnej pracy generatora impulsów zewn.
    stany F1,F2 i F3 powinny być takie same i stabilne w czasie. Tak jednak nie jest.
    Na 38000 zliczanych impulsów stany wahają się +/-200 i te wahania pływają.
    Aby to ustalić dokładnie czeka mnie wgłębna analiza kodu. Podejrzewam że kompilator C "wymyślił" coś poza kontrolą i należy użyć wstawek asm.

    Moje pytanie. Jakie powinienem spełnić podstawowe warunki w konstrukcji programu aby było b.dokladnie czyli +/- 1 impuls. Załączam ustawienie liczników i procedurę przerwania

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • Pomocny post
    #2 12478259
    dondu
    Moderator na urlopie...
    trebuch1 napisał:
    Na 38000 zliczanych impulsów stany wahają się +/-200 i te wahania pływają.

    Nie analizując Twojego programu, szybkie pytanie: Zerujesz preskaler za pomocą PSRxx?
  • #3 12478779
    trebuch1
    Poziom 26  
    Nie.
    Ustawiam tylko TCCR0 = 5 za każdym powrotem do początku zliczania F1, F2,F3
  • Pomocny post
    #4 12478945
    piotrva
    VIP Zasłużony dla elektroda
    1. Nie używaj przypisań typu Rejestr=liczba. Używaj przesunięć bitowych i nazw bitów w rejestrach.
    2. Ponadto co napisał @dondu - pamiętaj, że zliczając impulsy ze sporymi częstotliwościami musisz wziąć pod uwagę ilość instrukcji maszynowych, które procesor wykona od momentu zgłoszenia przerwania do zaprzestania zliczania impulsów/zapisania wyników.
  • #5 12479109
    trebuch1
    Poziom 26  
    Ad 2) Sprawa znana i oczywista.
    Ad 1) Zastanawiałem się jak pisać w C aby kod maszynowy był jak najbardziej efektywny. Jak wpływa ustawienie kompilatora na efektywność kodu.
  • #6 12479113
    piotrva
    VIP Zasłużony dla elektroda
    Skoro w przesunięciach bitowych i tak są stałe, to kompilator tak czy inaczej zwinie to wszystko do liczby.
  • #7 12481532
    trebuch1
    Poziom 26  
    Poeksperymentowałem z częstotliwościami podawanymi z laboratoryjnego programowanego generatora kwarcowego na wejście T1. Przypomnę czas otwarcia bramki (T0) wynosi 64 ms. Dla fwe = 1000Hz wyniki T1 wynoszą 64 (od czasu do czasu 65) i to jest OK. dla fwe = 50000Hz stany T1 = 32000 +/-200. Czyli potwierdza to że problem jest w reakcji obsługi przerwania. Nie rozumiem tego pływania +/-200. Jeśli program wprowadza opóźnienia to - nawet jeśli stany T1 nie są oczekiwane - powinny być powtarzalne w ramach kilku różnych wskazań.
    czyli błąd powinien być przewidywalny.
  • #8 12481577
    Konto nie istnieje
    Poziom 1  
  • #10 12481781
    Konto nie istnieje
    Poziom 1  
  • #11 12481839
    dondu
    Moderator na urlopie...
    Kolego atom1477:

    atom1477 napisał:
    Ale co miał sprawdzać?
    Przecież sam to pisał.
    Ma sprawdzać czy aby tego nie napisał?

    Zanim się do czegoś przyczepisz przeczytaj pytanie i odpowiedź.
    Napisał jedynie, że nie zeruje, a nie że sprawdził, że to nie ma wpływu na pływanie pomiarów.

    atom1477 napisał:
    Pozatym mi z obliczeń wychodzi że nieresetowany preskaler da błąd +/-12.

    Czyli potwierdzasz, że pływania z tego powodu mogą występować.
    Należy więc wyeliminować tę składową przyczyn pływania wyniku i szukać dalej, wśród tego co wskazujesz między innymi Ty.
  • #12 12481907
    Konto nie istnieje
    Poziom 1  
  • #13 12481932
    dondu
    Moderator na urlopie...
    atom1477 napisał:
    Więc jak dla mnie miał sprawdzić czy zeruje.

    A jesteś pewien, że to zrobił? Bo ja nie mam pewności, ponieważ nie napisał, że to zrobił. Dlatego zadałem mu ponowne pytanie, na które zamiast autora odpowiedzi udzielasz niepotrzebnie Ty.

    atom1477 napisał:
    Ale chodziło mi o to że mają mały wpływ i cos ma większy.

    Ja tego nie podważam, wręcz przeciwnie. Wskazuję jedynie na to, że na końcowy efekt pływania, oprócz tego co Ty piszesz, może mieć wpływ to co wskazałem ja. A w takim wypadku uważam, że należy wyeliminować wszystkie przyczyny, na czym autorowi zapewne zależy.
  • #14 12492471
    trebuch1
    Poziom 26  
    Temat wreszcie rozwiązany. W funkcji inicjalizacji T0 najpierw wpisałem zerowania preskalera: SFIOR |= (1<<PSR10);
    (Byłem zdziwiony ponieważ w Studio6 w dołączonej bibliotece nie miałem tego bitu zdefiniowanego więc zrobiłem to sam we własnym programie). Pomogło z zakresie wprowadzanego błędu preskalera a to też ważne.
    Wskazania nadal pływały ale mniej o ok 10%.
    Ujednolicając zapisy C do postaci analogicznej jak resetowanie preskalera, zmieniłem zapis TTCR0 =5;
    na selektywne ustawienie wymaganych bitów
    TCCR0 |= (1<<CS00);
    TCCR0 |= (1<<CS02);
    Jakież było moje zdziwienie osiągniętą stabilnością wskazań w T1.
    Wartość licznika T1 utrzymywała się na poziome 38447 (pomiar co 1 s) i od czasu do czasu 38448 czyli super dobrze.
    Przypomnę czas zliczania czyli czas przerwania od T0 ustawiony na 64ms.

    Dziękuję wszystkim za pomoc.
REKLAMA