RTV forum PL | NewsGroups PL

Jak zrozumieć różnice w czasach okresów po podziale sygnału zegarowego 100MHz?

Zegar i blad po jego podziale...

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Jak zrozumieć różnice w czasach okresów po podziale sygnału zegarowego 100MHz?

Goto page Previous  1, 2

Oshin
Guest

Tue Feb 19, 2008 5:47 pm   



Filip Ozimek pisze:
(..)
Quote:

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.

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.

Grzegorz Kurczyk
Guest

Tue Feb 19, 2008 6:04 pm   



Użytkownik Oshin napisał:
Quote:
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.

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

John Smith
Guest

Wed Feb 20, 2008 12:08 am   



Quote:
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.

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

Oshin
Guest

Wed Feb 20, 2008 8:33 am   



John Smith pisze:
(...)
Quote:

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

I tak wlasnie zrobilismy Smile
Dzieki.

Pozdrawiam,
M.

>

Oshin
Guest

Wed Feb 20, 2008 8:36 am   



Quote:
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.

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.

J.F.
Guest

Wed Feb 20, 2008 11:18 am   



On Tue, 19 Feb 2008 16:32:46 +0100, Oshin wrote:
Quote:
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...

To wrzuc scalony generator kwarcowy :-)

Quote:
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.

kalibracja kazdej sztuki to bedzie dodatkowych pare sekund i tez
koszty.

Ten wbudowany generator sie nie rozjezdza z czasem i temperatura ?

J.

Oshin
Guest

Wed Feb 20, 2008 12:16 pm   



Quote:


Ten wbudowany generator sie nie rozjezdza z czasem i temperatura ?

Cos tam się rozjezdza (musial bym poszukac ile) ale to nie problem dla

nas gdyz temperatura na produkcji ma byc stała ;)

Pozdrawiam,
M.
>

Górski Adam
Guest

Wed Feb 20, 2008 3:18 pm   



Oshin pisze:
Quote:
Górski Adam 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.


Adamie!
Ja nigdy i nigdzie nie napisałem, że sie nie da oraz, że nie chcemy się
wysilać. Smile
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 Wink

Tak , to ja Smile
Mój GG też nie.

Szkoda że to sie urwało - przynajmniej dla mnie. :)

Adam

Goto page Previous  1, 2

elektroda NewsGroups Forum Index - Elektronika Polska - Jak zrozumieć różnice w czasach okresów po podziale sygnału zegarowego 100MHz?

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map