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.

[danhard]

Ale mě to jede v cyklu DIV1-4, HOD1-4, TON1-4, TOFF1-4, jen je to časově posunuté proti čítači stavu, tak, že HOD1 (jednotky minut) je stav 0.
Na ROMku následující hodnoty jde D0-D3 na A0-A3, S0, S1 jde na A4, A5 a na A6 jde S2, S3 přes NAND 7400, na A7 jde denní/týdenní cyklus.

S0, S1 jde přímo na A0, A1 RAM.
Ve stavu TON1-4 se modifikuje adresa A2 na RAM, v první půli taktu se čte TON, to se zapamatuje v 7475 a v druhé půli taktu se čte HOD a na konci se výsledek srovnání zapisuje do registru.
Dtto TOFF a adresa A3.

Když je S2,S3 na 1, tak výstup blokuje hodiny pro modifikaci a adresa je nastavena na DIV.
Celé to zajišťuje jedna 7400.

Logika přenosu - 7420 + 1/2 7474, druhá 1/2 je generátor přenosu při inkrementu tlačítkem.

Logika budíku - časování se bere z 7442 + 2 inverze výstupů, pak hradlo 7410, 1/2 7474 na přenos rovnosti a na výstupu 2 hradla 7410 a nahození ON, nebo OFF v 1/2 7474.

Nic víc tam není, nastavování je řešené přepínači, tam by se dalo ještě popřemýšlet

[Ivan_Ryger]

Dobrý den. Opäť som mal trocha času na posunutie sa vpred. Posielam upravenú verziu schémy, zohľadňujúcu Vaše posledné myšlienky.

Uvažujem, že adresné bity S2, S3 čítača stavu rozhodujú, či operujeme s registrami hodín HOD (0,0), budíka TON (0,1), budíka OFF TOFF (1,0) alebo deličky DIV (1,1). Keďže segmentovky SEG0..3 máte zapojené na párne výstupy 7442 (Q0,2,4,6), uvažujem, že jeho adresné vstupy (a1, a2) sú totožné so spodnými adresnými bitmi RAM (a0, a1) a ďalej adresné vstupy 7442 a0 (váha 1) a a3 (váha 8 ) sú použité aj na prepínanie medzi zobrazením hodín a časov budíka nasledovne:

Spínač „zobraz čas ON“ môže voliť medzi priamym alebo invertovaným bitom čítača S2/~S2 a „zobraz čas OFF“ môže voliť medzi priamym alebo invertovaným bitom čítača S3/~S3. Súčasne uvažujem, že výstup Q1 (adresa 0001) indikuje adresu registra TON1 a výstup Q8 indikuje adresu registra TOFF1, ktoré sa dajú použiť na inicializáciu kaskádneho vstupu rovnosti (=) komparátora 7485 na začiatku porovnávania. Výstup Q9 indikuje adresu (1001), jeho prechod L->H indikuje zmenu adresy TOFF4 -> DIV1. Toto som zatiaľ nevyužil.

K logike prenosu čítača: Signál ~DIV/HOD sa dá použiť na inicializáciu čítača preddeličky. Jeho prechod do nízkej úrovne (H->L) sa môže zaviesť ako krátky pulz cez R-C derivačný článok do asynchrónneho vstupu ~R 7474, čo zabezpečí nastavenie signálu ~CARRY do nízkej úrovne na inicializáciu preddeličky hodín DIV1.

Ak potom prenos do vyššieho radu sa stane neaktívny (~C==1), prenos do vyšších radov zostane zablokovaný cez pascu (~Q=~S) na úrovni 1, pokiaľ nepríde opäť krátky impulz do asynchrónneho ~R vstupu pri nasledujúcej adrese DIV1.

Momentálne riešim, ako sa robí nastavenie hodín, minút a inkrement.

Otázky:

Predpokladám, že stlačením „zobraz čas ON“ & „nastav minúty“ sa logicky povolí inkrement registra TON1 (jednotky minút). Podobne sa povolí inkrement pri TOFF a hodinách. Keďže tlačidlom inkrementujete hodnotu aktuálne zobrazovanú na displeji, nabáda sa na tento účel nejako využiť výstupy obvodu 7442 používané na riadenie digitov. Je táto úvaha správna?

V prípade ručného inkrementu času TON a TOFF je prenos medzi jednotkami a desiatkami (hodín alebo minút) zabezpečený cez signál ~CARRY, ako aj v prípade hodiniek, akurát nenastáva prenos cez DIV->HOD, len registre budíka sú inkrementované signálom z tlačidla.

Keďže registre budíka TON a TOFF sú používané v režime porovnávania, signál ~RAMWR bude pri porovnávaní blokovaný. Ďalej, keďže inkrement registrov hodín je riešený v druhej fáze (polcykle) hodín a inkrement registrov budíka TON a TOFF sa realizuje pri stlačení tlačidla zobrazovania, predpokladám, že zvolenie tohto tlačidla zablokuje modifikáciu adresy, aby sa hodnota týchto registrov v RAM mohla inkrementovať. Je to takto správne?

K činnosti tlačidla inkrementu: Spomínali ste, že jedna polovica 7474 je použitá na inkrement tlačidla. Jedno stlačenie tlačidla generuje inkrement o +1 alebo dlhé zatlačenie generuje postupný inkrement s nejakou periódou?

Zostáva mi voľné hradlo 7420, ktoré by sa dalo využiť na vyhodnotenie logických podmienok inkrementovaného registra v spojení s voľnou polovicou 7474, ktorú ste naznačili, že je na tento účel použitá.