Diskuzní fórum Elektro Bastlírny

Sháním nějaký obvod RTC typu DS3234, co umí "probudit" spící procesor, a má sběrnici SPI. Ten zmíněný je pro mě moc velký, mám málo místa, a do SSOP se mně moc nechce. Externí krystal teoreticky nevadí.

Měl by být levný. Měl by mít spotřebu v řádu desítek až stovek uA.

Jestli máte pocit, že chci moc, tak můj nápad to není...

Zkus mrknout na toto: http://www.microcrystal.com/images/_Pro ... 049-C2.pdf
Ale osobní zkušenost nemám.

Nebyl by špatnej.

Jenže "on" chce přesnost alarmu nastavitelně v řádu desítek ms - a to mám strach, že sice jeho papír snese všechno, ale realita bude jinde...

Pod 1 vteřinu jsem nic nenašel.

Taky pochybuji, že bude RTC, co dá rozlišení pod 1s. Na druhou stranu snad nic nebrání probudit MCU předcházející sekundu a těch pár stovek ms ho nechat vrčet a odčasovat si to s ním.

To nemůžu kvůli spotřebě. Prostě 10ms akce, 10s spánek.

10s se má časovat od RTC? MCU neumí pustit timer, uspat se a probudit se od přerušení od timeru? Jakou to má mít plánovanou spotřebu, krátkodobou a dlouhodobou stabilitu času?

Procesor má interní RC oscilátor pro wake-up, pak bere cca 10uA, jenže ten lítá -50 až +300 procent. Ale zákazník si dupnul, že to musí být synchronní v rámci maximálně milisekundy kvůli bezdrátovýmu přenosu a kolizím.

Já na té "asynchronnosti" založil svoji metodu, včetně detekce kolize dvou vysílačů, předvedl jsem to, ale letěl jsem, že jsem to vymyslel já a ne on.

Co víc napsat.

Tak s časováním v rámci milisekundy tedy držím zákazníkovi palce, to bych nechtěl řešit. To se bude víc zařízení pravidelně mezi sebou synchronizovat? Jak se to bude řešit na začátku po zapnutí?

Celá ta komedie začala tím, že "stádo" slave bude řídit jednoho mastera. Já to programuju jen se zatnutými zuby. Ale nesmím to nikde říct.

Okrajové podmínky jako zapnutí atd. se neřeší vůbec. Přitom je to docela důležitý.

Náš zákazník používa od ST niečo z M41***. Tvoje podmienky možno splní M41T94.

Ja neco podobneho pred casem taky resil, bylo tam cca 30 vysilacu a jeden prijimac. Nic rozumneho aby to chodilo spolehlive jsem ale nevymyslel, takze se nakonec tahaly kabely.

Bud by se to cele muselo obcas sesynchronizovat, coz prinasi nutnost mit ve slave modulech i prijimac se vsemi problemy s tim spojenymi, nebo casy vysilani ponechat vicemene nahode, dat kazdemu vysilaci jiny interval tak aby vzajemne opakovane nekolidovaly (tusim ze jsem to mel zalozene na prvociselnych intervalech) a doplnit to masivnim CRC pro detekci kolizi.
Cele se mi to ale vubec nelibilo, tak jsem sel cestou tech kabelu i za cenu mnohem vetsi pracnosti pri montazi.

Nevim jak to chces delat ty (mozna s vymyslel neco co mne nenapadlo), ale myslim ze pouzitim RTC si k nicemu moc nepomuzes. Bez opakovane synchronizace se to stejne casem rozjede.

Já to právě založil na pseudonáhodně generovaném času při kolizi (je to RX/TX transmitter, takže umí potvrzení doručení dat, i detekci nosné cizího vysílače), zákazník požaduje atomovou synchronizaci a to vše při 10uA.

Kdykoliv mám pocit, že bych to někde použil, přijde zmíněný genius a udělá z toho paskvil. To mně ovšem nebrání napsat si tam vlastní soft.

Pokud je mozny obousmerny prenos, slo by proste frekvenci toho RC oscilatoru vzdy zmerit treba podle intervalu mezi prenosy a nasledne poslat upraveny cas dalsiho prenosu podle momentalni frekvence oscilatoru tak, aby nedochazelo ke kolizim vubec. Za tech 10sec oscilator snad o tolik neuleti.

Ty slave umí jenom vysílat ?
Pokud ano, tak se to nedá udělat synchronní, jelikož to není čím sesynchronizovat

Umí to přijímat i vysílat. A ta metoda korekce RC mě napadla, mám možnost to synchronizovat s krystalem během probuzení. On vymyslel přidat druhý procesor, co to bude budit, já ho s tím vyhnal, že to je orloj a navrhl RTC.

Uvidíme..