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

ATtiny2313 USART i błąd transmisji

gary2007 22 Gru 2009 14:28 2022 3
REKLAMA
  • #1 7422263
    gary2007
    Poziom 14  
    Potrzebuje odebrać 11 bajtów danych od urządzenia, które wysyła je z prędkością 9600 bps. Do tego celu wykorzystam ATtiny2313 i USART pracujący w trybie asynchronicznym. Mikrokntroler ma wykorzystywać swój wewnętrzny oscylator (nie chce dołączać kwarca zewn.). Normalnie mam ustawiony podział częstotliwości przez 8 więc pracuje na 1MHz. Pojawia się problem z doborem prędkości transmisji ponieważ UBBR w takim przypadku nie jest całkowite i odczytując z dokumentacji ATtiny2313, błąd prędkości transmisji wyniesie -7%. Z tego co widze to dużo lepszym rozwiązaniem byłoby wyłączenie podziału częstotliwości, tak by zostało 8 MHz, wówczas błąd maleje do 0,2%. Wiem, że dodanie odpowiedniego kwarcu pozwoliłoby na wyeliminowanie tego błędu, jednak tak jak napisałem na wstępie nie chce tego robić.

    Gdyby ktoś byłby uprzejmy wyjaśnić zagadnienie błędu transmisji byłbym wdzięczny, ponieważ nie do końca czuje to zagadnienie. Jak przeprowadzić ewentualne obliczenia, które pozwoliłyby stwierdzić czy błąd na poziomie -7% pozwoli na poprawne odebranie tych 11 bajtów i czy mam brać pod uwagę całość danych czy tylko 1 bajt?
  • REKLAMA
  • Pomocny post
    #2 7422381
    arnoldziq
    VIP Zasłużony dla elektroda
    Przestaw zegar na 8MHz. 7% błędów przy odczycie z 'obcego' urządzenia jest raczej nie do przyjęcia.
    Jeżeli komunikujesz się z urządzeniem które sam zbudowałeś, jesteś w stanie przewidzieć jakie dane otrzymasz, zastosujesz jakiś mechanizm sprawdzania poprawności otrzymanych danych, to te 7% nie jest jeszcze problemem.
    Ale w tym przypadku (zgaduję) jesteś skazany na odczyt gotowych danych i raczej nie masz możliwości sprawdzenia czy dane dotarły poprawnie i np. w przypadku błędu, wysłania zapytania o powtórzenie danych.
    Z drugiej strony, jeżeli w w/w urządzeniu istnieje mechanizm sprawdzania błędów i wymuszenie powtórnej wysyłki, to nie masz się czym przejmować, wszystko zależy jak oprogramujesz uC.
  • REKLAMA
  • #3 7422874
    mirekk36
    Poziom 42  
    Dokładnie - skoro sam widzisz, że wyłączenie podziału taktowania przez 8 (CKDIV8) spowoduje ci procent błędu na poziomie 0,2 to czemu nie korzystasz z taktowania procka 8MHz z wewn oscyla tylko uparcie stosujesz 1MHz ? ;)

    Przecież zastosowanie 8MHz to same korzyści a dla ciebie od razu poprawna transmisja przez RS232 na prędkości 9600

    Zamiast samemu obliczać ten błąd procentowy transmisji (wzory masz przecież w PDFie) to zawsze sobie zajrzyj na ostatnią stronę rozdziału UART każdego procka AVR. Tam masz podane procenty błędów prędkości przy zastosowaniu różnych częstotliwości taktowania - od 1MHz do 16MHz.

    Zasada jest taka, że jeśli przy danym taktowaniu procent błędu jest +/- 2% to można śmiało działać. Jeśli większa odchyłka to lepiej zastosować tzw kwarc przyjazny dla RS232.

    Na podstawie tej tabelki szybko określisz sobie jakie wartości kwarców są przyjazne dla RS232 - spójrz na przykład na procenty błędów dla kwarca 11,0592MHz ;)

    ale jak mówiłem - najspokojniej w świecie każdy procek taktowany wewnętrznym oscylatorem 8MHz będzie ładnie śmigał na 9600 - a nawet masz możliwość jeszcze dokalibrowania tego (gdyby w jakimś było coś lekko nie tak) za pomocą bajtu kalibracyjnego OSCCAL. Ale to już ładnie robi się z poziomu programów a nie ustawiania fusebitów.

    A przy okazji gdy taktujesz procka 8MHz zamiast kociej prędkości 1MHz to szybciej wykonują ci się pętle i inne krytyczne czasowo operacje. Więcej rzeczy możesz w przerwaniach robić itd itd
  • #4 7424958
    gary2007
    Poziom 14  
    Obce urządzenie ma tylko bit parzystości i nie mam możliwości powtórzenia wysłania danych. Tak też właśnie zrobie, że ustawie Procek na 8 MHz. Właśnie te dane dotyczące błędów podałem z tabelki. Pytałem tylko dlatego że nie mam pojęcia co to znaczy ze ten błąd jest na poziomie 7% i czy to jest do przyjęcia. Czy to oznacza, że podczas próbkowania każdego bitu przez mikrokontroler wszystko przesuwa się maksymalnie o 7% w stosunku do czasu trwania tego samego bitu który został nadany z prędkością 9600? Więc jeśli bitów jest 8 to mamy przesunięcie o 56% przy próbkowaniu?
REKLAMA