Nejakych 15ns by bodlo :).

[Wek]

>> Ak som dobre videl, ten DS nedefinuje ziadny vztah medzi OSC1/CLKOUT
> Podle tech maluvek to sedi. Logika v MCU se nedela asynchronni, ale vzdy
synchronni.
> Takze bych predpokladal, ze vse je vztazeno k referencnim hodinan.
Ano, synchronne, ale nie k JEDNYM referencnym hodinam.
Ten 5ns presah dat nevznikol nahodne.

> Pokud jsou interne rozfazovany, tak opet synchronne :-)))
Ano, ale nikde nevidim nakreslene, ze ako presne.

> Ale co Panu Jirimu brani se na to posivat nejakym slusnejsim ukazovatkem, a
kdyz ho nema,
> ta co to krmit treba 100Hz a koukat se na to nejakym bazmekem na LPT port,
rekl bych
> ze rozfazovani bude temer shodne pri 100Hz i 10MHz :-))))
Som zvedavy, ako rozfazovanie trebars o 5 ns uvidi "bazmekom na LPT porte"
:-))) A ci bude skumat, ako sa to rozfazovanie meni napr. od teploty alebo
medzi jednotlivymi varkami :-)))))
Podla datasheetu zacne pulz WRx o 5 ns skor ako su platne data. A to uz moze
byt dost na to, aby sa prave vtedy vyskytla hrana CLK a na "prvej nabeznej
CLK1" boli este neplatne data (+ treba mysliet este aj na setup time latchu,
delay vyhodnocovacej logiky apod.).
Asi to tak nebude, ale naco riskovat, ked je poruke jenoduchsia a ista cesta.
Navyse, kedze "pozriem sa" to nie je podla datasheetu, kedykolvek to vyrobca
moze zmenit (a pritom dodrzat vsetko, co je v datasheete uvedene), a tym nasa
nadherna prepracovana synchronna logika zrazu zacne robit psie kusy.

Synchronna logika je fajn vec, ale tam, kde su referencne hodiny definovane
(kratke e) poruke.

A este jedna vec, "prva nabezna" OSC1 znamena, ze druhu nabeznu treba
odignorovat, t.j. este tam treba vkladat nejaku logiku navyse. So vsetkymi
nasledkami.

Este stale si myslim, ze tu je adekvatne rychlejsie hradlo a latch. Hadam
74HCxx nie je jedine riesenie.
Howgh.

wek

PS. To HC to nestihne so zarukou, lebo hold time je podla specifikacie
(Philips) prave 5ns, a k tomu este treba pripocitat to hradlo...