Debug přerušení v AVR studiu + tvorba čítače

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í)

1. shledáváte tento způsob jako vhodný?
2. 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.

Len k tomu odskoku na main pri preruseni.

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.

Ano, ty flagy se opravdu nulují tím, že do nich zapíšeš log. 1. Jednou jsem to tu také řešil.

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.