input capture atmega 644

[Andreas M. (alteleiterplatte)]

Hallo,

habe ein Problem beim input capture interrupt mit einem atmega644. Wenn 
ich folgenden code im Avr Studio 4 simulator debugge :



#include <avr/io.h>
#include <avr/interrupt.h>


ISR( TIMER1_CAPT_vect )
{
  unsigned char temp_00=0;
  temp_00 = ICR1;
}

int main(void)
{
  DDRD = 0x00;

  TCCR1A = 0;
  TCCR1B = (1<<ICES1)  | (1<<CS10);  // Input Capture Edge, kein 
Prescaler
  TCCR1C = 0;

  TIMSK1 = (1<<ICIE1) ;  // Interrupt akivieren, Capture

  sei();

  for(;;)
  {
  unsigned int i;
  i++;
  i = i + PORTB;
  }
}


schaffe ich es nicht durch toggeln von pind.6 in die ISR einzuspringen. 
Vektoriell stimmt die ISR und wenn ich im Simulator PIND.4 toggle wird 
die ISR aufgerufen obwohl der atmega644 den ICP-Pin auf PIND.6 hat.
Wenn wer eine Idee hat, bitte melden.

mfg

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

Welcher Simulator (für den ATmega644 müsste es ja auf jeden Fall
den V2 geben, der wäre zu bevorzugen)?  Hast du die Errata zum
Simulator gelesen?

Ich schiebe das mal, das hat mit'm GCC ja offenbar nichts wirklich
zu tun.

p.s.: bitte [ c ]-Markierungen benutzen.

[Andreas M. (alteleiterplatte)]

Danke für die schnelle Antwort,

Ich benutze die AVR Studio 4.14 build 589 und den V1 Simulator. Auf 
deinen Tipp hin habe ich nun den V2 Simulator verwendet, allerdings 
unterstützt dieser nur den atmega644p. Mit dem V2 funktioniert es nun 
mit Pind.6. Scheint ein bug im Simulator zu sein.?!

Jetzt muss ich nur noch herausfinden wo genau die technischen 
Unterschiede vom 644 und 644p liegen.

mfg

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

Andreas Mossauer wrote:

> Scheint ein bug im Simulator zu sein.?!

Gut möglich.  Meines Wissens (ich habe kein Windows und daher auch
kein AVR Studio) sind die Bugs des Simulators irgendwo dokumentiert.

> Jetzt muss ich nur noch herausfinden wo genau die technischen
> Unterschiede vom 644 und 644p liegen.

In dieser Richtung (also einen ATmega644P simulieren, aber einen
ATmega644 benutzen) sind sie belanglos.  Außer der Picopower-
Funktionalität (die man extra in Registern aktivieren muss) hat
die P-Version noch die zweite UART, die nicht-P-Version dagegen
nur eine.  Wenn man all das nicht benutzt, müsstens sie binär-
kompatibel sein.  Ansonsten gibt's mit AVR508 noch eine migration
note:

http://www.atmel.com/dyn/resources/prod_documents/doc8038.pdf

[Andreas M. (alteleiterplatte)]

Jörg Wunsch wrote:

>Gut möglich.  Meines Wissens (ich habe kein Windows und daher auch
>kein AVR Studio) sind die Bugs des Simulators irgendwo dokumentiert.

Mit welchem Simulator arbeitest du? (Gehe mal davon aus das du unter 
linux arbeitest).
Bin mittlerweile auch schon am überlegen auf ein anderes System 
umzusteigen, möchte einfach nur sinnvol AVR mcu´s in c programieren ohne 
mich über compiler oder debugger zu ärgern und stundenlang systemfehler 
zu suchen.

mfg

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

Andreas Mossauer wrote:

>>Gut möglich.  Meines Wissens (ich habe kein Windows und daher auch
>>kein AVR Studio) sind die Bugs des Simulators irgendwo dokumentiert.

> Mit welchem Simulator arbeitest du? (Gehe mal davon aus das du unter
> linux arbeitest).

Auf Arbeit arbeite ich unter Linux, zu Hause unter FreeBSD.

Simulator ist in der Tat die dünne Stelle der Opensource-Tools.
Ich nehme ganz selten mal simulavr, vor allem zum Simulieren von
Algorithmen.  Ansonsten vor allem live debuggen mit dem JTAG ICE.
Selbst das ist bei den meisten Anwendungen ja schon schwierig
genug (ein einzelner breakpoint kann einem das komplette Timing
über den Haufen werfen), ich kann mir gar nicht vorstellen, dass
man die passende Stimulierung selbst eines guten Simulators
schneller hin bekommen sollte als das Debuggen am lebenden Objekt.