Programovatelné hodiny

[Ivan_Ryger]

Dobrý deň, pridávam moje riešenie, ktoré by som rád porovnal s Vaším prístupom.

ALU
Činnosť PROM v kombinácii s RAM a adresným čítačom ste už naznačili skôr.
V PROM Využívam jeden z adresných vstupov na odlíšenie adresy registrov preddeličiek a adresy hodín (diódová kombinačná logika D1, D2). Nasledujúce 2 adresné vstupy rozlišujú registre jednotiek minút/desiatok minút/jednotiek hodín/ jednotiek poldní (10-6-12-14) alebo v prípade preddeličky modulo 15-16-16-16. Ďalšie 4 adresné vstupy sú spätná väzba minulej hodnoty registru. Posledný vstup je C (carry), ktorý je zavedený cez D flip-flop.

Na riadenie zápisu (R/W) do pamäte RAM používam 16.384kHz hodiny vstupujúce do adresného čítača 7493 (jeden cyklus zápis/čítanie pre každú adresu).

Na porovnávanie času s budíkom, sú použíté obvody 7475 (latch) a 7485 (komparátor magnitúdy). Do 7475 zachytím hodnotu registra hodiniek a porovnám s hodnotou registra časovačov. Keďže za jeden celý cyklus (16 adries) môžem porovnať hodnotu iba 1 registra, medzivýsledok porovnania uložím v pamäti a porovnávam sekvenčne v 4 cykloch. Na medzivýsledok používam dva samostatné D flip-flop pre čas ON a čas OFF.

Krokovanie adresy registra (minúty/desiatky minút/hodiny/poldne) pre toto sekvenčné porovnanie robím dodatočným vydelením frekvencie najvyššieho bitu (MSb) adresného čítača pomocou 2-bitového čítača zostaveného z deličiek dvomi (7474). Táto hodnota sa zmení raz za 1 celý cyklus (16 adries). Ich hodnota je neustále porovnávaná s okamžitou hodnotou adresného čítača. Keď nastane zhoda, je povolený buď prepis LATCH registra (register hodiniek) alebo pamäti prenosu porovnania času ON, času OFF pomocou kombinačného obvodu tvoreného IC3, IC4A, IC5.

Zobrazovanie som vyriešil nasledovne:
Dekodér 1-z-10 má využité 3 po sebe idúce adresy. 2 nižšie postavené bity krokujú pozíciu 0-1-2 pre cyklické prepínanie medzi segmentovkami, 2 vyššie bity určujú, či sa zobrazujú hodiny, budík ON, budík OFF. Zatiaľ som nedoriešil ako ošetriť zobrazovanie registra na najvyššej adrese -poldní, zatiaľ na tomto stojím. Predpokladám, že by sa dal ešte využiť na toto dodatočný 5. vstup 74188?

Inkrement minút-hodín-poldní - tu pre nedostatok hradiel som urobil diódovú logiku sledujúcu podľa zatlačeného spínača, ktorá logickým AND vyhodnocuje, či výstup adresného čítača zodpovedá hodinám, minútam alebo dňom. Potom, ak je stlačené tlačítko, vytvorím cez derivačný článok impulz dlhý 1 plný adresný cyklus, čo v logickom súčine vytvorí logickú 1 počas doby trvania adresy minút, hodín alebo dní. Tu moja otázka znie, či sa vo Vašom návrhu inkrement nastavenia času deje iba jednorázovo pri stlačení tlačítka alebo počas doby jeho držania?

Predpokladám, že pre nastavenie/ inkrement hodnoty hodiniek (alebo budíka) používate carry logiku. To by vyžadovalo externou logikou (nie v tabuľke PROM) zakázať prenos medzi najvyšším registrom hodiniek a registrom budíka, ktorý v normálnej prevádzke zostáva nemenný. Prenos (slúžiaci takto na inkrement) by bol povolený len impulzom z tlačítka inkrementu. Toto zatiaľ nemám dokončené. Iné riešenie pre nastavenie registrov mi zatiaľ na um neprišlo.

Ešte nemám vyriešený výstup budíka, tu mi vychádza, že by bolo treba si zapamätať hodnotu porovnania/prenosu, keď adresa registra dovŕši najvyššiu adresu (teda poldní).

Taktiež ešte nemám urobený denný/týždenný cyklus.

Zostávajú mi voľné 2 hradlá 7404, ktoré zrejme budem musieť použiť na inverziuq
⁵ hodinových signálov na registre medzipamäti porovnávania.

Určite by sa celý tento obvod dal vyriešiť elegantnejšie, tu by ste mi veľmi pomohli nasmerovať, ktorú časť by ste urobili ináč, lebo je urobená neefektívne.

[danhard]

Asi to budu muset z toho bastlu namalovat a pak to můžeš vylepšit

Data do zobrazování a na tabulku následující hodnoty jdou až z latche 7475.
Stav "zapisovala se 0" jde přímo do D přenosu, ale zápis do RAM a do přenosu se dělá jen když když je inkrement, tj. když je přenos z předchozí číslice.

Srovnávání budíku se dělá v jednom cyklu.

[Ivan_Ryger]

Ďakujem, toto bolo presne nakopnutie, už som to potreboval. To usporiadanie operácií dáva zmysel. Skúsim sa nad tým potrápiť.

[danhard]

Nejvyšší bit tabulky 74S287 je přepínání denní/týdenní cykl.
A u 7442 mám zapojeno více výstupů, takže to používám také k řízení budíku.
Vstupy jsou zpřeházené, výstup 0, 2, 4, 6 jde na buzení číslic, výstup 1, 8, 9 na řízení budíku. Na to je tam ještě 7410 a 7474, nic víc.
U čítače cyklu 7493 jde na přímo Q0, Q1 na A0, A1, ostatní Q2, Q3 se přepíná, podle toho, co to má dělat.

[Ivan_Ryger]

Pre rozlíšenie modulo-N čítania ROM potrebuje mať na adresnom vstupe predošlú hodnotu (4 bity), adresu registra (2 bity) a rozlíšenie hodinkovy čítač/preddelič (1 bit). Ak je MSB vstup obsadený výberom tabuľky (1/7 dní), nezostáva voľný vstup na Carry. Vychádza mi, že PROM má natvrdo napálené len po sebe idúce hodnoty pre časovače a čítače, nemá vstupnú informáciu o prenose a inkrement by sa robil iba povolením zápisu novej hodnoty do RAM. Je moja uvaha spravna?

V mojom návrhu som uvažoval, že registre deličky, čítačov hodín budú adresované postupne za sebou, čo umožnilo jednoduchú carry logiku medzi postupnými registrami.
Ak ale robíte 4 porovnania hodín a času ON, OFF v jednom adresnom cykle, adresy hodín a budíka su asi v pamäti prekladané (napr. hodiny-min1, budík ON min1, budík OFF min1, hodiny min10, budík ON min10, budík OFF min10,...). Je tato uvaha spravna?

[danhard]

Ale Carry nejde vůbec do ROMky následující hodnoty, ale do logiky zápisu.
Když není zápis, tak je jedno, co je na vstupu RAM.
Když se nahodí C, tak se provede zápis. C je aktivní v 0 (protože součin jde z 7420) a přepisuje se na konci hodin, je tam past na 1 (/Q spojené s /S) a nahazuje se krátkým pulzem do /R, odvozeným od čítače S.
Čítač cyklu si radši označ S jako status.
Cykl jede v pořadí HOD, TON, TOFF, DIV, na začátku DIV se nahodí C.

A teď musím zkontrolovat, jestli se mi parazitně neinkrementuje TON jednou za týden

Tak dobrý, další vychytávka, čítač dní nečítá od nuly, tudíž přenos negeneruje

[Ivan_Ryger]

Premýšľam nad organizáciou registrov.
V mojom prvom kostrbatom riešení (lineárne adresovanie, zložitejšie vyhodnocovanie podmienky budíka) boli všetky 4 registre pre každý blok DIV, HOD, TON, TOFF v po sebe idúcich adresách (DIV1-4, HOD1-4, TON1-4, TOFF1-4).

Podľa vášho receptu som prišiel k dvom možným alternatívam.

Prvá má 4 registre preddeličky pred navzájom sa prekrývajúcimi registrami HOD-TON-TOFF, potrebuje 3 klopné obvody pre zachytenie Carry a porovnania. Nevýhodou je, že carry má dva rôzne režimy ukladania (každá nasledujúca adresa, každé 4 adresy).

V druhom prípade je potrebné 4 klopné obvody, časovanie je viac vyrovnané, okrem momentu, keď sa robí carry medzi registrom preddeličky a registrom hodín.

Farebné šípky znázorňujú, kedy sa realizuje prenos medzi jednotlivými registrami.