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

[ATmega8] ATmega8: Problem z USART i programowym PWM - serwomechanizm drży

Zygfryt 09 Kwi 2012 02:00 1942 4
REKLAMA
  • #1 10773482
    Zygfryt
    Poziom 9  
    Witam,
    od kilku dni próbuję wygrać nierówną walkę z programowym pwm i usartem na atmedze8. Wysyłam z nadajnika dane za pomocą USART (sprawdzane wielokrotnie na bank są dobre) do płytki z atmegą i serwomechanizmem. Jeżeli serwo jest sterowane bez ingerencji danych z USART to wszystko działa jak trzeba, w momencie gdy chcę wysłać gotowe dane do płytki serwomechanizm zaczyna wariować (drży jakby coś blokowało jego ruch). Myślę, że nie ma potrzeby załączania schematu ponieważ linia sterująca serwem to po prostu PIND3.
    Jako podstawę czasu przyjąłem 80kHz a częstotliwość pwm dla serwa to ok 50Hz. Dane z USART atmega otrzymuje z częstotliwością 60Hz-2kHz (dla tego przedziału zachowanie jest dokładnie takie samo). Prosiłbym o zajrzenie do kodu, mam nadzieję, że coś mi umknęło w samym kodzie a samemu już ciężko wyciągnąć mi coś konstruktywnego z gapienia się nań.

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Na końcu każdego przesłanego pakietu obecny jest znacznik CR. Dane odbierane należą do przedziału {0, ... 80}. Każdorazowo po nawiązaniu połączenia efektem jest widoczne drżenie serwa jak już wcześniej wspomniałem.
  • REKLAMA
  • #2 10773892
    kriss68
    Poziom 20  
    Po pierwsze piszesz, że na końcu pakietu masz znak CR więc czemu go nie filtrujesz? Poza tym te dane 0-80 wysyłasz jako ASCII czy wartość binarną? Bo jeśli jako ASCII to musisz to zrobić trochę inaczej, no i odfiltruj ten CR bo to on Ci miesza.
  • REKLAMA
  • #3 10774320
    Zygfryt
    Poziom 9  
    Liczby wysyłam jako wartość binarną, dzięki za uwagę z tym CR. Jak tylko dorwę się do laptopa to przeprogramuje układ i zobaczę jak się zachowa układ.
  • REKLAMA
  • #4 10775318
    kriss68
    Poziom 20  
    Tylko jak odfiltrujesz wartość 13 to program nie zareaguje Ci na tą wartość. Mógł byś wysyłać zamiast 0 - 80 wartości 14 - 94 i odejmować to 14 w procku.
  • #5 10775592
    Zygfryt
    Poziom 9  
    Więc próbowałem odfiltrować to 13 ale niestety dalej ten sam efekt. Widocznie BTM222 w momencie odbioru wymaga CR i nie przekazuje go do atmegi (tak mi się wydaje). Jedyne co zaobserwowałem to fakt że gdy zapiszę kod nadawczy w ten sposób:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    oraz część odbiorczą:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    To wtedy można powiedzieć, że działa lecz kod ten jest wysoce nieestetyczny i nieoptymalny + żeby zakodować poruszanie serwa z w miarę dobrą płynnością musiałbym dołożyć jeszcze ok. 2 razy więcej tych warunków. Niestety to są przerwania i nie jestem przekonany czy mogę pozwolić sobie na tak sztucznie wydłużony czas przerwania programu (zliczanie tików do pwm itp).
    Może te fragmenty kodu pomogą komuś wpaść na pomysł co to za dolegliwość. Cały czas kombinuje lecz powoli brakuje mi pomysłów.

    edit.

    Dla próby postanowiłem zrobić ten sam kod od nowa (po raz -nasty), wgrałem go na mege i śmiga (jedyne co mogło się okazać problemem to porównując oba kody to rzutowanie przy dzieleniu :O) w każdym razie dzięki za pomoc, pozdrawiam.
REKLAMA