Anriho OoTéčka ...

[A(&F)]

... off-topicové vlákno o všem možným, co Ánriho zajímá, ale přitom se to nehodí nikam jinam (zkrátka aby Anri "zbytečně neplevelil" ... ) ...

[A(&F)]

... nebo jen tak pro pokec ... ...

[A(&F)]

... pokračování "digitální diskuze" z http://upramene.cz/forum/viewtopic.php?p=140609#p140609 ...

Fakt dobrý nápad posunout multiplex před dekodér. Až mě štve, že to nenapadlo mě

... ... mno, teď si nejsem dvakrát jist, zda jsi správně "rozklíčoval" popis zmíněného principu ... neb "multiplex před dekodérem zobrazení" není tím hlavním "fórkem" (byť i to hodně ušetří), ... ten "multiplex před dekodérem" už byla jen taková "třešínka", která z toho tak nějak logicky samovolně vyplynula (přímo si to o to říkalo) ...... hlavní kouzlo toho řešení totiž spočívá především v postupném čítání/načítávání za použití jednoho jediného dekadického čítače pro všechna místa/digity + využití multiplexované paměti, namísto několika čítačů v řadě s jednotlivými paměťmi !!! (std. se pro každé místo/číslovku používá samostatný counter + samostatná paměť/latch + samostatný dekodér) ...... gdyžtak dej vědět, nakreslím blokové schéma ... z něj by to už mělo být už jasnější ...

... ale i tak dík za palec ... ...

... jinak pokud budeš chtít (když už jsem v tom "chlubení" ), tak se někdy třeba aj rozepíšu o "Anri-plexu" a dalších "IO vychytávách" ... mám jich za ty roky docela dost ...... a ne všechny již byly zveřejněny ... ...

... ... Anri ...

[lajos]

Se děsně podobáme, ten šahací intervalový spínač jsem dělal taky , zkusím sem dát zítra fotku digitálního měřiče čehož základ je 7490,7475,74141+3 digitrony z bulharské stolní kalkulačky.

[sisa]

Tož ahoj. :-)

[A(&F)]

... ... ";o* ... ... ... Anri ...

[A(&F)]

Se děsně podobáme, ...

... to přece oba víme už dávno ... ... jestli to nebude tím, že jsme vyrůstali ve stejný době ...

... ten šahací intervalový spínač jsem dělal taky, ...

... v jakým roce?? ... a podle jakýho schématu?? ... ...

... zkusím sem dát zítra fotku digitálního měřiče čehož základ je 7490,7475,74141+ 3 digitrony z bulharské stolní kalkulačky.

... jj, bulharský sčoty ... ... díky jejich veliké poruchovosti vděčný to zdroj základních součástek ... ... já v tom čítači namísto 141-ky měl ruskou nahnědlou klasiku ... K155 ( nebo K156??) ... ... to bylo dááávno ... ...

... ... Anri ...

----------
vysvětlivka pro nebastlíře: ... barva pouzder logických integrovaných obvodů je std. černá (s krásně čitelným bílým popisem) ... kdežto IO sovětské provenience měly pouzdra okrově hnědý (zkrátka v barvě řidčího extrementu ), což bylo velmi příznačný, jelikož se děsně "sr@ly" (byly děsně poruchový) ... + označení bylo natištěno rozmazaně (takže se blbě četlo), navíc soudruzi z ruska sice obšlehli kompletní řadu obvodů od Texas Instruments, ale číselnou řadu (označení typu) si udělali vlastní, tomu celosvětově používanému naprosto nepodobno ... tudíž elektronici v rámci RVHP si museli pamatovat, co u těch "Сделано в СССР", znamená ve vztahu k originálu ... ... ...

[Ilem]

mno, teď si nejsem dvakrát jist, zda jsi správně "rozklíčoval" popis zmíněného principu ... neb "multiplex před dekodérem zobrazení" není tím hlavním "fórkem" (byť i to hodně ušetří), ... ten "multiplex před dekodérem" už byla jen taková "třešínka", která z toho tak nějak logicky samovolně vyplynula (přímo si to o to říkalo) ...... hlavní kouzlo toho řešení totiž spočívá především v postupném čítání/načítávání za použití jednoho jediného dekadického čítače pro všechna místa/digity

Ten princip chápu jako multiplexovaný čítač. Asi jsem napsal blbě před dekodér, měl jsem na mysli až před čítač. Myslím, že jsem to pochopil dobře. Jen jsem teď v hrozném časovém presu, kdy bych vůbec neměl chodit z časových důvodů na fórum, ale probírají se tu tak zajímavé věci, že to zkrátka nevydržím. Už sem si to několikrát zakázal, ale je to droga. Tak potom píšu nepřesně a vznikají nesrovnalosti

Ostatně, pokud tě to zajímá, svým způsobem podobný princip jsem požil kdysi také. Jen mě to nikdy nenapadlo u měřáku. Bylo to na vojně. Chtěl jsem se ulévat z výcviku, tak jsem vymýšlel zlešovací návrhy. Tento se týkal sledování výjezdu aut z autoparku přes čarový kód. Dnes brnkačka, ale tenkrát (v roce 1986), jsem se až po návratu z vojny (když jsem to chtěl patentovat) dozvěděl, že ještě někdo jiný někde ve světě vymyslel čarový kód a má na to patent.
Paprsek nebyl rozmítaný, k pohonu multiplexu jsem použil pohyb vozidla. Čarový kód byl tvořen dvěma řádky čar, z nichž jeden řádek byly jedničky, druhý nuly. Nikdy nemohly být dvě čáry nad sebou, buď byla nula, nebo jednička. Byly tam dva Schmidťáky - jeden na jedničky a jeden na nuly a příchod buď jedničky, nebo nuly dával impulz pro čítač, který posouval posuvný registr, do kterého se ukládal kód auta. Na konci auta osvětlovací lampa dosvítla až na druhý konec brány, kde byl další fototranzistor a ten dal pokyn k porovnání obsahu posuvného registru s kódy aut v paměti a u shodného auta se rozsvítila ledka. Tím dozorce na rotě - 3km od autoparku přesně věděl, které vozidlo opustilo autopark. Tenkrát za mnou dokonce přijeli nějací generálové a chtěli, jestli bych to nemohl modifikovat na letadla. To jsem odmít, protože už takhle byly obrovské problémy s různou intanzitou osvětlení. Nakonec se musela brána autoparku zastřešit. Protože letní polední slunce dokázalo přesytit automatickou regulaci citlivosti.

[A(&F)]

... tak vydrž, v rychlosti čmárnu schéma, z něhož by už mělo být naprosto jasné, jak to celé vlastně funguje ... a co je myšleno tím "jediným čítačem" pro celý rozsah ... ...

[Ilem]

Chápu to tak, že mutiplexuješ po řádech. Načteš jeden řád, dékóduješ, vysvítíš a jdeš na další řád. Pokud jsem to správně pochopil, v principu první digit rozsvěcuješ s periodou 1/10 taktu čítače a druhý 1/100 taktu čítače, atd. Nebo naopak, teď nevím, jestli jdeš od horního, nebo spodního řádu, musel bych si to znovu přečíst. V principu jde, myslím, oboje. Jde mi o nápad, ne o podrobnosti, nápad je dobrý, možná bych při hlubší analýze zjistil, že to jde jen z jedné strany. Myslím, že není potřeba to malovat. Kdybych to někdy chtěl použít, stejně si to navrhnu znova a využiju pouze princip. Ale radši bych se naučil PIC. Tam by se to dělalo elegantněji. Jen toho času, kdyby nebylo tak málo.

[A(&F)]

Chápu to tak, že mutiplexuješ po řádech. Načteš jeden řád, dékóduješ, vysvítíš a jdeš na další řád. Pokud jsem to správně pochopil, v principu první digit rozsvěcuješ s periodou 1/10 taktu čítače a druhý 1/100 taktu čítače, atd.

... ano přesně tak ... ... teď už věřím, že jsi to pochopil ... ... jenom upřesním terminologii ...... s postupně snižujícímu nebo zvyšujícímu se (to je fakt jedno) multiplexovaným výstupem (151) z časové základny (poskládané z řady 90-ek) gejtuju (/gate) vstup toho jedinýho "provozního čítače" (90-ka, ve schematu označena tlustým rámečkem) ... a do ní načtený (často mnohokrát přetečený) výsledek uložím do paměti (89), pak přepnu na další pozici (pomocí 93) a pokračuji v dalším měření ... během měření dochází k zobrazování přes dekodér (47) v 1 kHz běžícím multiplexu (pomocí 192 + 42) ... ... namísto 1 sekundy se tak měří 1,1111111 (plus nějaký ty nano na zápisy do paměti a na resety čítače a děliček) ...

... když jsem onehdá s přišel s tou myšlenkou (použít jediný čítač), tak si všichni svorně ťukali na čelo ... ... že to prý určitě nepůjde, ... protože kdyby to prý fungovalo, tak už se to dávno používá ... ...

... tak tady je to schéma, když už jsem ho nakreslil ... ...

(přerušovaně zakreslen vodič pro rozšíření až na 16 číslovek (např. při více kanálovém provedení)) ...

... + tady je ještě pro srovnání "klasické zapojení", jenž se běžně používá u čítačů, dokola opakujícícho měření, atd. ... aneb "najdi deset rozdílů" ... ...

Kdybych to někdy chtěl použít, stejně si to navrhnu znova a využiju pouze princip. Ale radši bych se naučil PIC. Tam by se to dělalo elegantněji.

... myslíš nějak takhle?? ... ...

(dotatečně opravena drobná chybka v označení + pozměněno rozlišení)

... když jsem o té koncepci čítače před pár dny psal, připomenulo mi to hodně dávnou ideu, že bychom s "chovancema" (s klukama z kroužku) mohli zkusit postavit tento měřič frekvence (na zcela stejném principu = jediný dek. přetékající čítač pro všechny rozsahy), ale nikoliv již za použití RAM + řídící logiky z TTL (neb ta 7489 se dnes už stejně nevyrábí), nýbrž za použití modernějších součástek, tedy MCU coby řídící jednotky, čímž se to celý úúúžasně zjednoduší !!! ... použije se jedna dual-BCD 74390 + 2x RSKO + pár NANDů + PIC (klidně bez krystalu, jenom s vnitřním nepříliš přesným oscilátorem) + 16x4 nebo 16x2 LCD ... a časovka se rovněž spáchá z polovičního množství HC74390, což vše zákonitě přispěje k celkovému zjednodušení a ušetření prostoru i energie (menší počet švábů) ... ... tím pádem i při měření nejvyšších kmitočtů to nebude nijak kritické na programovou obsluhu (ani na interapty), takže si to be problémů budou moci kluci sami modifikovat k obrazu svému / vymejšlet další případná vylepšení ... ..... nehledě na to, že to v podstatě vůbec ani nemusí mít displej ani žádná tlačítka, a vše (tj. zobrazování + nastavování) se bude realizovat přes RS-232 na připojeném řídícím compu, popř. přes bluetooth (BT-05) na androidím telefonu nebo tabletu (čímž se zároveň vyřeší i galv. oddělení), popř. přes 433 MHz (byť ta frekvence není zrovna určená pro tento druh provozu, tak moduly jsou sehnatelné za pár desetikorun) ... zkrátka, může to být pouze krabička (nejlépe napájená jednou li-on 18650, nabíjení samozřejmě řízeno opět pomocí teho PICa) s jedním, dvěma nebo čtyřmi vstupy (záleží, kolik se tam dá gejtů) + jedním digitálním výstupem (ať již drátovým nebo i bezdrátovým), přičemž celý se to v pohodě vejde do několika stokorun ... ...... a pokud by se ta časovka (třeba) doplnila ještě o další švábíky (rovněž s SW nastavováním z toho PICáka, jak jinak, že ), mohla by pak sloužit i jako programovatelná dělička čehokoliv ... ... časem k tomu s klukama ještě můžeme zkusit spáchat mezixicht pro měření LC, atd. ...

... jinak tím, že to bude řízený mcu-čkem, budou fungovat i všechny další příslušný záležitosti, které vyžadují "přenos mezi řády", tj. i prosté čítání počtu jednotlivých impulsů (vč. případného poměrového odčítání na základě dalšího vstupu), měření délky pulsu (nebo jen L či H úrovně), hodiny, stopky, otáčkoměr, časovač (i s výstupem na relé nebo optotriak), měření teploty, atd. ... záleží jen, co se k tomu připojí + dopíše obslužnej soft ... fantazii se meze nekladou ... je to otevřený systém, kde si každý sám rozhodne, nakolik co osadí ...

doplněno: ... samozřejmě bude možné nastavit referenční kmitočet (/"mezule") a po použití mat. fcí (součet/rozdíl, atd.) rovnou nechat zobrazovat výsledný kmitočet ...


... ... Anri ...

----------
HaF: ... ještě k tomu tvýmu "Jen toho času, kdyby nebylo tak málo" a povzdechnutí, že bys taky rád uměl programovat ... ... schválně, ... kolik je to roků, co jsi ode mě dostal PICAXe ??? ... ještě pořád se ti válí v šuplíku ... ... protože pokud bys učení se (a zkoušení) věnoval byť i jen půl hodiny týdně, tak už jsi ho mohl minimálně 2 roky běžně používat ...... když to pomocí histogramů zvládnou i 5-ti letý děti (co ještě neumějí číst ani psát, viz můj nejmladší chovanec ), tak bys to jisto jistě zvládl aj ty ... ... ...... neb čím déle to budeš odkládat, tak holt budeš muset pořád vše dál "natvrdo drátovat" ... ... (věř, u tebe na baráku by ses s ním těžce vyřádil ... ... jak tě znám, zřejmě by to byl nejvíc "zregulovanej barák" ve střední Evropě ... )

[Ilem]

Jo, přesně tak. Jen mi tam uniká, čím chceš synchronizovat čas při použití RC oscilátoru. Na všechno ostatní ano, ale na čítač???? Tam je snad vždy přesnost čítače daná přesností oscilátoru. Ať použiješ jakýkoli princip. Nebo mi něco uniklo?

[A(&F)]

Jen mi tam uniká, čím chceš synchronizovat čas při použití RC oscilátoru. ...

... že ty jsi, Ileme, zase "rychle četl?" ... ...... neb ten výše zmíněný "nepřesný oscilátor" (o RCčku nikde nebyla řeč) bude použit pouze pro PIC (použitím jeho vnitřního vestavěnýho oscilátoru/clocku) ..... přesnost vlastního čítače je (gejtováním) dána časovou základnou s krystalem (který je zakreslen vlevo dole, vedle časovky) ...... a v případě použití coby "klasických hodin" (s budíkem ), stopek, countdownu, při měření délky pulsů, ad., je v zapojení možná cesta z časovky až do mcu (přes multiplex 151), ... kdy pokud by snad bylo zapotřebí mít k dispozici absolutně přesné "hodiny/čas" i během měření, např. pro vytváření měřícího protokolu (přes RS-232 do compu, popř. do možné velkokapacitní paměti připojené pomocí i2c - paralelně k displeji), tak není problém tento (nebo další) spoj natvrdo natáhnout přímo z časovky, z jejího libovolného výstupu (kdy bude interuptem v mcučku vyvolávat rutinu pro obsluhu hodin ... např. každou sekundu, ale klidně i častěji, ... tj. každých 0.1 sec, 0.01 sec, atd., stačí si vybrat) ... ..... ale stejně je v případě přesných hodin nejjednodušší k mcu přes i2c (nebo SPI) připojit RTC (Real Time Clock), tedy čip reálného času (nejlépe s integrovaným oscilátorem), protože jej lze snadno zálohovat jednou "knoflíkovkou" (tudíž se nemusí po každém vypnutí znovu nastavovat), ... navíc krom HH:MM:SS(SS) logicky obsahuje i registry YY/MM/DD ... + často aj další fce a rozšíření (např. RTC Alarm, Watchdog, RAM, EEPROM, atd) ...

... ... Anri ...

[Ilem]

jj, četl jsem rychle, nenapadlo mě, že bys tam dával dva oscilátory. Stačí přece jeden pro PIC a z PIC vytáhnout výstup pro gejtování čítače. Přijde mi to jednodušší. Pak můžeš i pohodlně měnit měřicí rozsah.
Jedině, že bys potřeboval vyšší frekvenci, než umožní takt MCU. Pak by to mělo logiku.
Ale i tak by se dal požít 1 oscilátor a jen vytáhnout takt pro MCU třeba za první 7390

[A(&F)]

... nenapadlo mě, že bys tam dával dva oscilátory. Stačí přece jeden pro PIC a z PIC vytáhnout výstup pro gejtování čítače. Přijde mi to jednodušší. Pak můžeš i pohodlně měnit měřicí rozsah.

... možná, že ti to přijde snazší, ale není to zas až taková sranda, jak se zdá, anžto při použití přímo samotného mcu jakožto časové základny, vznikají pak tyto technické problémy:
- musíš použít rychlejší "procesor" = nezanedbatelná vyšší cena ...
- rutinu měření / časové základny je nutno napsat nejlépe přímo ve strojáku (kvůli rychlosti) ... jakmile použiješ libovolný programový jazyk (překladač), většinou jsi v háji ..... kdy pokud bude zapotřebí v této rutině dodatečně provést nějaké (i drobné) změny, následně to znamená další časově náročné odlaďování ... a nejen toho "timingu" ... ani při desítkách kusů se ti většinou nevrátí vložené úsilí (leda že bys to v tom strojáku úmyslně programoval jen tak pro radost, neb máš hromadu volného času a máš rád komplikace, popř. chceš si dokázat, "že na to máš" a pojal to jako výzvu ... jo, i to se občas stává ... )
- během měření (gejtování) nesmíš povolit vyvolání dalšího neočekávaného přerušení, jinak hrozí nepřesnost (popř. ho musíš předem ošetřit, aby ti nerozhodil časování) ..... nezapomeň, že v té době musí mcu zvládat i další věci nutné pro běh celého zařízení, tj. zobrazování (i když při použití LCD s vlastním řadičem ne, do něj to pouze jednorázově přenese), obsluha tlačítek, obsluha hodin, komunikace s nadřazeným, popř. podřízeným systémem (např. řízení výstupního PWMka na základě vstupního kmitočtu, atd.), atd. ...
- tebou již zmíněnými max limity při měření velmi vysokých kmitočtů ...
- apod. ...
(pozn: ... to už se mnohdy vyplatí použít další "malej procesor" ("slave bejby mcu"), který se bude výhradně starat pouze o tyto "kritické záležitosti" (např. v tomto případě generování gejtu/časové základny, popř. měření délky vstupního pulsu) ... a ten mít (bez možnosti pře-rušení běžícího programu) propojen s hlavním mcu ... )

nehledě na to, že: ...
- já tam žádný další oscilátor nepřidávám, ... neb ten vnitřní oscilátor je v navrženém PICovi již od výroby ... ... a pokud by se snad použilo tvého návrhu "vytáhout takt pro MCU z výstupu prvního děliče 74390", bylo by to do budoucna omezující ...... před každým novým měřením je totiž nutno provést zresetování všech děliček časové základny, kteréžto se provádí právě pomocí mcu, tudíž stejně (byť i jen na malý okamžik = do kompletního dokončení této operace) by se v tu chvíli musel mcu přepnout na vnitřní oscilátor ... jelikož přijít zrovna v té chvíli nějaký interuptík (co by se trefil přesně doprostřed "resetovací sekvence" high pinresettimebase, pause xx, low pinresettimebase), tak by mohl nastat nemalý problém ... interupt by přerušil právě probíhající "resetovací sekvenci" = nedokončil by se tak proces resetu = děličky by zůstaly "viset v nule" = mcu by přestal být krmený takty = kolaps ... ... možným alternativním řešením je sice na dobu "resetu" vypnout všechny HW interupty, ale co když zrovna bude některý z nich zapotřebí?? ...... a vzhledem k tomu, že stabilita vnitřního oscila PICu je pro tyto vytyčené účely více jak dostatečná, tak proč si zrovna s tímto komplikovat život ?? ...
- přepínání rozsahů je zcela stejně komfortní, jako u přímo generované čas. základny ... navíc
- cena těch několika švábů navíc (3x HC390, 1x 151) je záležitostí několika desetikorun (max. do desetikoruny/ks: 390, 151, při větších odběrech sleva) ...
- tím pádem lze použít i pomalý = laciný "procesor" (klidně i ten PICAXe) ..... kterej však i přes své primární povinnosti (měření kmitočtu, ukládání naměřených hodnot, automatické přepínání rozsahů dle momentálního kmitočtu, atd.) bude mít dostatek času na to, aby reálném času např. i přímo v multiplexu ovládal LED displej bez HW řadičem (tj. mcu by při zobrazování přímo generoval kódy pro sedmi-segmentovky a současně by spínal jednotlivé "společné vývody", tedy anody nebo katody číslovek, nahradil by tak rovnou dekodér 7447, ale třeba i ten kodér 7442, bude-li přebytek vývodů) ... k tomu všemi ještě kupříkladu porovnával naměřené hodnoty s předchozími vzorky, odesílal je do compu, pípáním a mrkáním displeje upozorňoval obsluhu na předvolené hraniční hodnoty, roloval údaje na displeji, a kdovíco nevím dalšího, atd. ... [+ k tomu by ještě třeba dělal něco navíc (ať již souvisejícího či nesouvisejícího), např. sám by postupně (dle předdefinovaného algoritmu či tabulky) měnil nastavení parametrů měřeného zařízení a k tomu se zpětnou vazbou kontroloval teplotu na pouzdru výkonového budiče (= ochrana zařízení během měření, např. při hledání ideálního pracovního bodu měniče, apod)] ...... zkrátka, aby měl do budoucna využitelnou rezervu, aby to nebylo postaveno takříkajíc "na knop" ...
- při tomto řešení to i přes přidanou HW podporu paradoxně vyjde cenově laciněji ... ...

... kdy, pokud by se nepoužila uvedená HW podpora (a přistoupilo na "one chip" řešení), ve finiši by si to už kluci nemohli naprogramovat sami (neumí stroják, učit je to by bylo nepřínosné/zatěžující, někteří jsou fakt ještě malý děti), čímž by si pak ani nemohli sami provádět případné změny a rozšíření ... což by ovšem bylo naprosto o ničom, protože by je to nijak významně nerozvíjelo ... rovněž by se to neshodovalo s mým cílem, vychovat z nich dobré techniky, kteří umí používat svou vlastní hlavu při hledání nejschůdnějšího řešení (a to klidně i za cenu mírně zvýšené složitosti) ...

... takže asi tak ...

... ... Anri ...

Edit: ... výše doplněno ...