Diskuzní fórum Elektro Bastlírny

Ahoj, chlapi.

Dostal jsem za úkol postavit pro naše hasičské družstvo stopky. Potřebujeme dvě dráhy a myslel jsem, že pro tréninkové účely bych přidal i 3 mezičasy. Takže jsem (za pár korun) koupil displej 4x20 znaků (44780) a rozdělil jsem ho tak, abych na prvním řádku měl první časy levé a pravé dráhy, na druhém řádku 2. časy až na 4. řádku by byly časy při proběhnutí cílem. Když jsem to pokusně v Pascalu naprogramoval a nahrál do PICu (mám 16F877A) tak jsem zjistil, že když chci přepisovat všech 80 znaků na displeji, tak že to prostě za 0,01s (to by mělo být rozlišení časomíry) nestihnu. Řešením by určitě bylo před startem zobrazit 00.00:00 a po startu namísto setin zobrazit dvě pomlčky a displej přepisovat jednou za sekundu a po proběhnutí cílem zobrazit setiny.
Ale - neexistuje nějaké řešení, jak displej donutit zobrazit všech 80 znaků za méně než 0,01s?
Pokud to nejde, tak koupím LED zobrazovače a buď je připojím nějak v multiplexu nebo použiju nějaký řadič (např. MAX7219). S MAX7219 bych použil šest 7segmentovek k jednomu MAXu, do všech bych posílal stejná data a po proběhnutí příslušného úseku bych jen zablokoval vstup Mode konkrétního proběhnutého úseku. Frekvenčně (rozlišení 0,01s) by to snad mělo fungovat.

Raději bych ale použil ten LCD displej - nemáte se stopkami (ať už vícekánálovými nebo rychlými) někdo zkušenosti?

Díky za odpovědi.

Jirka

Není přeci potřeba přepisovat najednou všech 80 znaků. Přepiš jen to, co se v daném okamžiku změnilo.
Tím ušetříš spoustu času.

OK, ale i tak budu v nejhorším případě přepisovat 8x6 znaků. Myslíte, že to za setinku sekundy stihnu?

Asi jsem trošku mimo, ale proč přepisovat všechny údaje najednou? Pro informaci stačí zobrazovat desítky/jednotky sekund a stovky milisekund. Tedy změna hodnoty na displeji jednoho času 1x za 100ms. Až po zastavení teprve zobrazíš i desítky milisekund. A tedy v daný okamžik můžeš přepisovat jen jeden čas, takže se čas zápisu do LCD dost sníží / rozdělí. Pro průběžné zobrazení stejně nebude přesnost nikdy rozhodující, protože čas pořád poběží, takže zdržení zobrazení není tak vážný problém. Hlavně aby to počítalo přesně (vlastně co nejpřesněji) reálný čas .

Pochybuju že LCD bude 10ms na změnu vůbec stíhat, a i kdyby stíhal, co asi uvidí pozorovatel při měnící se hodnotě? všechny prvky matice více-méně aktivní s různým jasem.
Maximálně pro efekt můžeš zobrazovat 10x za vteřinu, což oko ještě rozliší a stopky ti to ještě budou stíhat zobrazovat.
Máš věrohodně objektivní snímání start a stop impulsu na těch 10 ms?

Vyřešit zobrazování na LCD je prkotina. Přece se nemusí zobrazovat na 0,01s, hlavně, aby to 0,01s počítalo a zobrazování stačí například 3x za sekundu, to je úplně fuk, až se časomíra zastaví, tak může maximálně trvat 1/3s než dojde k obnovení LCD, což se nepozná, ale dosažený čas bude správný.

Ale tyhle stopky s uC mají zcela jiný problém, alespoň já na to nemůžu přijít:

Když je jen jedna dráha (jeden čas), může mít klidně i několik mezičasů, to je jedno, to žádný problém není, ale nastane, když bude drah víc. Je potřeba aby změřený úsek byl pro všechny dráhy stejně zobrazen. Možná to píšu krkolomně,tak uvedu příklad třeba pro 3 dráhy.

Jsou tři registry, kde se v každém bude pro každou dráhu přičítat 1 v intervalu 10ms odvozeném od přerušení 100Hz a teď to nastane. Naprosto ve stejný okamžik dojde k protnutí cíle (např. spojíme cíl 1 a 2 a ten aktivujeme, tzn. oba časy by měly být stejné) od cílového impulzu dojde program do větve "zastavení času 1" a to bude chvíli trvat a v této době může dojít k dalšímu přerušení 10ms, který zvýší hodnotu v registru času2 a pak dojde teprve k provedení větve "zastavení času 2" ale tam už je o impulz víc, což je špatně.

Možná by se to dalo dělat tak, že i start na dalších drahách bude úměrně posunut o dobu co se zpracovává obsluha "startu1" ale nějak nemám žádný nápad, jak by se to dělalo.


Taky bych potřeboval stopky na 4 dráhy pro požární sport, které by byly menší a lehcí než ty, které jsou vyrobeny ještě z integráčů, ale zase "profi" výrobek, který na všech drahách ukazuje korektně.

Kdyby nás někdo nakopl (raději jinam, než do ), jak na to, tak by to bylo super.

Mozna je to blbost,ale co takhle vzhledem k velikosti a cene by snad nebyl problem pro kazdou drahu jeden procesor?Synchronizovat by snad sly jednim ext. oscilatorem a ovladani by nebyl snad problem spolecne.Ale je to jen tak blby a asi nejjednodussi reseni,(snad )

rkozeluh píše:Jsou tři registry, kde se v každém bude pro každou dráhu přičítat 1 v intervalu 10ms odvozeném od přerušení 100Hz a teď to nastane. Naprosto ve stejný okamžik dojde k protnutí cíle (např. spojíme cíl 1 a 2 a ten aktivujeme, tzn. oba časy by měly být stejné) od cílového impulzu dojde program do větve "zastavení času 1" a to bude chvíli trvat a v této době může dojít k dalšímu přerušení 10ms, který zvýší hodnotu v registru času2 a pak dojde teprve k provedení větve "zastavení času 2" ale tam už je o impulz víc, což je špatně.
...
Kdyby nás někdo nakopl (raději jinam, než do ), jak na to, tak by to bylo super.

Když budeš cílové/mezičasové snímače obsluhovat (kontrolovat jejich stav) v tom přerušení 100Hz, tak se to co popisuješ nemůže stát. Stačí mít na snímačích hw nebo sw klopák, který se protnutím nahodí a pak při následujícím přerušení 100Hz se příslušný(é) čas(y) zastaví. To, jestli jeden snímač byl protnut 3ms před druhým stejně nedokážeš změřit (indikovat rozdílným časem).

Pro zrychlení naplnění displeje je nutné po každém bajtu (nibblu) číst stav BusyFlag a další zápis vykonat hned jak se BF změní na "0". Ale nevím, jestli se v Pascalu dá bojovat o nějaké mikrosekundy.

Komunikace s LCD modulem se dá zrychlit použitím osmi bitové komunikace místo často používané čtyř bitové.

Ale jak již zaznělo, nemá smysl zobrazovat nic méně, než sekundy. Teprve po zásahu cíle v dané dráze to má smysl.

Oba cíle mohou být spojené přes OR hradlo a po zásahu se vyvolá externí přerušení. To pak obslouží zastavení času pro dráhu, která byla zasažená. Je ale potřeba tří vstupů.

Kluci,
posílám první verzi jakéhosi vývojového diagramu, mělo by v něm být zamezeno chybnému odečtu jak to popisuje "rkozeluh".
Jednou z jistě mnoha podmínek aby to fungovalo je to, že cílová fotobuňky musí být zacloněna aspoň 1/100s, což by při rychlosti závodníka 8m/s a šířce jeho těla 0,3m mělo být splněno. Ale kdyby tam mávl při dobíhání jen rukou, tak to by asi muselo být řešeno přerušením od portu procesoru (nebo HW klopným obvodem).
Jinak princip je takový, že se po stisku tlačítka start vynuluje registr pro přerušení od RTC (aby se první setina načetla opravdu až za 0,01s), spustí se přerušení a skočí se do nekonečné čekací smyčky. Při přerušení se zkontroluje, jestli je vůbec ještě nutné do nějaké dráhy příčítat 1/100s (jestli už není doběhnuto na všech drahách). Pokud je ještě nějaká dráha nedoběhnuta, tak se inkrementuje hlavní čas, přepočte se případné přetečení setin do sekund, sekund do minut a postupně se kontroluje doběhnutí jednotlivých drah. Když dráha není doběhnuta, tak se přepočítaný hlavní čas zkopíruje do této dráhy a čas se pošle na displej. Po testu doběhu u všech drah se znovu vypočítá příznak pro doběhnutí všech drah a zase se skočí do nekonečné smyčky.Další start je v tomto diagramu řešen resetem procesoru.

To je první nástřel, tak mě za případné blbosti v něm nekamenujte.
Jirka Malík

Ještě poznámku k vývojovému diagramu - aby to fungovalo, tak celý ten proces od inkremetace času až po konec zobrazení poslední dráhy na displeji musí být kratší než 1/100s, jinak by přerušení znovu inkremetovalo hlavní čas, ale ta předchozí inkrementace by ještě nebyla dokončena u všech drah, což by byl průšvih. Proto jsem se ptal na rychlost zobrazení znaků na LCD.

Jirka

Mám tu na řešení ještě jeden problém. Mám takové tušení, že obsluha LCD běží v přerušení, tzn. že máme dvě přerušení, která se musí obsluhovat, 1. - přičítání setiny a 2. zobrazování na LCD, jak vyřešit toto?


A i kdyby LCD nebylo v přerušení, tak ve chvili, jak se pracuje na zobrazování a dojde k přerušení od přičítání setiny, tak zhavaruje LCD.


A ještě jedna věc: já ten vývoják v tom pdf nevidím celý, chybí horní část. Je to jen chby u mě, nebo to je špatně převedený?

Přepisovat LCD v přerušení je blbost. Zobrazení není podstatné, podstatné je počítat přesně čas. Takže měření času v přerušení, zobrazování v hlavním programu klidně metodou "jak nejrychleji to jde". Zápis do LCD pak nemá proč zhavarovat, když přerušení na LCD nesahá. A dá se tak měřit klidně i na tisíciny sekundy, když je dokážou zachytit čidla.

To anonym:
Nejdřív jsem myslel že to nepůjde řešit Vámi navrhovaným způsobem, ale ono to možná půjde, i když si jist úplně nejsem. Jako příklad si vezměmě stopky pro dvě dráhy, rozlišení 1ms. Trochu otočím moji vizi a dejme tomu, že program bude po startu donekonečna zobrazovat data na displeji "jak nejrychleji to půjde" a občas si odskočí na přerušení (kde provede přičtení 1ms do hlavního řasu, kontrolu přetečení setin do sekund a sekund do minut a zkopírování tohoto "hlavního času" do všech drah, které ještě nedoběhly). To by procesor měl za 1ms zvládnout. Pak se běh programu vrátí do zobrazování. Takže se může stát, že čas pro 2. dráhu se bude zobrazovat už jinak než čas 1. dráhu, protože mezitím došlo k přerušení a přičetla se 1ms. Jenže to asi nevadí, protože až se provede tento přenos 2. času na displej, tak už se bude zobrazovat aktuální čas 1. dráhy (a tento čas může být jiný od starého času 1. dráhy o několik ms, ale to neva, stejně to nikdo neuvidí). Jo, takhle by to mohlo jít.
Důležité je, aby se v jednom přerušení přičetla 1ms do všech drah, které ještě nedoběhly.
Díky, anonyme. Zkusím to přepsat do vývojáku. Mimochodem - vývoják jsem včera převedl špatně a nevšiml jsem si toho, omlouvám se. Převáděl jsem to pomocí PdfFactory. Při převodu přes Adobe je vše OK.

Jirka Malik