Zdravím,
A) Program v chipu ATMEGA8 funguje správně ale v AVR studiu při debugování jakmile nastane přerušení skočí na první krok v main funkci a nikoli do obsluhy přerušení.
B) Dělám čítač nízkých kmitočtů zároveň i jako průměrný kmitočet za delší dobu (30s až třeba 5minut). Jako časovou základnu mám hodinový krystal 32kHz na časovači 2. Měřený signál je přiveden na T1 nastavený jako čítač s vzestupnou hranou a na INT1 nastaven na vzestupnou hranu. Funkce probíhá takto: zvolí se počet měřených kmitů. S náběžnou hranou v INT1 se vynuluje čítání času a naplní se čítač TIMER1 tak aby při přetečení uběhl požadovaný počet kmitů. Když uběhne požadovaný počet kmitů nastane přerušení TIMER1 kde se odečte “jemný” čas z TCNT2 a půl vteřiny které se inkrementují v přerušení TIMER2. Z výsledných dat se vypočte kmitočet. Tento postup vyžaduje vypínaní přerušení a různé manipulace protože signál je tam stále a je blbost aby s každou hranou proběhlo přerušení INT1. (halda push a pop plus nějaká obsluha přerušení)
shledáváte tento způsob jako vhodný?
myslím si, že jelikož signál běží stále tak i když vypnu konkrétní přerušení např. INT1 nastaví se na něj flag. A když ho pak zapnu tak se asi nespustí s hranou ale díky flagu hned jak ho zapnu? To asi bude platit i o přetečení časovačů atd. Jak tedy znulovat příslušné příznaky? V datasheetu jsem našel zapisem log 1 na INTF1 ale nějak se mě to nezdá (zároveň píšou ze s událostí se nastaví na log 1 a nuluje se jakmile se skočí na příslušný vektor.) a jelikož debug nefunguje nemohu snadno vyzkoušet.
3)optimalizaci asi necháme na příště. Tahle sranda mě s lcd displejem zatím stála 5098bytes v atmega8 62%
Děkuji za rady.
Mas nastaveny spravny procesor pre DEBUG? Nejedna sa automaticky o procesor, pre ktory pises a prekladas aplikaciu. V polozke DEBUG si musis vybrat spravnu platformu. Pravdepodobne bude Tvoj problem sposobeny tym.
Ještě pořád to úplně nechápu (před chvílí jsem vstal a ještě neměl čaj ) ale jsem si celkem jist, že by ti měl stačit 1 timer.
Po zpracování předešlého měření si vynuluješ počítadlo impulzů a TCNT. Při vzniku INT1 spustíš timer. Při každém jeho přetečení si přičteš 1 do počítadla. Když přijde další INT, tak akorát zastavíš timer, vyzvedneš hodnotu z počítadla a TCNT a zpracuješ. Vynuluješ počítadlo, TCNT a to by mělo být vše.
Některé příznaky se opravdu nulují zápisem “1”. Myslím, že to je z důvodu tzv. “atomic” operací. Ale už si to nepamatuju, musel bych to zase někde najít.
Děkuji za rady. Debugging už funguje. Opravdu to bylo špatně nastaveným procesorem. Projekt jsem začínal s ATMEGA32 a poté jsem přešel k ATMEGA8 a změnil to jen pro kompilátor a v debug zůstal mega32.
piityy: určitě by to šlo s jedním timer/counter. Jelikož beru více impulzů někdy i 14025 a tudíž neměřím jednu periodu volil jsem to takto. Což by i tak šlo že bych counter udělal softwarově inkrementací v INT1. Ovšem při vyšších kmitočtech by procesor nedělal nic jiného než push pop. Varianta s HW counterem snese i vysoké kmitočty. Co se týče přesnosti - na timer2 mám ten šutr, ale kdyby byla nějaká lepší varianta uvítal bych volný timer2 pro USART nevím jestli to jde použít zároveň když tam mám ten šutr cca 32kHz resp a jestli se trefí do nějakého normálního baudrate. Ale na USART asi stejně nebude paměť.
Jesli jsem to dobře pochopil, tak měříš počet taktů na 32kHz oscilátoru v době mezi dvěma INT1. Pokud ti stačí 32kHz, tak v žádnym případě nemusíš mít strach, že by procesor nestíhal. 1x za přetečení čítače přičíst 1 vážně není problém.
Jesli je to jinak tak pardon, ale ten popis máš dost chaotickej Možná i zapojení by pomohlo k pochopení.
Piityy: zkusím to napsat jinak. NEMĚŘÍM čas mezi hranami (periodu) ale čas mezi NĚKOLIKA periodami. (někdy až 14 025period) V přičítání 1 v přerušení od časovače (těch 32kHz hodinový šutr) opravdu problém není. To je jasně definované a konstantní a navíc v celku dlouhá doba.
Jde o přičítání 1 v počtu impulzů (period) které se měří. Takhle to snese i vysoký kmitočet. Možná si to zbytečně komplikuji tou univerzálností co to všechno snese. (Stejně se s vysokými kmitočty moc nepočítá. A rozlišení času by mohlo být nedostačující.) Má to i tu výhodu že si předplním čítač a když přeteče tak vím že měření je u konce a proběhl požadovaný počet impulzů.
Spíš mi jde o přesnost. Třeba bych použil i interní časovač. Ale jde o to, že měření trvá většinou 2minuty. Otázka je jak je interní oscilátor přesný a teplotně stabilní. Myslím že s externím 32kHz z kterého se dělají hodiny by to mělo být v pohodě. S interním bych zase měl mnohem větší rozlišení a pohodlnější práci když by byl 16bit. Mohlo by se ale stát že bych sice měřil na mikrosekundy ale za pár minut by ujel o milisekundy. u RS232 komunikace to nevadí, jelikož se synchronizuje každým start bitem. A za následujících 9bitů to nestihne tak moc ujet.
Tahle sranda mě s lcd displejem zatím stála 5098bytes v atmega8 62%
Varianta s HW counterem snese i vysoké kmitočty. Co se týče přesnosti - na timer2 mám ten šutr, ale kdyby byla nějaká lepší varianta uvítal bych volný timer2 pro USART nevím jestli to jde použít zároveň když tam mám ten šutr cca 32kHz resp a jestli se trefí do nějakého normálního baudrate. Ale na USART asi stejně nebude paměť.
Možná i zapojení by pomohlo k pochopení.