statische variable in ISR nicht wirklich statisch.

ich kann nicht den kompletten code posten, viel zu viel.

ich habe jetzt mal eine variable "vorher" vor v_test gesetzt.
im .map file liegt die aber ganz woanders als v_test ...

aber ich glaube eh nicht das da was aus den grenzen läuft.
es scheint eher so zu sein, dass alle variablen in diesem file neu 
initialisiert werden.
(vorher1 wird wieder 255 gesetzt, v_test, s_test auf 0)

was könnte der grund dafür sein?

1

#include <string.h>

2

#include <avr/io.h>

3

#include <avr/interrupt.h>

4

5

#include "rs232.h"

6

7

8

volatile int vorher0 = 255;

9

volatile int vorher1 = 255;

10

volatile uint8_t v_test = 0;

11

volatile int nachher = 255;

12

13

uint8_t put_frame() {

14

15

  // enable UDRE Interrupt 

16

  UCSR0B |= (1 << UDRIE0);

17

18

  return 0;

19

20

}

21

22

23

//----------------------------------------------------------------------------- 

24

// UART TX data register empty interrupt 

25

ISR(USART0_UDRE_vect) {

26

27

  static uint8_t s_test = 0;

28

29

  v_test++;

30

  s_test++;

31

32

  vorher1 = 100;

33

34

  UDR0 = 0x00;

35

36

}

insbesondere ist ja auch seltsam, dass das nicht passiert wenn ich die 
zeile UDR0=... auskommentiere...


ist da evtl was falsch gesetzt?

1

UBRR0H=(uint8_t)((F_CPU / (16 * BAUD_RATE)) - 1)>>8;

2

UBRR0L=(uint8_t)((F_CPU / (16 * BAUD_RATE)) - 1);

3

UCSR0B = (1<<RXCIE0) | (1<<RXEN0) | (1<<TXEN0);

4

5

OCR0A  = ((F_CPU / BSP_TICKS_PER_SEC / 1024) - 1);

6

7

//switch (HMI) timer

8

TCCR2B = (1<<CS22);            // divide by 64

9

TIMSK2 = 1<<TOIE2;            // enable timer interrupt

10

11

12

//framework tick timer

13

//set Timer0 in CTC mode, 1/1024 prescaler, start the timer ticking */

14

TCCR0A = ((1 << WGM01) | (0 << WGM00));

15

TCCR0B = (5 << CS00);

16

17

TIMSK0 = (1 << OCIE0A);

danke sehr! :)

es war die fehlende ISR für timer2.

wusste nicht, das sich das derart rächt. was passiert da wenn der INT 
ausgelöst wird und nicht gehandled wird. scheint ja nicht so gesund zu 
sein.


danke euch!
ich werde jetzt wohl mal ein bisschen was lesen zu interrupt handling 
und so.
empfehlungen?

>ich werde jetzt wohl mal ein bisschen was lesen zu interrupt handling
>und so.
>empfehlungen?

Das Datenbl

>> insbesondere ist ja auch seltsam, dass das nicht passiert wenn ich die
>> zeile UDR0=... auskommentiere...

>Und das wiederum deutet drauf hin, dass nur mit dieser Zeile ein
>Interrupt ausgelöst wird, ohne nicht. Und ein fehlender oder falsch
>implementierter Handler zum Neustart führt.


ja, das sollte man doch vermuten.
aber es hat auch irgendwas mit dem timer2 zu tun...

myteriös (jedenfalls für einen newbe wie mich)
...aber spassig.

att

>>ich werde jetzt wohl mal ein bisschen was lesen zu interrupt handling
>>und so.
>>empfehlungen?

>Das Datenbl


booo wirklich :(  gääähn

ich muss aber zu meiner verteidigung sagen, dass ich da schon einiges 
gelesen hab. eigentlich ganz gut, aber nicht sonderlich fesselnd... aber 
du hast wohl recht.

>att

w0t?

>> wusste nicht, das sich das derart rächt. was passiert da wenn der INT
>> ausgelöst wird und nicht gehandled wird.
>Wenn das ne Frage sein soll: Dann gibt's einen "Warmstart", sofern
>nichts anderes eingestellt ist.

ja, aber warum gibts den warmstart nur, wenn ich in dem UDR-handler 
UDR-setze? der warmstart kommt doch von dem nicht gehandleden 
timer2-overflow...!

>ja, aber warum gibts den warmstart nur, wenn ich in dem UDR-handler
>UDR-setze? der warmstart kommt doch von dem nicht gehandleden
>timer2-overflow...!

Die Timer2-Interrupt-Einsprungadresse liegt vor der des UDRE-Interrupts 
in der  Vektor-Tabelle. Vermutlich springt der Prozessor dorthin, findet 
aber keine Adresse und geht dann den Adressraum weiter hoch, bis er zum 
ersten sinnvollen Programmpunkt kommt, der dann die UDRE-ISR-Adresse 
ist.

aus Interesse habe ich mal eine Frage:
Läßt sich der Compiler oder besser Linker dazu bewegen, an die 
Einsprungadressen ohne ISR ein RETI zu setzen?

Danke für die Antworten.
Dann gehört die BADISR eigentlich in jedes Projekt und sollte eine 
definierte Fehlerausgabe erzeugen. Während der Entwicklung kann man dort 
auch einen Breakpoint setzen, der ja nicht erreicht werden sollte.

>Richtig. Ich vermute mal, dass in dem nicht gezeigten Teil des Programms
>noch eine Reihe weiterer Klöpse stecken, von denen mindestens einer zu
>dem beschriebenen Effekt führt.


hehe... immer drauf auf die kleinen newbes.
eigentlich läuft jetzt aber alles ganz super, nachdem ich den timer2 
rausgenommen habe.
(das hatte ich halt versehentlich mit reinkopiert aus einem anderen 
projekt)

ich kann den code aber gerne der wissenschaft zur verfügung stellen, 
würde mich ja auch mal interessieren was da genau passiert.
also wenn ihr wollt, schrumpfe ich den code soweit zusammen, dass er 
lesbar wird und den beschriebenen effekt zeigt.