Har suttit ett antal timmer med ett litet projekt som ska bli en egen variant av personsökare är det tänkt.
Har äntligen fått ihop en väl fungerande FFSK-demodulator m.h.a. en komparator + Mega88.
Har dock fått både grått och vitt och snart transparent hår innan allt slutligen funkade.
Har nämligen stött på en hel del skumma fenomen vad gäller främst Timer1 Overflow Interrupt, men även EXT1 Interrupt.
Timer1 har jag konstaterat en fantastisk förmåga att lösa ut så fort man försöker pilla på register tillhörande densamma, eller nollställa den (TCNT1).
Den slutliga lösningen fick bli en check så att TCNT1 verkligen är 0x0000, annars hoppar den bara ur interruptet (kör i 8MHz och clk/64 prescaler, så den hinner som tur är inte slå om).
Jag mäter nollgenomgångarna genom att läsa av TCNT1 och omgående nollställa TCNT1 för mätning nästa nollgenomgång.
Har någon hört talas om att det ska vara några problem med detta?
Googlade lite, och leta lite på avrfreaks, och jag hittade en person med samma fenomen på en Mega16 (har jag för mig).
Men ingen kunde säga om det var ett fel, utan alla föreslog bara att gå runt det (genom att spara föregående värde och dra av det från nästa värde, vilket funkar bra tills timern slår över. En massa onödig kod).
Har någon använt timern till något liknande och inte fått fenomen?
Jag har även nått skumt med EXT1 Interrupt som verkar aktiveras antingen genom "cli();" eller lite styrning på outputpinnar. Har tyvärr inte hunnit forska någe vidare djupt i det.
Men även här har jag fått lösa det genom att sätta en flagga då den inte får köra interruptet, och en IF-sats först i ISR:en som hoppar ut om flaggan är satt.
Rätt störande sätt att lösa det på, men enda vägen tydligen.
ATmega88 + Skumma interrupt
Hmmm, varför använder du inte input capture med timern? 
Modifierar du timerns räkneregister precis som de säger i databladet? Verkar som att du programmerar helt i C (?), då är det inte så mycket man kan misslyckas med på den punkten.
Jag har inte haft några besvär med att timern ger för många avbrott, men sedan är jag också väldigt försiktigt med att modifiera dess register medans den kör. Vad du kan göra, som jag vill minnas att de nämner någonstans i databladet, är att stanna timern när du ska ändra något. Då undviker man garanterat ofrivilliga överslag under skrivningen.
Modifierar du timerns räkneregister precis som de säger i databladet? Verkar som att du programmerar helt i C (?), då är det inte så mycket man kan misslyckas med på den punkten.
Jag har inte haft några besvär med att timern ger för många avbrott, men sedan är jag också väldigt försiktigt med att modifiera dess register medans den kör. Vad du kan göra, som jag vill minnas att de nämner någonstans i databladet, är att stanna timern när du ska ändra något. Då undviker man garanterat ofrivilliga överslag under skrivningen.
Vilka fördelar skulle input capture ge i denna applikation?
Hur menar du att dom säger i databladet? Det enda jag hittar är en varning om att en compare match kan missas, men min användning är inte så kritisk, jag vill bara ta tiden mellan två logikförändringar på INT1.
Nu skrev jag en separat modul för timer1 (tmr_start(), tmr_stop(), tmr_clear()) osv, och sedan gjorde jag som du sa, stannar klockan innan ändring å sånt, och banne mig, visst funkar det!
Provade dock bara som hastigast, men det verkar funka preliminärt.
Återkommer om jag stöter på andra fenomen.
Hur menar du att dom säger i databladet? Det enda jag hittar är en varning om att en compare match kan missas, men min användning är inte så kritisk, jag vill bara ta tiden mellan två logikförändringar på INT1.
Nu skrev jag en separat modul för timer1 (tmr_start(), tmr_stop(), tmr_clear()) osv, och sedan gjorde jag som du sa, stannar klockan innan ändring å sånt, och banne mig, visst funkar det!
Provade dock bara som hastigast, men det verkar funka preliminärt.
Återkommer om jag stöter på andra fenomen.
