Interrupt-Probleme beim ATmega8

[Marco (Gast)]

Hallo liebe Gemeinde,

ich heiße Marco und programmiere erst seit kurzem Microcontroller. Mein 
größtes Projekt war bisher die Steuerung eines Stoßstromgenerators für 
meine Diplomarbeit zu programmieren. Damals bin ich gänzlich ohne 
Interrupts ausgekommen.
Mein aktuelles Projekt mit dem ATmega8 soll mal zur Ansteuerung von 
Servos genutzt werden. Da ich mich aber mom erst "reinfuchse" wollte ich 
zunächst was kleines probieren. Ich habe im Inet geforscht auf der Seite 
http://members.shaw.ca/climber/avrinterrupts.html ein Prgrammierbeispiel 
gefunden. Hab dies mithilfe von AVR Studio 4.17 und meinem STK gleich 
ausprobieren wollen. (Hab es zusätzlich etwas hübscher gemacht und die 
Interruptbezeichung etc angepasst).
Nun das Problem: Da es in Real-life nicht funktioniert hat - habe ich es 
mir im Debugger etwas genauer angeschaut.. : Der Timer beginnt zu laufen 
und der Counter brav zu zählen. Bei der Zahl 5 (wird später durch ne 
höhere ersetzt ;) ) wird auch brav der OSF1A gesetzt, der das Matching 
zwischen TCNT1 und OCR1A markiert. Jedoch wird im TIMSK der OCIE1A nicht 
gesetzt, wodurch ich annehme, dass deshalb alles net so funktioniert wie 
es sein sollte ;)
Am PortD sollte eigentlich der PIN0 sich ein und ausschalten - was er 
nicht tut. Mein Vermutung -> das fehlende Flag im TIMSK wodurch meine 
ISR net aufgerufen wird - kann das sein?
Um die ganze Sache verständlich zu machen, habe ich euch 
Bildschirmbilder angehängt.

Vielen Dank schonmal für eure Hilfe!
MfG Marco

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Um die ganze Sache verständlich zu machen, habe ich euch
> Bildschirmbilder angehängt.
Quelltext hängst du besser als *.c Dateien an.

Das wird nicht das tun, was du willst:

 PortD = (0<<PD0);

Thema Bitmanipulation

BTW:
Hast du deine GIFs aus JPEGs gemacht?
Oder wie bekommt man die sonst so schön pixelig?

[Karl H. (kbuchegg)]

> Jedoch wird im TIMSK der OCIE1A nicht
> gesetzt, wodurch ich annehme, dass deshalb alles net so
> funktioniert wie es sein sollte ;)

Wenn dem tatsächlich so ist, dann durchsuche mal die Konfigurationen, ob 
auch wirklich überall der Mega8 eingetragen ist.

Mangels Quelltext (wie kommt man auf die Idee Quelltext als Bilder 
anzuhängen?) kann man das hier nicht ausprobieren.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

>> Das wird nicht das tun, was du willst:
Ich muß mich korrigieren: es wird tun, was du willst,
aber auf eine andere Art, als du beabsichtigst. Denn statt

PortD = (0<<PD0);

könntest du schreiben

PortD = 0;

[Marco (Gast)]

Lothar Miller schrieb:
> BTW:
> Hast du deine GIFs aus JPEGs gemacht?
> Oder wie bekommt man die sonst so schön pixelig?

LOL, jup so ziemlich genau das habe ich gemacht, weil ich erst die jpgs 
aufm Laptop gemacht habe - und sie hier aufgrund der Forenregeln aufm 
Desktop umgewandelt habe ;) Habe sie diesmal gleich als gifs erzeugt und 
erneut angehangen ;)

Also wäre demnach das richtig: :)
PortD |= (0<<PD0);

Karl heinz Buchegger schrieb:
> Wenn dem tatsächlich so ist, dann durchsuche mal die Konfigurationen, ob
> auch wirklich überall der Mega8 eingetragen ist.
>
> Mangels Quelltext (wie kommt man auf die Idee Quelltext als Bilder
> anzuhängen?) kann man das hier nicht ausprobieren.

Sorry, Quelltext habe ich nun angehangen! Ich nutze den ATmega8-16PU - 
finde aber meist nur den ATmega8A in den Configs.. macht das den 
kriegsentscheidenenden Unterschied?

Danke für die flotten Antworten!
MfG Marco

[ich (Gast)]

> Also wäre demnach das richtig: :)

PortD |= (0<<PD0);

Mit diesem Befehl veroderst du und wenn du x mit 0 veroderst, bekommst 
du x raus. Wenn du das Bit löschen willst, dann musst du mit einer 0 
verunden.
Also PORTD &= (0<<PD0) oder besser noch PORTD &= ~(1<<PD0)

[Johann L. (gjlayde)]

Karl heinz Buchegger schrieb:

> Mangels Quelltext (wie kommt man auf die Idee Quelltext als Bilder
> anzuhängen?) kann man das hier nicht ausprobieren.

Das nennt sich "grafische Proogrammierung" und ist Stand der Kunst 
heutzutage.

[Karl H. (kbuchegg)]

ich schrieb:
>> Also wäre demnach das richtig: :)
>

> PortD |= (0<<PD0);
>

>
> Mit diesem Befehl veroderst du und wenn du x mit 0 veroderst, bekommst
> du x raus. Wenn du das Bit löschen willst, dann musst du mit einer 0
> verunden.

Auch nicht.

Eine 0 kann man nach links schieben sooft man will, sie bleibt trotzdem 
eine 0.

Mit einer 0 kann man nicht gezielt ein Bit löschen.

> PORTD &= ~(1<<PD0)

so geht das.

(Irgendwie seltsam, dass jemand eine Diplomarbeit fertig stellt und 
nicht mal korrekt ein Bit setzen und löschen kann)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

ich schrieb:
>>> Also PORTD &= (0<<PD0)
Das ist wieder gleichbedeutend mit  PORTD &= 0;
Und das wieder mit                  PORTD = 0;

Aber die zweite Hälfte der Antwort war dann doch noch richtig:
>>> oder besser noch PORTD &= ~(1<<PD0)

[Karl H. (kbuchegg)]

Marco schrieb:

> Sorry, Quelltext habe ich nun angehangen! Ich nutze den ATmega8-16PU -
> finde aber meist nur den ATmega8A in den Configs.. macht das den
> kriegsentscheidenenden Unterschied?

OK
Ich kann das geschilderte Verhalten hier nicht nachvollziehen.

Was hab ich gemacht?
* AVR-Studio gestartet
* Neues Projekt angelegt
* Als Prozessor den Mega8 ausgewählt und den normalen Simulator
  (Der Simulator wird vom Wizard automatisch auf Mega8 eingestellt)
* Im Code Fenster, das AVR-Studio automatisch erzeugt, den Code
  direkt per Copy&Paste eingefügt
* Die Optimierungen in Project / Configuration Options abgeschaltet
* Compiliert
* Per Debug den Simulator gestartet
* mittels F10 ein paar Schritte gemacht und im TIMSK Register, welches
  beim Timer 1 angezeigt wird, beobachtet, wie der Haken dort auftaucht
* Danach im Simulator den Cursor auf die erste Zeile in der ISR gesetzt
* Mittels F9 einen Breakpoint an diese Position gesetzt
* Danach mit F5 dem Simulator die Erlaubnis gegeben, das Programm
  komplett weiterzusimulieren
* Der Simulator ist an den Breakpoint in der ISR gekommen und hat mir
  die 'Befehlsgewalt' in der ISR wieder zurückgegeben

Alles in allem:
Alles funktioniert so, wie es sollte. Keine Anomalien.

[Marco (Gast)]

Tausenddank!!! Der Fehler lag entweder in der Optimierung oder darin, 
dass ich den ATmega8A ausgewählt hatte - bei allen anderen Sachen (bsp 
LCD Ansteuerung) gab es da nie Probleme ;)
Nochmal Danke für die tolle Anleitung beim Debugger - hab den Controller 
programmiert und die LED blinkt ganz brav wie sie soll!

Jetzt kann es erhoben Hauptes an die Ansteuerung der Servos gehn!
MfG Marco