Timerwert erfassen

[Mark Z. (lyams)]

Hallo,
Also was ich vorhabe ist eigentlich trivial, dennoch treibt es mich fast 
in den Wahnsinn.
Ich will eine Frequenz messen, genauer gesagt eine Periodendauer.
Ich lege eine Frequenz an meinen Mikrocontroller (ICP1)
dort sollte ja der Timer 1 mit einer Auflösung von 500ns (16MHz mit 
Prescaler 8) die Zeit zwischen 2 Flanken messen.

Die Ausgabe ist hier nicht zu beachten, habe ich kurzfristig verändert. 
weil mich das ergebnis verwundert hat. Hier sollte man ja eig 0 erwarten 
wenn am Eingang ne gleichbleibende Frequenz anliegt.
die Bedingung ist allerdings mal erfüllt und mal nich.

Ich weiß nicht warum ich einfach nicht das erwartete Ergebnis bekommen.
Was ist falsch?
Ich bitte um Hilfe, is sicher iwo ein grobes Verständnisproblem 
meinerseits.
Habe ich gestern schon versucht und die Tipps von einem Moderator 
umgesetzt, es hilft aber nix.

hier mein Code:

void Interrupt_init()
  {
    sei();          
    GICR |= (1<<INT1);
    GIFR = (INTF1);
    TIMSK |= (1<<TICIE1);  
    TCCR1A = 0x00;
    TCCR1B = (1<<ICNC1) | (1<<ICES1) | (1<<CS11) | (0<<CS10);
                              
  }
 
void Ausgabe()
{
   while(1)
   {
     PORTA=0x00;      //Startsignal - alle LED an            
     _delay_ms(1000);
       }
    if (u8_timerwert[1]-u8_timerwert[0]<90)
    {
      PORTA=0b00000101;
      _delay_ms(400);
    }
    else
    {
      PORTA=0b00000001;
      _delay_ms(400);
    }
     
   }
 }

volatile uint8_t flag;
volatile uint8_t i=0;
ISR(TIMER1_CAPT_vect)
 {    
                   
  if (i>0)            //ersten Wert verwerfen            
  {      
  u8_timerwert[i-1]=ICR1;    //Array mit Timerwerten beschreiben  
  }  
  i++;
  if (i==3)            //Abbruchbedingung              
  {  
      GICR &= ~(1<<INT1);    //ISR deaktivieren
      flag=1;          
  }
                
  
}
 
int main(void)
{
  DDRA=0xff;
  Interrupt_init();
  while(1)
  {
     if (flag==1)
     {
       Ausgabe();
     }
  }
}

[Stefan (Gast)]

Wenn Du zwischen dem lesen von zwei Timerwerten durch einen Interrupt 
unterbrochen wirst, erhälst Du zwei Werte, die nicht mehr zusammen 
passen.

Du musst beim Lesen Interrupts sperren:

cli();
uint8_t a=u8_timerwert[1];
uint8_t b=u8_timerwert[0];
sei();
if (a-b<90) ...

[Mark Z. (lyams)]

Ok, aber bei meiner derzeitig verwendeten Frequenz von 20,8kHz sollte 
das doch zeitunkritisch sein oder?
Ich habe dabei 48µs Zeit bis zum nächten Interrupt, und was ich während 
dessen mache sollte doch nicht so lang dauern.
Oder verstehe ich hier etwas falsch?

Danke trotzdem für den Rat, ich versuch natürlich das umzusetzen.
sperrt denn cli(); wirklich in jedem Fall den Interrupt?

[Uwe (de0508)]

Hallo Mark,

"CLI"
ja, das ist Grundlagenwissen.

Tipp schau dir auch mal alle Assemblerbefehle eines Atmel µC an.

http://www.atmel.com/images/doc0856.pdf‎

[ich (Gast)]

cli();

ist in Ordnung, aber

sei();

würde ich nicht machen. Wenn nämlich vor dem Aufruf die Interrupts schon 
gesperrt waren, werden sie hier mit sei(); auf jeden Fall freigegeben. 
Das heißt, daß nicht der vorherige Zustand wiederhergestellt wird.

Besser ist es so:

uint8_t sreg;
sreg = SREG;
cli();
...
...
SREG = sreg;

Dann wird nach dem Vorgang der vorherige Zustand wieder hergestellt.

[Stefan (Gast)]

> Ich habe dabei 48µs Zeit bis zum nächten Interrupt

Du sollst die Interrups im Hauptprogramm sperren. Da dieses keine 
Rücksicht auf die Zeitpunkte der Interrupts nimmt, kann ein Interrupt 
zwischen dem lesen der zwei Werte stören.

Die Interrupt-Routine ist schon Ok - jedefalls auf den ersten Blick.

[Uwe (Gast)]

>     GIFR = (INTF1);
Sieht komisch aus

>void Interrupt_init()
>  {
>    GICR |= (1<<INT1);
>    GIFR = (INTF1);
>    TIMSK |= (1<<TICIE1);
>    TCCR1A = 0x00;
>    TCCR1B = (1<<ICNC1) | (1<<ICES1) | (1<<CS11) | (0<<CS10);
>    sei();
>  }
"sei()" würde ich erst am Ende machen

>volatile uint8_t flag;
Könnte man zur Sicherheit noch initialisieren
volatile uint8_t flag=0;

[Mark Z. (lyams)]

Habs grad mal mit dem Oszi gemessen, also meine ISR läuft nur 1,6µs, das 
heißt ja ein neuer Interrupt kommt mir während der Zeit der Verarbeitung 
nicht dazwischen.
Aber mach ich vlt iwo beim setzen der Bits in den Registern was falsch?
Ich habe jetzt eine Frequenz von 20,8kHz anliegen und der Timer auf der 
Empfängerseite läuft mit 2MHz (16MHz mit Prescaler 8)
also sollte doch ein Timerwert von 96=T1/T2 zu erwarten sein oder 
zumindest 95-97.

[Mark Z. (lyams)]

Ich bekomm hier gleich ein Magengeschwür, also ehrlich.
cli(); stoppt den Interruptbetrieb nicht.
erst das bit INT0 im Register GICR 0 zu setzen stoppt meinen Interrupt.
Oooooooh man, das hat Nerven gekostet.
Hat vlt noch jemand ne plausible Erklärung dafür?
Einfach sowas wie, Input Capture Interrupt läuft unabhängig vom SREG und 
das mit Beleg im Datenblatt?
Das wär Balsam für meine Seele!

Wer es testen möchte, hier der Code:

void Ausgabe(void)
{  
    PORTA=0xff;
    _delay_ms(200);
    PORTA=0x00;
    _delay_ms(200);
}

volatile uint8_t flag;
volatile uint8_t i=0;

 ISR(TIMER1_CAPT_vect)
 {                
  if (i>0)              
  {      
    u8_timerwert[i-1]=ICR1;  
  }  
  i++;
  if (i==3)              
  {    
    GICR= (0<<INT1); //ohne das gehts nicht!!!
    cli();      
    flag=1;    
  }
  TCNT1L=0x00;              
}

[Thomas E. (thomase)]

Mark Ziegler schrieb:
> Ich bekomm hier gleich ein Magengeschwür, also ehrlich.
> cli(); stoppt den Interruptbetrieb nicht.
cli(); schaltet die Interrupts ab. Hundertprozentig.

Kauf dir Maloxxan.

http://www.google.de/imgres?q=maaloxan&sa=X&rls=com.microsoft:de:IE-SearchBox&rlz=1I7GGHP_deDE505&biw=1920&bih=931&tbm=isch&tbnid=mSLuVafywuETZM:&imgrefurl=http://www.eurapon.de/maaloxan-25-mval-suspension-01427373/&docid=Gv4bkS1RaaxEkM&imgurl=http://www.eurapon.de/apopixx/1000_white/01427373.jpg&w=1000&h=1000&ei=jKELUvqzOoWPOOmlgNAK&zoom=1&iact=rc&dur=156&page=1&tbnh=144&tbnw=144&start=0&ndsp=56&ved=1t:429,r:15,s:0,i:130&tx=82&ty=72

mfg.

[Dietrich L. (dietrichl)]

Mark Ziegler schrieb:
> cli(); stoppt den Interruptbetrieb nicht.

In einer ISR ist der Interrupt sowieso disabled, d.h. beim Anspringen 
der ISR wird "cli" quasi von der Hardware ausgeführt.

Das nochmalige "cli" innerhalb der ISR ändert also nichts. Aber beim 
Verlassen der ISR wir der Interrupt in jedem Fall wieder eingeschaltet - 
auch wenn Du das nicht ins Programm schreibst.

Gruß Dietrich

[Mark Z. (lyams)]

Vielen vielen Dank!
...damit ist es klar:)

[Sascha W. (sascha-w)]

@Mark Ziegler

was machst du überhaupt mit INT1? Der hat mit dem Inputcapture des 
Timers nichts zu tun!
Exsistiert dafür irgendwo eine ISR?

Sascha

[ich (Gast)]

> Aber beim Verlassen der ISR wir der Interrupt in jedem Fall wieder
> eingeschaltet - auch wenn Du das nicht ins Programm schreibst.

Falsch!
Beim Verlassen der ISR wird der Zustand wieder hergestellt, der 
herrschte, als die ISR betreten wurde. Das heißt, wenn er vorher schon 
ausgeschaltet war, ist er auch nach Verlassen der ISR ausgeschaltet.

[Sascha W. (sascha-w)]

ich schrieb:
>> Aber beim Verlassen der ISR wir der Interrupt in jedem Fall wieder
>> eingeschaltet - auch wenn Du das nicht ins Programm schreibst.
>
> Falsch!
> Beim Verlassen der ISR wird der Zustand wieder hergestellt, der
> herrschte, als die ISR betreten wurde. Das heißt, wenn er vorher schon
> ausgeschaltet war, ist er auch nach Verlassen der ISR ausgeschaltet.
auch Falsch

wenn er vorher schon ausgeschaltet war, wird die ISR auch nicht 
aufgerufen.

Sascha

[ich (Gast)]

Stimmt. ->Hand an die Stirn :-))

[Route_66 (Gast)]

Sascha Weber schrieb:
> wenn er vorher schon ausgeschaltet war, wird die ISR auch nicht
> aufgerufen.

Es sei denn, ein verirrter Prozessor kommt auf einem anderen Wege in die 
ISR - z.B. durch einen Stack-Fehler.

[Thomas E. (thomase)]

Route_66 schrieb:
> Sascha Weber schrieb:
>> wenn er vorher schon ausgeschaltet war, wird die ISR auch nicht
>> aufgerufen.
>
> Es sei denn, ein verirrter Prozessor kommt auf einem anderen Wege in die
> ISR - z.B. durch einen Stack-Fehler.
Und beim Verlassen werden die Interrupts global eingeschaltet.

Denn diesen Unsinn macht er nicht:

ich schrieb:
 > Falsch!
> Beim Verlassen der ISR wird der Zustand wieder hergestellt, der
> herrschte, als die ISR betreten wurde. Das heißt, wenn er vorher schon
> ausgeschaltet war, ist er auch nach Verlassen der ISR ausgeschaltet.

mfg.