Přenos signálů
Moderátor: Moderátoři
Přenos signálů
rozšiřujeme jednu časomíru o externí displej a bohužel jsme narazili na dost podstatný problém.
Mám v podstatě dvě možnosti:
1. využít hodiny a povely a vnější displej udělat autonomní, což ze zkušenosti vím že nemá dostatečnou přesnost a lže o pár setin sekundy.
2. kamarád by raději vyvedl BCD kódy pro sedmisegmentovky, ale to je moře drátů.
Takže napadá vás někoho jak přenést 15 BCD kódů elagantním způsobem?
Ideální by bylo použít nějakou průmyslovou sběrnici na 3 dráty a vzdálenost 10m. Bohužel s mikroprocesory si neruzumíme, ale kdyby to někdo byl schopen to vyřešit za rozumnou cenu, i to by byla možnost.
Pro představu je to charita pro hasiče, 3 časy 1:00,00.
Nějaká stokoruna se vždycky najde, ale pár tisícovek už ne.
Přečíst informace v hlavní jednotce a poslat je do externího displeje.
Avšak bez mikroprocesoru bych se do toho ani nepouštěl - což vás nemusí trápit, s tím bych pomohl, jen je potřeba mít aspoň nějakou dokumentaci k původní časomíře.
Když tak pošlete mi SZ a pobavíme se o tom přes SKYPE.
Důležité budee zobrazení zastaveného (mezi)času, v podstatě zkopírování stavu buď BCD výstupů před dekódováním (a dekódovat v obou displejích) nebo rovnou zkopírování stavu budičů segmentů, tím odpadne u podružných displejů dekodér, ale pro přečtení výstupů a jejich aktivaci u podřízených displejů bude vyžadovat vícebitový čítač s pamětí, než pro BCD.
Přenos může být pak klidně sériovou linkou, údaj bude stejný, jen se na ostatních displejích objeví o desetiku sekundy později.
Pokud by bylo zpoždění sér. přenosu dat např. 100ms, tak to přeci pro pozorovatele nevadí, že hodnota na displeji se "ustálí" až za 100ms, nebo se pletu?
Tenhle princip se používá např. pro spojení PLC a Operátor. panelu. Na PLC běží úloha a data se sér. přenáší na panel a zpět. Panel zde plní jen funkci "terminálu". Podstatné je, že číslo, které vidí operátor odpovídá číslu v PLC. To že je tam malé zpoždění nehraje roli.
Zpoždění přenosu nehraje sebemenší roli, protože je nikdo nestihne odečítat, důležité jsou jen výsledné zobrazované 3 (mezi)časy.
Nejsnazší by právě bylo číst asi ty BCD kódy, proč číst 7 informací když stačí jen 3.
jasin: bohužel je to klasická technologie TTL čítačů s BCD děličkami a klasickým výstupem.
mtajovsky: princip přenosu hodin jsme už jednou použily, vlastní časomíra je řízena PLCčkem, vyhodnocuje se na PC (pěknej prográmek rovnou vše vyhodnocuje a řadí výsledky) a displej pro diváky je řízen hodinami. Divil by ses jak jsou lidi schopní se hádat že displej ukázal čas o 0,02s jiný než časomíra, přestože bylo předem řečeno že displej je pouze informativní. Právě tomu se teď chceme vyhnout.
- kevin_mitnick
- Příspěvky: 1812
- Registrován: 20 kvě 2007, 00:00
- kevin_mitnick
- Příspěvky: 1812
- Registrován: 20 kvě 2007, 00:00
Pokud by se data přenášela čistě sériově, pak bych volil snímání stavu jednotlivých výstupů BCD multiplexerem adresovaným z jednočipu, který si stav každé BCD číslice uloží do paměti a po dokončení čtecího cyklu všech míst ho odešle po vedení na podřízené displeje, které budou fungovat opačně: procesor přijatá data rozstrká do jednotlivých dekodérů s latchem.
Rutiny pro sériový přenos pro různé jednočipy jsou dostupné už hotové.
Asi bych to čtení výstupů řešil postaru se Z80SIO (U851D), když už tam jsou pažravá TTLka: umí 8 datových vstupů a umí udělat paket ve formátu RS232 a ještě si poklepat rukou s protějším zařízením, když se mu to dobře vysvětlí.
Jde navíc hardwarově jen o to, multiplexovat do těch 8 bitů všechny výstupy z čítačů a na konci je zase rozhodit do těch správných latchů před dekodéry v displejích.