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
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.
:-)
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
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
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
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 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.
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 ;)
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.
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 ;)
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)
