Elektroda.pl
Elektroda.pl
X
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Oscylator wewnętrzny w PIC i wpływ temperatury na transmisję USART

18 Sty 2014 12:49 1704 11
  • Poziom 15  
    Witam, czy warto zaryzykować i używać wewnętrznego oscylatora w mikrokontrolerze pic 18, gdzie układ ma pracować w szerokim zakresie temperatur i wykorzystywana jest transmisja USART 57600 czy lepiej zastosować zewnętrzny kwarc z kondesatorami, żeby mieć większą stabilność o wartość np. 3.6864 MHz.
    (Przy takiej f i 57600 błąd jest = 0%). Pytam, ponieważ mam ograniczone miejsce na PCB, ale nie chce też mieć sytuacji, że wszystko się rozjedzie i będzie sporo błędów. Jeśli ktoś ma doświadczenie w tym zakresie, proszę o sugestie. Z góry dziękuję.
  • PCBway
  • Poziom 1  
  • Poziom 25  
    bez problemu powinno działać , a dla większej pewności możesz zastosować jakąś kontrolę błędów .
  • PCBway
  • Poziom 15  
    Witam, mikrokontroler to 18F26K22, nie sądzę aby miało znaczenie to czy jest to produkcja seryjna czy nie, chodzi o rozwianie wątpliwości. Przy taktowaniu oscylatorem wewnętrznym
    16MHz dla 57600 mamy błąd 2,12%, nie wiem czy nie będzie znacznie poważniejszych odchyleń dla np. -25 lub w drugą stronę + 50. Ilość danych w jednej paczce <= 300 znaków. Zastanawiam się
    nad użyciem kwarcu 3,6864 MHz, gdzie błąd jest 0 % dla podanej prędkości, pozostaje pytanie jak ustawić rejestry dla w/w częstotliwości.
  • Poziom 1  
  • Moderator Mikrokontrolery Projektowanie
    Cytat:
    16.2 Clock Accuracy with Asynchronous Operation

    The factory calibrates the internal oscillator block
    output (HFINTOSC). However, the HFINTOSC
    frequency may drift as VDD or temperature changes,
    and this directly affects the asynchronous baud rate.


    Two methods may be used to adjust the baud rate
    clock
    , but both require a reference clock source of
    some kind.

    The first (preferred) method uses the OSCTUNE
    register to adjust the HFINTOSC output. Adjusting the
    value in the OSCTUNE register allows for fine
    resolution changes to the system clock source. See
    Section 2.6 “Internal Clock Modes” for more
    information.

    The other method adjusts the value in the Baud Rate
    Generator. This can be done automatically with the
    Auto-Baud Detect feature (see Section 16.4.1 “Auto-
    Baud Detect”). There may not be fine enough
    resolution when adjusting the Baud Rate Generator to
    compensate for a gradual change in the peripheral
    clock frequency.
  • Poziom 15  
    Marek_Skalski napisał:
    Jeżeli produkcja jest jednostkowa, to na pewno masz czas, ale nie wiadomo czy masz warunki aby przeprowadzić kalibrację w pełnym zakresie temperatur i napięć.
    Jeżeli produkcja jest seryjna, to pewnie masz warunki, ale księgowy może kwestionować taką rozrzutność z punktu widzenia czasu i dodatkowego procesu.
    Tak, jak wcześniej pisałem, możesz kalibrować oscylator wewnętrzny w pewnym zakresie za pomocą bitów do tego służących.
    Jeżeli już chcesz użyć kwarcu, to może 14,7456MHz (bliżej HSINTOSC 16MHz) lub przynajmniej 7,3728MHz, ponieważ minimalna częstotliwość na wejściu PLL to 4MHz. Po to jest PLL, aby z niej korzystać.
    Transmisja ~300bajtów @57600 trwa min: 52ms, a DMA tutaj nie ma, więc masz do wyboru albo czekać w stanie aktywnym na wysłanie każdego bajtu aby go załadować do EUSART, albo wrzucać bajt (<2us) i usypiać rdzeń na czas transmisji (~174us).
    Ustawienie transmisji jest trywialne: Na stronie 280 (dokument 41412F) masz wzory na obliczenia wartości zapisywanej do rejestrów generatora. Dodatkowo, na stronach 281-283 masz tabele, z których wystarczy odczytać wartość i możesz je porównać ze swoimi obliczeniami. Według moich obliczeń, dla kwarcu 14,7456MHz i BR=57600, do rejestru generatora musisz wpisać 3 i skasować SYNC, BRG16, BRGH. Teoretyczny błąd wynosi 0, ale przy -25*C możesz gubić bajty
    Pomysł z kontrolą błędów jest bardzo dobry. Możesz użyć zwykłej sumy składników dołączanej do końca pakietu, możesz użyć CRC16 (o ile wystarczy mocy obliczeniowej), możesz użyć podziału pakietów na mniejsze z żądaniem przesyłania potwierdzenia prawidłowego odbioru z drugiego urządzenia.


    Nie pytałem o rzeczy oczywiste dotyczące USART, chodziło mi o ustawienia rejestru, gdzie podaje się częstotliwość taktowania, a w opcjach nie ma wartości pomiędzy 3 a 4MHz czy 14,7456.

    Nie napisałem, że dane będą tylko wysyłane, podałem przykład dla długości ramki, dane też będą wysyłane przez urządzenie zewnętrzne do mikrokontrolera,
    więc w usypianie raczej się bawił nie będę.

    Niestety właśnie chodzi o czas, nie ma go na testy itp., inaczej sprawdziłbym dokładnie jak to wygląda w dokumentacji, zakładając temat miałem nadzieję na to, że ktoś może miał podobny problem i wie czego należy unikać, albo co można spokojnie użyć jak np. wewnętrzny oscylator.

    Z góry dziękuję za sugestie.
    Pozdrawiam.
  • Poziom 1  
  • Poziom 15  
    Tylko dlaczego mam użyć 14,XX a nie 3,XX ?
    Częstotliwość pracy w tym układzie spokojnie wystarczy, chyba, że masz inne "przeciw" stosowaniu kwarcu 3,6864 MHz gdzie dla 57600 jest teoretycznie 0% błędu ?

    Odnośnie wartości rejestrów to chodziło mi o coś innego, nie o BRG, ale to już nie jest istotne, bardziej chodzi mi o to, czemu kwarc 14,XX a nie 3,XX ?
  • Poziom 1  
  • Poziom 15  
    Witam, temat rejestrów nie jest już istotny, program jest w trakcie pisania, ze zmianą parametrów itp. powiązanych z częstotliwością nie będzie problemu, rozumiem, że nie ma więcej "przeciw" jeśli chodzi o kwarc 3,XX MHz ? ;).Chyba czeka mnie po prostu dokończenie softu w taki sposób, żeby układ potrafił sprawdzić czy przesłane dane jakby to nazwać - mogą być "wiarygodne" i powtórzyć raz jeszcze przesłanie tych samych informacji, po czym zrobić porównanie. Mikrokontroler w odcinkach czasu co ok 5-15 minut będzie otrzymywał dane w postaci paczki < 300 znaków, co jakiś czas, też z przedziału 5-15 minut będzie wysyłał paczkę nie większą jak 300 znaków.

    Według danych producenta kwarc powinien pracować od -20 do +70, moduł komunikujący się z mikrokontrolerem też będzie narażony na tę samą temperaturę.