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
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.
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
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
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
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.