Hallo zusammen,
ich versuche seit 2 Wochen mein Programm ans Laufen zu bekommen, aber
irgendwas funktioniert nicht .. ich denke es liegt an den Interrupts, im
speziellen an "TIMER1_OVF_vect" in Kombi mit dem Aufrauf des TIMSK =
(1<<TOIE1) Registers.
Zumindest hängt sich alles auf, wenn ich das drin hab..Beim Debuggen
habe ich festgestellt, dass an der Stelle die Register OCIE1A & OCIE1B
geschaltet werden, warum weiß ich nicht, gewollt ist das zumindest
nicht, ich denke dass das vlt den Fehler verursacht ?!
Ich hoffe, dass mir jemand helfen kann, bin inzwischen ziemlich am
verzweifeln deswegen :(
Dazu sei noch gesagt, dass ich mir das Prog aus anderen Codes zusammen
gebastelt habe und ich nicht so viel Ahnung vom Programmieren hab, daher
ist der Code sicherlich nicht optimal. Bis auf das Auslesen des Timer1 -
Overflow-Register (TOIE1) funktioniert es einigermaßen..
Aber gut, einige relevante Infos fehlen ja noch:
Ziel ist es über den Input Capture Pin - ICP1 (Pin PD4 des Olimex Boards
AVR-MT-128) ein getriggertes Signal aufzunehmen und daraus die Frequenz
zu ermitteln. Anschließend soll daraus eine Drehzahl berechnet werden.
Über ein Menü solls dann aufgerufen werden etc.
Das Board verfügt über einen ATmega128 und LCD/Taster.
Im Anhang ist der Code.
Ich verwende das AVR Studio Version 5 und den AVR Dragon.
Nochmal die Problembeschreibung:
Wird das Register
TCCR1B = ((1<<ICES1)| (1<<CS10));
und
TIMSK = (1<<TICIE1)| (1<<TOIE1);
aufgerufen, dann hängt sich das Programm auf. Nach rumprobieren hat es
sich dann auf das Register
TIMSK = (1<<TOIE1);
eingegrenzt. Ob es letztlich nur daran liegt oder woran genau, das
konnte ich nicht herausfinden und hoffe daher, es weiß jemand ne Lösung.
Schonmal Danke!
ist eine gaaaanz schlechte Idee. Du musst Fehler schon beheben und nicht
kaschieren!
AUch wenn du C-Anfänger bist, solltest du wissen, dass in C
Gross-/Kleinschreibung wichtig ist
1
ISR(Timer1_CAPT_vect)//Interrupt für Timer/Counter1 Capture-Event
2
{
3
...
4
}// ISR1
5
6
7
// Interrupt für den Overflow
8
9
ISR(Timer1_OVF_vect)// Interrupt Vector
10
{
11
...
12
}
Du versuchst nicht zb den TIMER1_OVF_vect zu instantiieren, sondern du
versuchst dienen Timer1_OVF_vect zu instantiieren. Das ist ein
Unterschied! Der Name und seine Schreibweise sind dir vorgegeben! Die
kannst du nicht einfach nach Gutdünken verändern.
Compiler Warnungen zu ignorieren ist nie eine gute Idee!
Vielen Dank erstmal!
Das ist mir ja schon ein bisschen peinlich, ich gucke mir seit Tagen
alles genau durch und mir fällt die Schreibweise nicht auf.
Wobei ich mir die Compiler Warnungen schon angesehn habe, aber wohl
nicht genau genug.
.. und danke für die Rechtschreibkorrektur..das hätte mir auch auffallen
sollen..
Dann versuche ichs mal mit den Änderungen, vielleicht klappts ja dann
schon..und nochmals danke!
Richard P. schrieb:> Vielen Dank erstmal!>> Das ist mir ja schon ein bisschen peinlich, ich gucke mir seit Tagen> alles genau durch und mir fällt die Schreibweise nicht auf.>> Wobei ich mir die Compiler Warnungen schon angesehn habe, aber wohl> nicht genau genug.
Nur zur Info:
Es gibt harmlose Warnungen und es gibt Warnungen, die tatsächlich auf
schwerwiegende Probleme hinweisen können.
Da es mühsam ist, bei jedem Compilierdurchgang wieder erneut alle
Warnungen durchzugehen und den Spreu vom Weizen zu trennen, gelten im
professionellen Umfeld (und das sollten Amateure auch so sehen)
normalerweise die unmissverständlichen Direktiven:
* der Warning-Level des Compilers wird auf die höchste mögliche
Stufe gestellt oder zumindest auf die vorletzte dieser Stufen.
das bedeutet: Der Compiler mäkelt in Form einer Warnung an
allem rum, was auch nur irgendwie nach 'Problem' aussieht.
* Warnungen werden wie Fehler behandelt.
D.h. sie sind zu beheben. Der Code ist so zu gestalten, dass
das die Warnung auslösende Element verschwindet.
* Warnungen sind ausnahmslos zu beseitigen. Ein Code, egal wie groß
er ist, seien es 20 Zeilen oder 20 Millionen Zeilen, hat ohne
eine einzige Warnung zu compilieren.
* Die Warnung dadurch zu beseitigen, dass man den Warning-Level senkt
oder im Compiler einzelne Warnungen abschaltet, gilt NICHT!
(Da mag es Ausnahmen geben. Bei einzelnen Compiler Warnungen weiß
man, dass sie immer harmlos sind. Die können dann schon mal einzeln
abgeschaltet werden. Aber: Das sind Ausnahmen! Und die
Projektverantwortlichen entscheiden, ob und auf welche Warnung der
Fall zutrifft.)
Zusammengefasst:
Warnungen werden ernst genommen und sie werden beseitigt!
Immer?
Immer!
Danke für die Info, werds jetzt beherzigen.
Nach erneuter Compilierung - 0 Errors und 0 Warnungen - funktionierts
leider immernoch nicht. Aber zumindest hängt sich das Programm nicht
mehr auf.
Ich versuche mich jetzt nochmal mit dem Debuggen..
Tja.
Blöde Geschichte.
Da das ganze offenbar ein Drehzahlmesser werden soll: Du hast viel zu
viel Code auf einmal geschrieben!
Man macht das nicht, dass man seitenweise Code runterschreibt, in der
Hoffnung keinen logischen Fehler zu machen.
Ganz im Gegenteil: Du willst so schnell wie möglich in einen Zustand
kommen, in dem du die 'wichtige' Funktionalität deines Programmes testen
kannst. Dass dein Drehzahlmesser auch die Aussentemperatur anzeigen
kann, ist ein nettes Gimmick, aber für einen Drehzahlmesser erst mal
nicht notwendig. Das beim Einschalten erst mal 78 Zeilen mit Copyright
Meldungen kommen inklusive Danksagung an die Oma, ist zwar nett, aber
für einen Drehzahlmesser nicht notwendig. Eine Menü Auswahl ist zwar
nett, aber für eine erste Version nicht notwendig - für eine erste
Version reicht es völlig aus, wenn all das was man mit dem Menü
einstellen kann einfach mal als gegeben angenommen wird.
Für einen Drehzahlmesser notwendig ist die Messaufnahme, die Auswertung
(wobei es für eine erste Version nicht notwendig ist, zwischen 2 Blatt
und 3 Blatt Luftschrauben zu unterscheiden) und die Anzeige. Mehr
braucht man nicht, um mit einem Drehzahlmesser loszulegen.
Erst kommt das Display drann, damit man eine Ausgabefläche hat, um dort
Zwischenergebnisse und sonstiges anzuzeigen. Läuft die, dann kommt die
Messaufnahme. Sehen die Messwerte gut aus (die man sich dank
funktionierendem LCD ausgeben lassen kann), dann wird in die endgültige
Anzeige umgerechnet. Passt das dann, dann kommen die Zwischenergebnisse
wieder von der Anzeige weg.
Und erst dann, kommen all die anderen Gimmicks dazu.
Immer mit dem wichtigsten Bestandteil einer App anfangen! Und der erst
nun mal in den meisten Fällen die innere Maschinerie. Noch wichtiger ist
nur noch eine Ausgabemöglichkeit, um von Anfang an das 'Stochern im
Nebel' abzustellen.
Und zwischendurch testen, testen, testen! Was immer du testen kannst -
teste es!
