AVR-Studio4, Mainschleife und die totale Verwirrung

[Mirco Blitz (Gast)]

Hi,

ich bin ziemlich neu im Thema Microcontroller, kenn mich aber mit c und 
anderen Sprachen ganz gut aus. Deshalb verirrt mich das Verhalten des 
AVR-Studio Simulators.

Meiner Meinung nach sollte das Programm (siehe anhang) ab while(1){} in 
einer Endlosschleife hängen, bis der Interrupt durch Timer1 erreicht 
Vergleichswert ausgelöst wird.

Wenn ich das Programm in Avr-Studio simuliere durchläuft er aber ständig 
die Main schleife und das while am ende scheint ihn nicht zu 
interessieren.

Funktioniert die logik auf nem micro irgendwie anders oder hat der 
Simularot nen schatten? (Wie soll man so den timer testen??)

Gruß
Mirco

[Mirco Blitz (Gast)]

Ignoriert die Setup funktion, das war nen test :-)

[Sven P. (Gast)]

Was soll denn da deiner Meinung nach passieren? Der rennt sich in der 
while-Schleife dumm und dämlich und dein ISR wird vermutlich garnich 
erst übersetzt, weil der eh leer ist.

[Mirco Blitz (Gast)]

Hat ich dcoh geschrieben, in der Endlosschleife hängen bleiben, bis der 
ISR auslöst, Der ist bei meiner version schon gefüllt, endlos viele if 
abfragen, deshabl hab ich das zum hochladen rausgeschmissen.

[Andreas K. (a-k)]

Mirco Blitz wrote:

> die Main schleife und das while am ende scheint ihn nicht zu
> interessieren.

Unverständliche Formulierung. Was ist diese "Main schleife" wenn nicht 
die while-Schleife?

[Rufus Τ. F. (rufus)]

Vermutlich sowas wie 'ne if-Schleife.

[Karl H. (kbuchegg)]

Mirco Blitz wrote:

> Wenn ich das Programm in Avr-Studio simuliere durchläuft er aber ständig
> die Main schleife und das while am ende scheint ihn nicht zu
> interessieren.

main() beginnt also wieder von vorne?

Wenn ja:

Das ist ein Hinweis darauf, dass du einen Interrupt freigegeben
hast, für den es keine ISR gibt.

Da du allerdings die entsprechenden Register mit Hexzahlen
beschreibst und ich zu faul bin da jetzt die einzelnen Bits
auseinander zu klamüsern um zu sehen, welche Interrupts du wirklich
freigibst, wirst du das wohl selbst übernehmen müssen.

[Andreas K. (a-k)]

Wenn du die Bits in den Steuerregistern in Hex-Notation definierst, 
statt deren Namen zu verwenden, muss jeder Leser zur Kontrolle erst 
umständlich die Bitpositionen einzeln mit dem Datasheet 
synchronisieren., um rauszukriegen was da passiert.

Die Aussichten, dass sich jemand das antut, sind eher gering.

[Andreas K. (a-k)]

Ach ja, eins ist auch so klar:
  TIMSK = 0x0C;
gibt 2 Interrupts frei, ich sehe aber nur eine ISR.

[Peter D. (peda)]

- M103-Fuse

- Interrupts enabled, aber keinen (oder nen falschen) Handler 
aufgesetzt.

Beides bewirkt Sprung in den Wald.


Peter

[Mirco Blitz (Gast)]

Offensichtilich habe ich Probleme mit den TimerRegistern, kann mir da 
mal jemand unter die Arme greifen, vielleicht raff ichs dann. Ich möchte 
das TIMER1 alle 625 CPU-zyklen auslöst und in die Unterfunktion springt.

(Mit dem 8-bit Timer und Overflow bekomm ichs hin, hier leider nicht)

Und ähm wie ausser als hex soll ichs denn notieren?

Gruß
Mirco

[Stefan E. (sternst)]

Andreas Kaiser wrote:
> Ach ja, eins ist auch so klar:
>   TIMSK = 0x0C;
> gibt 2 Interrupts frei, ich sehe aber nur eine ISR.

Und die hat auch noch den falschen Namen.
Zum Bit OCIE1B gehört wohl eher "TIMER1_COMPB_vect".

> Die Aussichten, dass sich jemand das antut, sind eher gering.

Naja, hatte das Datenblatt eh gerade offen. ;-)

[Andreas K. (a-k)]

Mirco Blitz wrote:

> Und ähm wie ausser als hex soll ichs denn notieren?

 TIMSK = 1<<WEISSNICHT1 | 1<<UNBEKANNT2;

Hat sich doch Atmel extra die Mühe gemacht, für alles Bits Namen zu 
erfinden und sie sogar in die Include-Files (via XMLs) zu schreiben.

[Mirco Blitz (Gast)]

> Zum Bit OCIE1B gehört wohl eher "TIMER1_COMPB_vect".


Danke, das wars. Raffen tu ich das zwar noch nicht, aber ok die 
Datenblätter sind auch noch nen ziehmlicher Bahnhof.

Merci
Mirco