Tolerancia on-chip oscilatorov

[Andrej Jancura]

Dňa 13. februára 2014 15:19, Jan Waclawek <konfera na efton.sk> napísal(-a):

> >
> >>
> >> Ale ratal by som s tym, ze to na ten cely rozsah teplot nebude bohvieco,
> >> tych 5% nepisu nahodou. A na tych grafoch pre ten PIC12F683 si vsimni,
> ze
> >> ten graf (co bude asi priemer pre vela meranych kusov) v celom rozsahu
> >> teplot a napati sice neuhne ani o percento, ale ten rozptyl ide aj do
> >> +-3%, a to uz moze byt fatalne. Inaksie povedane, to, ze na jednom kuse
> si
> >> zmerias nejaky priebeh, Ti nezaruci, ze to bude aj na inych kusoch tak.
> >>
> >
> >No ja som pozeral len na ten 10f20x a tam z tej tabulky si myslim, ze to
> >treba drivovat z 5V zdroja. Ale to si iba myslim, minimalne je to dalsi
> >bod, ktory si treba zapisat do poznamok a brat na neho ohlad pri designe.
> >Vtedy by to mohlo mat tych +-1% v celom teplotnom rozsahu...
>
>
> Urcite nie. Bavime sa o datasheete PIC10F200/202/204/206, DS40001239E,
> str.70.
>

Ano, to je posledny a aktualny.


>
> Tolerancia oscilatora INTOSC +-1% plati len pre VDD=3.5V a 25 st.C. Inaksie
> povedane, ta kalibracna hodnota, ktora je ulozena vo FLASH, je dobra len
> pre VDD=3.5V.
>

Toto si musim este premysliet v klude. Zatial mam len poznamku, ze bude
treba riesit napajanie a jeho kolisanie s teplotou. Teda nebude to take
trivialne ako som si povodne myslel. Zatial mam totiz len prvu ideu ako by
to mohlo cele vyzerat a pisem si rozne poznamky a postrehy k designu.


>
> Podla tych grafov v datasheete k PIC12F683 (ano, ja viem, ze to iny svab a
> ze to pre 10F2xx bude mat obmedzene pouzitie, ale ver mi, ze to zhruba tak
> bude), pri 25st.C a 5V napajani je uz ta frekvencia uhnuta o cca +0.3
> -1.3%.
>
> Pre rozsah 0 st.C az +85st.C pre VDD medzi 2.5V az 5.5V plati +-2%, a pre
> cely rozsah teplot a cely rozsah napajacich napati plati +-5%.
>

To je uz dost nepouzitelne a pokial mi bolo zname, tak UART chodil +-5%
total error. Takze ak odskoci tolko len oscilator bude treba hladat nejake
ine riesenie toho prenosu, myslim nejake jednoduche kodovanie, ktore by sa
este dalo do toho cipu nakodit, alebo ist dostatocne pomaly a vyuzit pritom
tu skutocnost, ze vacsina hw-uartov sampluje vstup 16x baud. rychlost. a
strcit to do celkovej chyby. Tiez su to len idey a jedna z veci, s ktorymi
sa treba pohrat a vyskusat ich.


>
> Typicke hodnoty si mozu strcit za klobuk; neviem ako Ty, ale ja potrebujem,
> aby ten geret urcite fungoval, a nie len typicky fungoval... ;-)
>

Ale zase nestras, budes rad, ked ti to bude fungovat aj typicky. Vzhladom
na to, ze mne na stole nechodi ani hw seriova linka na dvoch inych mcu, to
kurvitko budes ladit sakrametsky dlho... :) Nasiel som nejaky workaround,
ale sucasne s nim som pochopil, ze bude ine a tiez s nim nic neurobim.


>
>
> >> Vsimni si este aj v datasheete pri tych udajoch v tabulke tie poznamky o
> >> poctivom blokovani napajania.
> >>
> >
> >Hej na to som pamatal, ale ten 10nF je uz dalsia suciastka. A ako tak
> >pozeram bude na tej doske viacej kondenzatorov ako vsetkeho ostatneho.
> >Takze urcite pride aj na katovanie kostov... :)))
>
> No, mozno to take horuce nie je, ak to bude SMD kondik narvaty rovno na
> nozickach a zdroj bude nejaky slusny...
>

Myslim, ze pod pojmom slusny sa dost obmedzi vyber, alebo dostatocne
skomplikuje navrh.


>
>
> >> Ak ten UART je obojsmerny, da sa robit autobaud resp. kalibracia podla
> >> prijimanych dat.
> >>
> >
> >No to som prave chcel vylucit, povodny zamer bol len obycajny Tx. A to som
> >chcel urobit s ohladom na 8 bitovy timer resp. 8 bitovu premennu na 9600 a
> >menej, podla toho, ako by vysla cakacia slucka. Kvoli jednoduchosti by som
> >nechel pouzivat unsigned int, lebo to sa uz blbo programuje... Teda bola
> by
> >to dalsia komplikacia, ktorej by som sa rad vyhol ak by to slo.
>
> Chapem.
>
> Pozri, zalezi na okolnostiach - na medzikusoch (prevodniky urovni, kabel) a
> na protikuse. UART by mal vcelku bez zasadnejsich problemov chodit do +-3%
> , v idealnom pripade (dokonala prenosova trasa, dokonale presna
> protistrana) aj trocha viac.
>
> Na druhej strane, aj protistrana sa moze prisposobit, robit autobaud apod.
>

Moja idea bola este posielat na zaciatku kazdeho paketu synchronizacne byty
a podla toho urobit ten prijimaci UART. Ale ako som uz napisal, su aj ine
moznosti. Budem si musiet sadnut a trocha pocitat a experimentovat.


>
>
>
> >> Kedze v tej mojej aplikacii to PICko je priamo
> >> kvoli meraniu a vysielaniu teploty, tak asi budem moct kompenzovat tu
> >> chybu rovno na zaklade merania teploty... :-)
> >>
> >
> >Vidis, toto ma nenapadlo, dakujem za inspiraciu.
>
> Este stale sa obavam, ze vzhladom na naznaceny rozptyl bude treba robit
> kalibraciu.
>

Rad by som zostal pri tej jednej, ktoru uz urobil vyrobca.

Dakujem ti ale za to, ze si si nasiel cas a trochu sme to rozobrali. Urcite
to mas rozpracovane lepsie ako ja, ale aj tak tych par bodov, na ktore si
poukazal, ma inspirovalo. A hlavne tu tabulku v DS som vecer naozaj
prehliadol. Ak by si mal este nejake pripomienky a napady, rad podebatim.

A.

_______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20140213/033011c4/attachment.html>