www.mikrocontroller.net

Forum: Compiler & IDEs Interrupt, was mach ich nur falsch :(


Autor: Chrstian Trohn (christian_trohn)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich bin neu hier und hoffe das ihr mir Helfen könnt, nachdem ich 
schon Tausende von Beiträgen gelesen hab, aber leider keinen Fehler in 
meinem Programm finde.

Ich möchte eigentlich nur mit meinem Timer0 bis zum Overflow zählen, um 
einen Interrupt auszulösen. Aber irgendwie hängt mein Programm in der 
Endlosschleife (die läuft auch, das seh ich an meiner blinkenden LED) 
aber löst nie einen Interrupt aus. Ich hab das gleiche Spiel auch schon 
im Compare Match versucht, mit dem gleichen Ergebnis. Im PWM mit 
direktem Pin ansteuern funktioniert es, deswegen bin ich arg verwirrt.

Wie gesagt, mein Programm ist schön kommentiert (denke ich doch) damit 
jeder gleich sieht was ich bezwecken will. Ich hoffe ihr könnt mir 
weiterhelfen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuchs mal mit

TIMSK |= (1<<TOIE0);

;-)

Autor: Chrstian Trohn (christian_trohn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahhh ja du hast Recht, der Fehler ist jetzt ein wenig Peinlich, 
allerdings funktionierts imemrnoch nicht :(
Gleiches Problem, Whileschleife läuft, kein Interrupt.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chrstian Trohn schrieb:
> Hi, ich bin neu hier und hoffe das ihr mir Helfen könnt, nachdem ich
> schon Tausende von Beiträgen gelesen hab, aber leider keinen Fehler in
> meinem Programm finde.
TIMSK |= (1<<TOIE2);

Für Timer0 besser TOIE0 verwenden :D

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt mehr als einen AVR. Welcher isses?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Chrstian Trohn (christian_trohn)

>allerdings funktionierts imemrnoch nicht :(
>Gleiches Problem, Whileschleife läuft, kein Interrupt.

Vielleicht ist dein LED an PD6 kaputt?

Autor: Chrstian Trohn (christian_trohn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATMEGA16

Ich verwende zum testen das Evaluationboard von Pollin, mein ATMEGA 
läuft erfolgreich auf 16mhz ext. crystal.

Die Befehle für den Timer hab ich hier aus nem Forenbeitrag "geklaut" 
und seit einigen Tagen andenen ich am Probieren bin bestimmt 10 mal mit 
dem Datenblatt abgeglichen.
@Falk Brunner, nein ich hab die Led die zum blinken in der Schleife 
hängt schon öfters mit der die dauerhaft Leuchten soll getauscht weil 
mir das auch schon in die Gedanken gekommen ist.
Auch hab ich schon einen komplett neuen ATMEGA16 genommen weil ich 
dachte das der vielleicht hin sein könnte, du siehst wie verzweifelt ich 
bin :O

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> (die blinkt auch schnell, also programm läuft mal endlos ab)

Da 10000 x 10000 bis zum Toggeln gezählt wird, dürfte die nicht schnell 
blinken, ganz im Gegenteil.

Das sieht mir eher so aus, also ob der MC laufend resettet.

Autor: Chrstian Trohn (christian_trohn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm da hast du vollkommen Recht wenn ich mir das jetzt mal Überleg. Ich 
hab die Werte einfach nur mal da Reingeschrieben das ich Seh ob das 
Programm überhaupt läuft. Ausgerechnet, bzw mir Gedanken darüber gemacht 
hab ich bis eben nicht. Aber warum sollte der MC dauernd Resetten ? 
Programme ohne Interrupt laufen einwandfrei.

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
>> (die blinkt auch schnell, also programm läuft mal endlos ab)
>
> Da 10000 x 10000 bis zum Toggeln gezählt wird, dürfte die nicht schnell
> blinken, ganz im Gegenteil.

Es wird ja gar nicht 10000 x 10000 mal gezählt, sondern 10000 + 10000 
mal.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Compiler korrekt auf Mega16 eingestellt?

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Ernst schrieb:
> Es wird ja gar nicht 10000 x 10000 mal gezählt, sondern 10000 + 10000
> mal.

Ja, auch gerad' gesehen, hatte' wohl eine sinnvolle Schachtelung 
vorausgesetzt. Schätze, die hätte dieses Konstrukt auch werden sollen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahhhh, neeee, die Scheifen fliegen raus un der MC rödelt immer auf PortD 
rum, sodass deine Änderung nie wirksam wird. Probiers mal so.
 
#include <avr/io.h>
#include <avr/interrupt.h>

#define F_CPU 16000000 //16mhz takt
#include <util/delay.h>
 
// globale Variablen
 
volatile uint8_t abc;
 
int main() {
   
// IO konfigurieren, sicherheitshalber einfach mal alles auf ausgang
 
  DDRA = 0xFF;
  DDRB = 0xFF;
  DDRC = 0xFF;
  DDRD = 0xFF;
// Leds an PORTD erstmal alle aus
  PORTD = 0x00;
 
// Timer2 konfigurieren
 
  TCCR0  = 0b00000101;            // Vorteiler 1024 -> 15,625 takte pro zähler+1 -> 8bit zähler = 256 -> 0,015384 sek nach programmstart müsste schon 
  // interrupt kommen, also led PORTD 6 müsste gleich mitleuchten wenn timer funktioniert.
  TIMSK |= (1<<TOIE0);            // Timer Overflow Interrupt freischalten 
 
// Interrupts freigeben
 
  sei();
 
// Endlose Hauptschleife
 
    while(1) {
        _delay_ms(1000);
        PORTD ^= (1<<PD5);// LED PORTD 5 an damit ich seh das überhaupt was geht (die blinkt auch schnell, also programm läuft mal endlos ab)
        if (abc == 1) { // Einfach nur irgendwas zum arbeiten der CPU, damit will ich wenn endlich interrupt läuft mal im mainprogramm die led blinken lassen
            abc = 0;
        }
    }
}
 
// Timer0 overflow Interrupt
 
ISR( TIMER0_OVF_vect ) {
    abc = 1;
    PORTD ^= (1 << PD6);      //Wenn interrupt, dann soll einfach nur ne scheiss LED an PORTD 6 Leuchten
}

Autor: Chrstian Trohn (christian_trohn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nen anderen ATMEGA Typ hab ich noch nie Benutzt, also sollte das kein 
Thema sein, ich Programmieren über AvrStudio, AVRISP MKII. Bei AVR 
Optionen ist Atmega16 eingestellt, Read Signature zeigt mir 0x1E 0x94 
0x03, Signature matches selected device, ISP Frequency ist zur zeit 125 
kHz (dachte vielleicht läuft da was schief und hab den zwischenzeitig 
mal auf 1mhz internal gestellt). Mit 1mhz internal rc läuft das Programm 
genauso, nur das die led langsamer Blinkt.

Autor: Chrstian Trohn (christian_trohn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Falk Brunner
Gleiches Problem, nur LED tog Langsamer.
Mit delay hatte ich das auch schon am Anfang versucht. Dachte das das 
vielleicht daran liegt, deswegen hab ich die 2 Zählschleifen 
reingeschrieben.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt in der Falk'schen Version übrigens einen kleinen Spass:
  PORTD ^= (1<<PD5);
ist nicht atomar. Daher kann es beim Blinken von PD6 zu vereinzelten 
Arrhythmien kommen. Hier unwichtig, nur sollte man ab und zu an sowas 
denken.

Autor: Chrstian Trohn (christian_trohn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den code von Falk Brunner hab ich sowohl mit PORTD ^= (1<<PD5); als auch 
mit PORTD |= (1<<PD5); versucht. Sie Leuchtet nie.

Hab ich vielleicht irgendwas an den Grundsätzlichen Einstellungen 
verkehrt gemacht und das Programm ist richtig?

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Chrstian Trohn schrieb:
> Hab ich vielleicht irgendwas an den Grundsätzlichen Einstellungen
> verkehrt gemacht und das Programm ist richtig?

Compiliert das Programm ohne Fehler ? Wurden die Projekteinstellungen 
mit Export Makefile auch in's Makefile geschrieben ?

Das Programm compiliert hier korrekt und simuliert auch richtig.
Flash doch mal anhängendes Hex.

Autor: Chrstian Trohn (christian_trohn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier nochmal allen Input den ich euch Geben kann:
ATMEGA16 16PU
Fuses:
HIGH 0xD9
LOW 0xEF
(
OCDEN = 0
JTAGEN = 0
SPIEN = 1 mit sonem kleinen roten Fragezeichen rechts unten ?
EESAVE = 0
BOOTSZ = Boot flash size = 1024 words start adress=$1C00
BOOTRST = 0
CKOPT = 0
BODLEVEL = Brown-out detection at VCC=2.7V
BODEN = 0
SUT_CKSEL = Ext. Crystal/Resonator High Freq.: Start-up time: 16k CK 
+4ms
)

Lockbits:
0xFF
(
LB = No memory lock features enable
BLB0 = No Lock on SPM and LPM in Application Section
BLB1 = No Lock on SPM and LPM in Boot Section


Compiliert wird ohne Fehler.

Compiliert das Programm ohne Fehler ? Wurden die Projekteinstellungen
mit Export Makefile auch in's Makefile geschrieben ?

Wie kann ich das nachvollziehen ??? Bis jetzt hatte ich noch keine 
Probleme mit irgendwelchen Programmen.

Dein hex lässt beide LED tog.
Also heisst das wohl das ich Grundsätzlich irgendwas Falsch mach mit AVR 
Studio ???????
Das wär Katastrophal ... ihr Wisst ja garnicht wieviel Zeit ich jetzt 
schon an dem Timer hock.

Autor: Chrstian Trohn (christian_trohn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NEEEEEEIN ICH HABS !!!!!!!!!!!!!!!
Unglaublich, bei mir war im Makefile ATMEGA128 ............
Ich dreh noch durch, etliche Tage vor dem Programm gesessen und gedacht 
das ich zu blöd bin nen Timer zu initialisieren. Und jetzt isses das 
Makefile ...


DANKE an alle die mir erstmal die Bestätigung gegeben haben das das 
Programm laufen müsste um jetzt auf son blöden Fehler zu stossen.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chrstian Trohn schrieb:
> Wie kann ich das nachvollziehen ??? Bis jetzt hatte ich noch keine
> Probleme mit irgendwelchen Programmen.

Naja, aber hier scheint's ja ein Problem zu geben, also alles überprüfen 
was Probleme bereiten könnte.

Unter Build gibt's die Funktion "Export Makefile", damit zur Sicherheit 
das Makefile im Codeverzeichnis neu schreiben.

Chrstian Trohn schrieb:
> Dein hex lässt beide LED tog.
> Also heisst das wohl das ich Grundsätzlich irgendwas Falsch mach mit AVR
> Studio

Ja, wobei die Led an PD5 möglicherweise mit der falschen Frequenz 
toggelt, hatte vergessen die richtige Frequenz in den Projektoptionen 
einzutragen, die Delay-Funktionen brauchen diese Info.

Siehe oben, einfach mal das Makefile neu schreiben, bzw. auch unter 
Project -> Configuration Options die Projekteinstellungen überprüfen.

Autor: Michael Buesch (mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die race condition beim Zugriff auf PORTD (auch wenn hier nicht viel 
passiert außer einer ab und zu falsch getoggelten LED) sollte vielleicht 
nicht unerwähnt bleiben. XOR ist nicht atomisch auf AVR.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Buesch schrieb:
> Die race condition beim Zugriff auf PORTD (auch wenn hier nicht viel
> passiert außer einer ab und zu falsch getoggelten LED) sollte vielleicht
> nicht unerwähnt bleiben. XOR ist nicht atomisch auf AVR.

War nicht unerwähnt:

A. K. schrieb:
> Es gibt in der Falk'schen Version übrigens einen kleinen Spass:
>   PORTD ^= (1<<PD5);
> ist nicht atomar.

Jedoch war das eigentliche Problem ein leicht anderes :D

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.