Interrupt: Simulation OK - in Hardware gehts nicht

[ErdBaer (Gast)]

Ich hab jetzt mehrer Stunden Datenblätter und foren gewälzt; Hier also 
mein Problem:

Den Code im Anhang möchte ich auf einem ATMega 16 ausführen. Die 
Simulation Funktioniert wunderbar, beim interrupt Aufruf wird der 
Zustand des Ports geändert. Auf dem Controller nehmen die Pins dann 
jedoch nur den Zustand an den ich in main zugewiesen hab.
Der interrupt an sich funktioniert (z.B. wenn ich ne Verzögerung in den 
Int einbaue). Nur der Zustand der Portpins will sich nicht ändern.

Ich benutz das AVR Studio 4.12 SP3 und den GCC der mitgeliefert wurde. 
Programmieren geschieht dann mit TwinAVR mit dem ich das .hex file das 
das AVR Studio generiert per SPI in den Controller schreib.

Wie man am Code Wahrscheinlcih sieht mach ich grade meine ersten 
Gehversuche mit dem MµC.

[Johannes M. (johnny-m)]

> Den Code im Anhang...
Aha...

[Oliver (Gast)]

>Ich benutz das AVR Studio 4.12 SP3 und den GCC der mitgeliefert wurde
Nochmal aha...

[ErdBaer (Gast)]

Sorry Bedienfehler, hier also der betreffenden Code:

 
#include <avr/io.h>
#include <stdint.h>
#include <inttypes.h>
#include <stdbool.h>
#include <avr/interrupt.h> 

void init (void);

int main (void)
{
  init(); 
      
    PORTA=0x15;
    PORTC=0xff;

  while (1)
  {
  }

}

void init (void)
{
  DDRA = 0xff;  

  DDRC =0xff;
  PORTC =0xff;   
  sei(); 
  TIMSK |= 0x01;  // Timer 0 overflow interrupt enable
  TCCR0 &= 0xF8; //unteren bits von timercontrolregister löschen
  TCCR0 |= 0x05; //Prescaler 1024
  TCNT0 =  0x66;  // Reload wert
  
}


ISR (TIMER0_OVF_vect)
{
  PORTC = 0x00;
  TCNT0 =  0x66;  // Reload wert
}

Laut Simulator müsste Port C irgenwqann komplett 0 sein, ist er aber in 
der Realen Schaltung nicht.

[Roland P. (pram)]

ich tipp mal drauf dass die Fuse JTAGEN falsch gesetzt ist und sich 
PortC noch im jtag Modus befindet

[pumpkin (Gast)]

Was hat das mit einem nicht funktionierenden Interrupt zutun? Nichts! 
Roland hat liegt sicher richtig. Datenblatt ATmega16, Rev. 
2466E–AVR–10/02, Seite 58ff.

pumpkin

[ErdBaer (Gast)]

So

Scheinbar stimmt die Adresse unter der der Compiler meinen ISR Code 
ablegt nicht! Wenn ich der ISR

 ISR(__vector_default)

 gebe funktioniert es. Wo muss ich Nachschauen um die richtige Syntax 
für  die ISR () Funktion zu finden bzw. wie kann ich mir den 
Assemblercode anschauen um zu prüfen wo der Compiler meinen Isr Code im 
Speicher ablegt.

Da ich auch im fertigen Programm nur einen Interrupt benutzen werde geht 
es so, schön isses aber nicht.

[Jörg W. (dl8dtl) (Moderator)]

Du musst auch beim Linken -mmcu=atmega16 mit angeben, nicht nur beim
Compilieren.  Frag' ich mich aber, warum das dann in der Simulation
gehen soll...

[ErdBaer (Gast)]

Danke erstmal Jörg!

Wenns diemsmal mit dem Anhang klappt müsste sich die Meldung die ich 
beim erstellen der .hex datei bekomme darin befinden.

Mir ist noch etwas aufgefallen: Laut Datenblatt hat der Timer 0 Overflow 
den Vector 10 in der iom16.h wird allerdings folgendes ersetzt

 #define TIMER0_OVF_vect  _VECTOR(9)

Ausserdem ist mir nicht klar ob die Adressen der ISR's bei mir noch da 
liegen wo sie per Default liegen sollten.

[Jörg W. (dl8dtl) (Moderator)]

ErdBaer wrote:

> Wenns diemsmal mit dem Anhang klappt müsste sich die Meldung die ich
> beim erstellen der .hex datei bekomme darin befinden.

Sieht OK aus.

> Mir ist noch etwas aufgefallen: Laut Datenblatt hat der Timer 0 Overflow
> den Vector 10 in der iom16.h wird allerdings folgendes ersetzt
>

 #define TIMER0_OVF_vect  _VECTOR(9)

Ja, wir sind hier `off by one' mit dem Datenblatt.  Ist aber
nebensächlich.  Bei avr-libc heißt der erste Interruptvektor eben
__vector_1, das ist ja ein rein interner Name.  Davor liegt noch
der Resetvektor, aber der wird nicht über das __vector_N-Schema
angesprochen.