attiny44 stürzt direkt nach dem ich sei(); ausführe ab

[Jan (Gast)]

Ich versuche ein einfaches Projekt vom attiny45 auf attiny44 zu 
portieren, doch leider ohne erfolg. Der attiny44 stürzt direkt nach dem 
ich sei(); ausführe ab. (wenn ich dem avr studio emulator beim debbugen 
glauben kann).

Mein Programm (habe es abgespeckt):

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

ISR(TIM0_OVF){
PORTB=0b00000111;
}

int main(void){
DDRB=0b00000111;
PORTB=0b00000000;
//PORTB=0b00000111;  Leuchtdioden  an
TIMSK0=(1<<TOIE0);
TCCR0B=((1<<CS00)|(1<<CS02));
sei();
while(1);
}

PORTB=0b00000111; schaltet drei Leuchtdioden an. Wenn diese Zeile in 
main nicht auskommentiert ist dann leuchten auch diese leds. Zum 
Interrupt kommt er aber nie, denn die leds bleiben immer aus wenn die 
Zeile PORTB=0b00000111; im main auskommentiert bleibt. Woran kann das 
denn liegen??

Interessanter weise habe ich folgende Warnung beim Kompilieren :

../attiny44test.c:6: warning: 'TIM0_OVF' appears to be a misspelled 
signal handler

danke für eure Hilfe im voraus. Gibt es vielleicht eine Besonderheit 
beim attiny44??

Gruss,
jan

[Floh (Gast)]

Jan schrieb:
> ../attiny44test.c:6: warning: 'TIM0_OVF' appears to be a misspelled
> signal handler

Der kennt den Interrupt nicht, also nachschaun, wie der wirklich heißt.
:-)

[Timmo H. (masterfx)]

Müsste es nicht: TIM0_OVF_vect heißen...

[asdf (Gast)]

Hallo,

ich hatte schon mal das Problem, dass der Debugger abstürzt wenn in 
einer Schleife keine weiteren Befehle stehen. Füge also z.B. zweimal 
nop(); in die while(1) Schleife ein. Vielleicht hilfts.
Grüße

[Karl H. (kbuchegg)]

asdf schrieb:
> Hallo,
>
> ich hatte schon mal das Problem, dass der Debugger abstürzt wenn in
> einer Schleife keine weiteren Befehle stehen. Füge also z.B. zweimal
> nop(); in die while(1) Schleife ein. Vielleicht hilfts.

Quatsch.
Der Compiler sagt ihm sogar, wo das Problem liegt.
Nur darf man eben Warnungen nicht in jedem Fall auf die leichte Schulter 
nehmen

[Jan (Gast)]

Der Vektor heißt TIM0_OVF_vect und nicht TIM0_OVF.

Der Compiler hat Recht, TIM0_OVF gibt es nicht. Schaut man in die 
include Datei dann findet man dort  TIM0_OVF_vect . Sobald  ich das zum 
TIM0_OVF_vect ergänzt habe verhält sich alles wie erwartet.

Weis nicht wie dieser Fehler reingekommen ist. Irgendwie war ich mir so 
sicher das diese Zeile richtig war, so sicher, das ich die 
Compilerwarnung nicht ernst genommen habe, bzw. nicht akzeptiert habe. 
Seltsam aber das Verhalten beim debbugen mit AVR studio. Das hat 
wahrscheinlich dazu geführt das ich die Warnung nicht ernst genommen 
habe.

Warnungen ignorieren darf man anscheinend nicht machen, der Compiler hat 
immer Recht! Oder fast immer??

Auf jeden Fall vielen Dank für Eure Hilfe.

Gruss,
Jan

[Karl H. (kbuchegg)]

Jan schrieb:

> Warnungen ignorieren darf man anscheinend nicht machen, der Compiler hat
> immer Recht! Oder fast immer??

Es gibt nur sehr wenige Warnungen, die man tatsächlich gefahrlos und 
ohne Ansehen der Situation einfach ignorieren kann. Aber selbst dann ist 
man besser beraten, den Code so zu ändern, dass die Warnung nicht mehr 
kommt.

Profis (also die Leute, die ihre Brötchen damit verdienen) arbeiten in 
der Regel so, dass ihr Code auf der höchsten oder zumindest der 
vorletzten Compiler-Warning Stufe (je nach Compiler) ohne jegliche 
Warnung compilieren muss! Ansonsten wird der Code wieder zum 
Programmierer zurückgegeben und wird nicht in das Produktionsenvironment 
übernommen. Hilfreich ist dabei ein Schalter, den praktisch alle 
Compiler haben: "Treat Warnings as Errors". Dann kann man keine Warnung 
übersehen, weil der Build Prozess fehl schlägt.

Betrachte Warnings als Hilfestellung des Compilers und nicht als 
notwendiges Übel und du hast weniger Ärger. Denn gerade in der 
Programmierung nimmt man jede Hilfe, die man kriegen kann dankbar in 
Anspruch.

[sonstwer (Gast)]

Gibts eigentlich irgendwo eine Liste mit all den "*_vect" Namen?

[Karl H. (kbuchegg)]

sonstwer schrieb:
> Gibts eigentlich irgendwo eine Liste mit all den "*_vect" Namen?

Der Regelfall ist:
Im Datenblatt das Kapitel mit den Interrupt Vektoren aufschlagen.
An jeden Namen noch ein _vect dran hängen ... du hast den Gcc-Namen 
dafür.

Man kann natürlich auch ins prozessorspezifische iom*.h hineinschauen. 
Dort müssen auch alle vorhanden sein. Denn irgendwie müssen ja auch 
diese Namen irgendwo definiert sein.

[sonstwer (Gast)]

Danke für die Beschreibung. Habs gerade in der iom*.h gefunden, aber 
wirklich komfortabel ist das nicht. Dann Nehm ich lieber deine 
"Datenblattname + '_vect'"-Faustregel ;)

[Karl H. (kbuchegg)]

sonstwer schrieb:
> Danke für die Beschreibung. Habs gerade in der iom*.h gefunden, aber
> wirklich komfortabel ist das nicht. Dann Nehm ich lieber deine
> "Datenblattname + '_vect'"-Faustregel ;)

Du wirst schnell merken, dass man die meisten Interrupts mit denen man 
ständig zu tun hat, in 0 Komma nix auswendig kann.

[sonstwer (Gast)]

Karl heinz Buchegger schrieb:
> Du wirst schnell merken, dass man die meisten Interrupts mit denen man
> ständig zu tun hat, in 0 Komma nix auswendig kann.

Stimmt schon, meine kenn ich auch auswendig, nur will ich auch wissen, 
wo ich schnell schauen kann wenn ich mal was 'exotisches' suche ;)

[Tom M. (tomm)]

sonstwer schrieb:
> Danke für die Beschreibung. Habs gerade in der iom*.h gefunden, aber
> wirklich komfortabel ist das nicht.

Ich schau meistens in der avr-libc Dokumentation nach zu 
<avr/interrupt.h>. Dort gibt's ne grosse Tabelle mit den 
Vektor-Bezeichnungen, Beschreibung dazu und ne Liste mit MC, welche 
diesen Vektor kennen.

http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

> Dann Nehm ich lieber deine
> "Datenblattname + '_vect'"-Faustregel ;)

Gute Eselsbrücke, darauf bin ich noch nicht gekommen. 8)