[BETA] Diskuzní fórum Elektro Bastlírny

ZdenekHQ píše:Ono, když se používá přerušení ke generování přesných pulsů, tak se dopočítává korekce - t.j. zohledňuje se doba, která uplynula od vyvolání přerušení do jeho obsluhy (dá se vyčíst z časovače) a ta se následně odečte od hodnoty nového nastavení časovače. Pak to tiká přesně.

Po výpočtu té korekce se potom provádí druhá korekce, kterou se eliminuje čas potřebný na ýpočet předchozí korekce. Po ukončení druhé korekce se provádí třetí korekce, kterou se upraví chyba zůsobená výpočtem druhé korekce. Pak se musí udělat 4. korekce na eliminaci chyb zpoždění způsobeného výpočtem předchozí korekce ... hmm, prostě česká cesta. Stejnou používá český parlament při tvorbě českých zákonů.

Ta druhá korekce může být pro čas na vykonání instrukcí od stopnrtí časovače po jeho následné spuštění v obsluze přerušení. Ten čas je v programu jako konstanta. Pro nějaké další a další iterace nevidím důvod.

Měření času jako sumy intervalů od přerušení timerem je snad hardwarově závislé a tudíž neměnné, korekce by řešila jen čas pro sw obsluhu a tudíž fázovou chybu, což při měření času obyčejně nevadí. Jiný než nulový čas při vyhodnocení (měření) času má každá metoda. Pro korekci korekce, saláme, nevidím důvod. A co se týká korigování korekcí českým parlamentem: ačkoliv nemám důvod považovat český parlament za něco odlišného od bandy zhovadilců, vyžírků a blbů, připadá mi míň obtížný a nebezpečný než europarlament s jeho korekcemi korekcí. Ten český je přímočaře blbější a mafiánsky buranštější, ten evropský je fanatičtější a horší, protože má pro svoje korekce a páchání domnělého dobra víc prostředků.

Problém je v preddeličke a ten sa nedá nijako eliminovať úpravou čítača TMR0. Preddelička sa toťiž vynuluje zápisom do TMR0 a stratí sa nejaký zlomok n/256 hodín. Iba nejakým záhadným spôsobom sa zosynchronizovať na preddeličku, 2 inštrukčné cykly je TMR0 na ten čas mŕtvy, pred vygenerovaním hodín do TMR0 urobiť zápis novej aj upravenej konštanty, aby to n bolo násobkom 256.
Preto je potrebné nechať TMR0 bežať dookola (256krokov) čo si vyžaduje použiť oscilátor s vhodnou frekvenciou či už systémový, alebo druhý externý kvôli celočíselnému napočítaniu prerušení do jednej sekundy.
edit:
Po slušnej analýze by sa dalo dopracovať k presnejším časom s ľubovolným oscilátorom . Z nevýhody sa stane výhoda...iba to treba exaktne hodiť do excelu.

Tak sem na to koukal v simulátoru a ten můj prvotní výpočet počítal s tím, že TMR0 po přetečení ihned počítá dál, jenže on po dobu přerušení stojí Takže tam mi vznikala ta chyba. Nicméně pro mojí potřebu to plně dostačuje. Tj úlohy jako drž tlačítko po dobu 3 vteřin a tak.

Prečo by mal stáť? Po prerušení sa nemení po dobu 64 inštrukčných cyklov. Keby obsluha prerušenia trvala dlhšie ako je nastavený prescaler TMR0 sa zväčší.

Jak píše Roman zde: http://www.romanblack.com/one_sec.htm

Basic procedure to generate a 1 second period;
(assuming a 4MHz crystal, and 1000000 timer0 ticks/second)
Every timer0 overflow; subtract 256 from our Period variable
When Period variable gets less than zero; generate the 1 second event and ADD another 1000000 to it
Because we ADD the next 1000000 ticks to the next second, the cumulated error is still contained within the Period variable. This means that the NEXT second will be adjusted by the error that was left in the variable. Every period will self-adjust it's length so over time there is Zero Cumulative Error.

Máme tříbajtovou proměnnou Period. TMR0 každých 256us udělá přerušení, a my odečteme z proměnné konstantu 256, jakmile proměnná podleze pod 0, přičteme k proměnné konstantu 1000000. ... takže výsledkem je Zero Cumulative Error

Aké Zero? Zostatok nebude nulový. A 4 tisíc prerušení za sekundu zožerie s tou aritmetikou možno aj cez 50% výkonu.

Protože číslo 1000000 není dělitelné 256 beze zbytku, první periodu nám zbyde jakýsi "zbytek" (zostatok). Trik je v tom, že se o tento zbytek zase "odečte" další perioda, tj. chyba se dále nesčítá. Tak to chápu já. Holt nejlepší bude to vyzkoušet a nechat to tikat, třeba týden.

Je to tak, je to jako u DDSky, tam po přetečení taky může zůstat v akumulátoru fáze zbytek, ale ten se projeví jen jako jitter.

Takže, jestli sem to celé pochopil. Problém v mém řešení byl ten, že při zápisu do tmr0 se zároven vynulovala předdělička a tím mi vznikala drobná chyba, která se postupně načítala.
Abych se dotal jakž tak výsledu, musí tmr0 přetékat bez zásahu.
Počítám, že stejná situace platí pro TMR1

TMR2 má možnosť hw-resetovať po načítaní do hodnoty PR2reg. Pritom sa rescaller nanuluje.

Voľne bežiaci TMR1 sa dá použiť v kombinácii s CCPxreg. v režime Capture. Do CCPxR sa vloží nasledujúci čas prerušenia.

Všeobecne platí: zápis do TMRxreg resetuje precaler. Tomu sa treba vyhnúť pri generovaní prerušení pre presnú časovú základňu.

Já jsem pro výpočet používat aplikace třetích stran, např. tady:
http://eng-serve.com/pic/pic_timer.html
nebo tady:
http://pictimer.picbingo.com/ (ale sehnal jsem na webu verzi 0.9.7)

PF