sei() - und das Programm läuft nicht

[Flo (Gast)]

Hi,

wie kann es sein, dass mein Programm nach dem sei() Befehl nicht mehr 
rund läuft. Es wird nur noch die setup() funktion ausgeführt und das 
immer und immer wieder. Die Main while schleife wird nie erreicht. 
Simuliert in AVR-Studio. Ohne sei() funktionierts. Hab ich irgendwo 
ausversehen nen watchdog angeschalten und blicks nicht, oder???

int main(void){

setup();

while(1){
......
}
return 1;
}
*
*
void setup(void){
  DDRD = (1<<LEDPIN);
  DDRB = 0b00001111; // PB0-1-2-3 ausgang
  
  Armed = false;

  //timer0 (8bit) - run 62,5khz
  //used to get SumSig
  
  TCCR0 = (1 << CS02);  //Normal mode - prescalser clk/256
            //Overflow nach 4,096ms
  TIMSK |= (1<<TOIE0);      //overflow int en
  TCNT0 = 0;
  GICR = (1<<INT0);                       
  MCUCR = ((1<<ISC01)|(1<<ISC00));  //rising edge

  uart_init();
  i2c_init();

        sei();
  _delay_ms(2000);
  
}//setup

grüße Flo

[Simon B. (nomis)]

Flo schrieb:
> wie kann es sein, dass mein Programm nach dem sei() Befehl nicht mehr
> rund läuft.

Du hast keinen Interrupt-Handler definiert.

Viele Grüße,
        Simon

[Michel (Gast)]

Und wie sieht die ISR aus?

[jonas biensack (Gast)]

genau, du schaltest den interrupt frei und hast keine ISR - Ergebnis: 
reset from controller.

[Flo (Gast)]

DIe ISR stehen über der Setup funktion.

volatile unsigned char cSumSig[5];
volatile uint8_t channel=0,valid=0;


ISR(TIMER0_OVF_vect){
  channel = 0;
  valid=0;
}
ISR(INT0_vect){
  if(valid == 1){
    cSumSig[channel] = TCNT0;
    armed = cSumSig[channel];
    channel++;
    }
  else{
    valid=1;
    }
  TCNT0 = 0;
}

[jonas biensack (Gast)]

mach mal return aus main raus, sollte zwar nichts verändern aber das ist 
unschön, den da gehen wir nicht raus...

[Flo (Gast)]

return ist weg.

Nach der sei() hab ich auch noch 2 Zuweisungen stehen. Auch die werden 
direkt übersprungen.

von sei(); gehts direkt zu setup();

[Johann (Gast)]

Junge, Junge. Du präsentierst hier kleckerlweise Dein Programm und 
erwartest tatsächlich, daß Dir jemand mit diesen Bruchstücken helfen 
kann?

[Flo (Gast)]

Ich dachte nicht dass der Rest des Codes was daran ändert wenn er eh 
auskommentiert war.
Aber vielleicht hilfts. Ich weiss nicht mehr weiter.

[Michael A. (Gast)]

Warum hast du zwei Header für Interrupts mit eingebunden?
#include <avr\interrupt.h>
#include <avr/signal.h>

Durch den Compiler geht der Code immer noch nicht wegen fehlender 
Definition von GyroCalibrated, Armed und uart_init.h

[Michael A. (Gast)]

Bei Freigabe mit  sei() steht schon der TIMER0_OVF Irq an. Das Programm 
hängt dan in der Timer0 Overflow ISR.

[Matt (Gast)]

Es muss #include <avr/interrupt.h> statt #include <avr\interrupt.h> 
heißen.
Durch das falsche Include erzeugt ISR(...) keine ISR und beim ersten 
Interrupt, der Auftritt springt Dein COntroller ins Leere bzw. landet 
wieder am Programmanfang.

[Michael A. (Gast)]

Matt schrieb:
> Es muss #include <avr/interrupt.h> statt #include <avr\interrupt.h>
> heißen.
Das ist ziemlich egal, sonst würde der Compiler heftig meckern 
(kommentier den Aufruf mal ganz raus).

[Ralf (Gast)]

In der Timer-ISR kann man, glaube ich nicht hängenbleiben. Und wenn der 
Compiler eine Datei nicht findet, meckert er schon rum.

Aber, wie ist die Variante?:
Deine 2s-Wartefunktion ist ja aus einer Bibliothek. Also nicht im 
Quelltext enthalten. Bei der Ausführung von delay versucht der 
Simulaotor die Funktion zu finden. Geht nicht, also nimmt er irgendeine 
(ich glaube, die am weitesten hinten im Speicher liegt), und die zeigt 
er dann an. Warte mal ~500 "Sprünge zu Setup" ;-) , dann ist die 
Warteschleife abgearbeitet, die ständig durch die Timer-ISR unterbrochen 
wird.

P.S.:
Michael A. schrieb:
> Das ist ziemlich egal, sonst würde der Compiler heftig meckern

...war wieder mal zu langsam

[Simon B. (nomis)]

Flo schrieb:
> DIe ISR stehen über der Setup funktion.
>
>

> volatile unsigned char cSumSig[5];
> volatile uint8_t channel=0,valid=0;
> 
> 
> ISR(TIMER0_OVF_vect){
>   channel = 0;
>   valid=0;
> }
> ISR(INT0_vect){
>   if(valid == 1){
>     cSumSig[channel] = TCNT0;
>     armed = cSumSig[channel];
>     channel++;
>     }
>   else{
>     valid=1;
>     }
>   TCNT0 = 0;
> }
>

Kann es sein, dass bei dem sei() direkt ein- bis mehrere INT0 anstehen? 
Darin wird dann munter "channel" inkrementiert, und das - soweit ich 
sehe - auch über 5 hinaus, d.h. wir haben u.U. eine Speicherkorruption.

Viele Grüße,
        Simon

[MitLeser (Gast)]

vielleicht lässt auch das 2sec-Delay den Watchdog ansprechen.
Wird zwar nicht vom setup() initialisiert, aber was ist wenn die
"Watchdog Always On"-Fuse gesetzt ist?

[Michael A. (Gast)]

Ralf schrieb:
> ... Warte mal ~500 "Sprünge zu Setup" ;-) , dann ist die
> Warteschleife abgearbeitet, die ständig durch die Timer-ISR unterbrochen
> wird.

Gutes Argument. Da hatte ich auch zu wenig Gedult mit dem Simulator...
Wenn man das 2s-Delay verkürzt sieht alles gut aus.

[Flo (Gast)]

Danke für die Resonanz, aber:
alle vorschläge durchgemacht. Leider kein Erfolg. Jetzt hab ich ein 
neues Projekt erstellt, in dem ich meiner Meinung nach das gleiche 
Interrupthandling implementiert hab. Und hier funktionierts.

Es wird die while Schleife ausgeführt bis eben einer der gewollten 
Interrupts auftritt.

Wieder zurück ins alte Programm..... gleiches Lied. Kommt am setup(); 
Aufruf nicht vorbei. Seh ich den Wald vor Bäumen nicht, oder??

Testversion:

//Atmega32 16MHz
#include <avr\io.h>
#include <avr\interrupt.h>
#include <stdlib.h>
#include <inttypes.h>
#include <stdint.h>

volatile unsigned char cSumSig[5];
volatile uint8_t channel=0,valid=0;


ISR(TIMER0_OVF_vect){
  channel = 0;
  valid=0;
}

ISR(INT0_vect){
  if(valid == 1){
    cSumSig[channel] = TCNT0;
    
    channel++;
    }
  else{
    valid=1;
    }
  TCNT0 = 0;
}

void setRX(void){
  
  TCCR0 = (1 << CS02);  //Normal mode - pre clk/256 -->62,5khz
                        //Overflow nach 4,096ms
  TIMSK |= (1<<TOIE0);        //overflow int
  TCNT0 = 0;
  GICR = (1<<INT0);    //GIMSK
  MCUCR = ((1<<ISC01)|(1<<ISC00));  //rising edge
  sei();
}

void main(void){
  
  DDRD |= (1<<PD0);
  setRX();

  while(1){
    PORTD = PIND ^(1<<PD0);
    
  }
}

[Ralf (Gast)]

Flo schrieb:
> Jetzt hab ich ein
> neues Projekt erstellt, in dem ich meiner Meinung nach das gleiche
> Interrupthandling implementiert hab.

Das ist der Unterschied:
Ralf schrieb:
> Warte mal ~500 "Sprünge zu Setup" ;-) , dann ist die
> Warteschleife abgearbeitet, die ständig durch die Timer-ISR unterbrochen
> wird.

Möglicherweise gravierend.
Und: Hat zwar nichts mit der Funktionalität zu tuen. Lass der 
Init-Funktion die Freude, sich schnell beenden zu können und mach das 
sei() in die main().

[Stefan E. (sternst)]

Du bist uns immer noch den Code von uart_init() schuldig. Nicht 
unwahrscheinlich, dass dort der Fehler ist.

[Matthias (Gast)]

Flo schrieb:
> Testversion:

Diese Version auf einen mega8 @3.6864 MHz gespielt mit PD2 als Ausgabe, 
schaltet alle 18.4 µs den Pin kurz auf low.

so well...

[Flo (Gast)]

Dann werd ich die uarts mal nachreichen. Glaub aber nicht, dass da ein 
Fehler drin ist. Hab ja nicht ich programmiert :)

Die sei() in die main oder wie in der Testversion in ne eigene RXinit 
rein werd ich heut Abend mal versuchen. Die 2 s Delay kann ich mir dann 
schenken!?
KLappt ja auch ohne warten...

[Stefan E. (sternst)]

Flo schrieb:
> Dann werd ich die uarts mal nachreichen. Glaub aber nicht, dass da ein
> Fehler drin ist. Hab ja nicht ich programmiert :)

Ist es aber. Diese Zeile ist die Quelle deines Problems:

  UCSRB =~(1<<RXEN); // RX enable

Hier werden sämtliche UART-Interrupts erlaubt, und der UDRE-Interrupt 
löst dann sofort nach dem sei() aus. Und da es keine entsprechende ISR 
gibt, gibt es einen Software-Reset und dein Programm beginnt von vorn.

[Flo (Gast)]

Das ists !!
MERKE: das nächste mal alles Posten. SORRY.

Aber ich dachte mit

UCSRB =~(1<<RXEN);

 wird nur der Empfänger Eingeschalten. Und nur mit setzen des RXCIE bzw. 
TXCIE werden die Interrupts angeschalten!?

Wenn ein Zeichen zu senden ist, wird ja hier

while(!(UCSRA & (1<<UDRE)))

gewartet bis der EMpfänger bereit ist. Das ist die Polling Methode,oder? 
Warum läuft während der Zeit der Timer1 weiter, aber der Timer0 nicht?

Ich dachte bisher, da der Timer0 OVF die höhere Priorität hat, dass die 
ISR auf jeden Fall ausgelöst wird während auf UDRE gewartet wird.

Muss ich statt

 while(!(UCSRA & (1<<UDRE)))

 - das Senden mit einer ISR handeln? Welchen Vektor muss ich da 
abfangen? USART _RXC | _UDRE | _TXC

grüeß FLo

[Flo (Gast)]

Ach misst, des  =~ ist ja die Bitweise Invertierung.

Kopf --> Tisch

[Stefan E. (sternst)]

Flo schrieb:
> Aber ich dachte mit

UCSRB =~(1<<RXEN);

> wird nur der Empfänger Eingeschalten.

Nein, diese Zeile setzt alle Bits in UCSRB auf 1 außer RXEN (und ist 
damit völlig sinnlos).

> Und nur mit setzen des RXCIE bzw.
> TXCIE werden die Interrupts angeschalten!?

Richtig, und genau das passiert in der Zeile.

> Das ist die Polling Methode,oder?

Ja.

> Warum läuft während der Zeit der Timer1 weiter, aber der Timer0 nicht?

Beide Timer laufen weiter.

> Ich dachte bisher, da der Timer0 OVF die höhere Priorität hat, dass die
> ISR auf jeden Fall ausgelöst wird während auf UDRE gewartet wird.

Die ISR löst auch während des Wartens aus (was aber nichts mit 
Proritäten zu tun hat). Oder versuchst du innerhalb einer anderen ISR zu 
senden?

[Flo (Gast)]

Nein, das hab ich durcheinander gebracht. Prios sind ja nur bei 
paralellem auftreten der INT's wichtig.

Ich hoffe ja, dass es nur das aktivieren der UART interrupts war was 
mich die letzten 2 Tage geärgert hat.

Thx für die Unterstützung.

FLo