Zegar i blad po jego podziale...

U¿ytkownik "Oshin" snipped-for-privacy@alpha.net.pl> napisa³ w wiadomo¶ci news:fpe9dp$s86$ snipped-for-privacy@nemesis.news.tpi.pl...

Na jeden takt zegara po podziale sklada sie 10 taktow zegara przed podzialem. Czyli blad x 10. I nadal pozostaje +- 10%. Nic nie zyskujesz. Dokladnosc w zaden magiczny sposob nie poprawia sie.

Maciek

Mylisz jitter z niedokladnoscia czestotliwosci.

Przy jitterze czas sredni jest dobry, tylko zbocza maja odchylke od prawidlowej pozycji.

A jeszcze masz inne generatory gdzie ten blad moze sie rozprzestrzeniac na wieksza ilosc cykli .. ale to juz patrz szumy fazowe generatora.

J.

(...)

(...)

Dzieki. Czyli z zegara np 96000M +/- 10% dzieląc przez 10 ni jak nie zrobię RS232 (9600kb)....:( Pozdrawiam, M.

A skad ten zegar pochodzi ? Moze jednak stabilizowany kwarcem ?

Natomiast asynchronicza transmisja stosowana w RS232 dopuszcza ok 3% odchylki czestotliwosci. 555 ma zdaje sie lepsza stabilnosc.

J.

Tylko przykład :)

Za drogo ;)

A sprawa jest taka że w MSP430 chcieliśmy zastosować zegar z wewnetrznego generatora RC. Ale taki zegar ma rozrzut od 800K do 1.5MHz i niestety z UART powiedział dość....:) Nawet dla 1200b :)

Pozdrawiam, M.

Oshin pisze:

Ale napisz co oznacza owe +/- 10%. Czy to niestabilność częstości (wariancja allana) czy czy może stała dewiacja częstości czy jitter.

No ale nic nie stoi na przeszkodzie, zeby transmisje poprzedzic czyms w stylu AA55 i w programie synchronizowac sie z tym sygnalem. Wtedy twoja czastotliwosc nie ma wiekszego znaczenia (o ile dzielnik dla RSa potrafi wystarczajaco sie dostroic). Jesli w trakcie dzialania oscylator ci plywa to mozesz taka synchronizacje okresowo powtarzac. Jeszcze inna mozliwosc to manchaster, niektore AVRy maja stosowny dekoder na pokladzie.

Oshin pisze:

Bez problemu da się to zrobić na MSP nawet z zegarem RC wew. Tylko trzeba się trochę wysilić

Możesz się na przykład przełączyć na zwykły port i zmierzyć długość tego co przychodzi przy pomocy timera.

Adam

U¿ytkownik "Oshin" snipped-for-privacy@alpha.net.pl> napisa³ w wiadomo¶ci news:fpeolf$6h2$ snipped-for-privacy@nemesis.news.tpi.pl...

A musi byæ UART ? A je¶li UART, to 8-bitowe znaki ? Skróæcie znaki a tolerancja na b³±d zegara wzro¶nie.

e.

Górski Adam pisze:

Adamie! Ja nigdy i nigdzie nie napisałem, że sie nie da oraz, że nie chcemy się wysilać. :) Rozwiązań jest mnóstwo (np. autosynchronizacja o które pisze T.M.F.). Albo na przykład mozna skorzystać z prekalibrowanych zegarów, których dane sa we FLASHu. MSP... Spokojnie.

Ja mam spojrzeć na problem z punktu widzenia DfM a to naprawdę zmienia sposób patrzenia, gdzie każda sekunda pracy automatu kosztuje ileś tam setnych centa co dla miliona sztuk daje konkretne pieniądze...

Wracając do początku - prosty podział zegara nie załatwi sprawy z UARTem a dodatkowo rozrzut technologiczny na poziomie 0.8-1.5MHz może mieć wpływ na zegar we FLASH Memory Timing Generator Rozwiązaniem jest dla nas użycie danych kalibracyjnych, przy których stabilność zegara jest już OK. Pozdrawiam, M.

PS Czy to z Tobą kiedyś był ten 'deal' dla Hadasa -AZ-COM ?? (PCB) Mój GG się nie zmienił ale jestem dostępny tylko wieczorami ;)

Filip Ozimek pisze:

Częstotliwość. Niestabilność częstotliwości :)

Pozdrawiam, M.

Oshin pisze:

Chcesz popędzać RS'a z zegarka mechanicznego? ;-)

Filip Ozimek pisze:

Dobre :D

Klient się uparł na _tanie_ rozwiązanie więc _my_ teraz mamy problem... Ale "nasz Klient nasz per Pan"

M.

Oshin pisze:

No bo to jest tak: jitter jest niezależny od częstości ale szumy fazowe skalują się z kwadratem harmonicznej. Więc dzielenie nie zlikwiduje jitteru. Ale być może wolne transmisje mają mniejsze wymaganie co do pływań czasu nadejścia zboczy, więc na 1200bps da się coś przepchać. W sumie trudno cokolwiek więcej doradzić przy małej liczbie szczegółów. Ale +/- 10% to dużo, nawet bez podania skali czasu na jakiej to pływa.

Filip Ozimek pisze: (..)

Dzięki Filip. To postaram się przedstawić problem (choć rozwiązanie już mamy)

1. Jest układ mikroprocesorowy gdzie sygnał zegarowy MCLK jest generowany z wewnętrznego generatora RC (R zewnętrzne tak po prawdzie)
2. Średnie częstotliwość takiego zegara w naszej konfiguracji 1.048MHz
3. Dla takiej częstotliwości ustawiamy rejestry podziału/konfiguracji zegara dla UART dla predkości 9600b.
4. Niespodzianka - Częstotliwość zegara MCLK może sie zmieniać w zakresie 0.8 - 1.5MHz w zależności od procesora (fizycznie od chipu). Taka technologia - wiadomo jak z pojemnościami robionymi w krzemie.

Dla takiego "rozrzutu" częstotliwości nie da się znaleźć jednego ustawienia rejestrów, przy którym działał by UART (nawet dla 1200b) Indywidualne strojenie UARTA do częstotliwości zegara MCLK za duzo kosztuje podczas produkcji.

Stąd więc moje pytanie czy aby czasem błąd zegara nie podzieli się przez zastosowanie dzielników - nie podzieli się gdyż względny błąd jest stały. Juz wiem gdzie się myliłem.

Ani jitter ani szumy fazowe tutaj nie maja wpływu tylko dokładność pojemności w krzemie....

Ale jak pisałem wcześniej... miało być tanio.

Pozdrawiam, M.

Użytkownik Oshin napisał:

Witam Taki problem pojawia się chyba w każdym procku popędzanym wewnętrznym oscylatorem RC. Nie znam MSP430, ale z powodzeniem uzyskuję 9600bps (a i z 19200 też nie ma większych problemów) na AVR-ach poganianych wewnętrznym oscylatorem. Tu również występuje problem, że co procek to inna czastota, ale AVR-y mają wewnętrzny rejestr kalibracji oscylatora wewnętrznego. Po zaprogramowaniu kalibruję ten oscylator i wartość zapamiętuję w EEPROM-ie. Rozwiązanie daje mi wystarczającą stabilność w dość szerokim zakresie temperatur.

Pozdrawiam Grzegorz

Proponuję użyć MSP430 serię 2xx. Mają DCO z 4-ema skalibrowanymi częstotliwościami z dokładnością 1%. K.

John Smith pisze: (...)

I tak wlasnie zrobilismy :) Dzieki.

Pozdrawiam, M.

Dzięki Grzegorz. Jak juz napisałem wyżej. W MSP da się dobrać tak współczynniki że by RS zadziałał z różnymi zegarami. Problem jest że trudno dobierać te współczynniki indywidualnie dla każdego egzemplarza na linii produkcyjnej... Tak jak pisałem wczesniej - użyjemy danych kalibracyjnych dla DCO

Pozdrawiam, M.