Hallo, ich arbeite mich gerade erst in C und der
Microcontrollerprogrammierung ein und habe das Problem, dass der
Controller bei delay stehen bleibt und ich finde den Fehler einfach
nicht.
Ich arbeite mit AtmelStudio 6.2
#define F_CPU 8000000UL
#include <avr/io.h>
#include <util/delay.h>
int main()
{
DDRB = 255;
while(1)
{
PORTB = 0b00001111;
_delay_ms(200);
PORTB = 0b11110000;
_delay_ms(200);
}
}
Es könnte sein, dass deine Frequenz hier falsch eingestellt ist, da
standardmäßig ein Prescaler von 8 per Fusebit gesetzt ist. Das würde
aber nur die Dauer des delay verachtfachen. Ansonsten könnte ein Fehler
in der Schaltung dazu führen, dass dein Controller einen Reset bekommt
und daher den Teil nach dem Delay nie erreicht bevor er resettet.
Chris G. schrieb:> Danke, aber die Schaltung ist ok, denke es liegt wirklich an der> Optimierung, ich weiß nur leider noch nicht, wo ich die Abschalten> kann!?
Du sollst die Optimierung nicht abschalten, sondern ggf. einschalten.
Diese ist allerdings per default eingeschaltet. Ausserdem gibt es eine
Warnung von der delay.h wenn die Optimierung nicht eingeschaltet ist.
Wenn es keine Warnung gibt, kümmere dich also nicht darum.
Wie sind die Fuses eingestellt?
Und zeig deine Schaltung. Dass die OK ist, behauptet hier ausnahmslos
jeder, bei dem eine LED nicht wie gewünscht blinkt.
Welcher Programmer? Vielleicht mag der das nicht wenn die Ports an denen
er angeschlossen ist, auf Ausgang geschaltet werden. Dazu muss man aber
wissen, ob das ein vernünftiger oder irgendein Gurkentool ist.
mfg.
Ich habs außer mit der Schaltung auch mit dem AVR Simulator IDE versucht
un das Ergebnis ist gleich.
Wo könnte ich die Optimierung denn abschalten? (nur zum testen)
Chris G. schrieb:> (nur zum testen)
Was willst du damit testen? Die Optimierung MUSS eingeschaltet sein,
sonst funktioniert 'delay' nicht. Ist sie nicht eingeschaltet, bekommst
du eine Warnung. Kompiliert dein Programm ohne Warnungen? Und zwar beim
ersten Kompilieren, nachdem du etwas geändert hast. Nochmal kompilieren
und sich freuen, dass die Warnungen dann weg sind, zählt nicht!
Das mit abgeschalteter Optimierung zu testen, ist das Gleiche als wenn
bei deinem Fahrrad die Kette abgelaufen ist und du lässt hinten die Luft
aus dem Reifen, in der Hoffnung, dass es dann wieder fährt.
Die Optimierung wird hier zwar ständig als Schlagwort in den Raum
geworfen, ist aber äusserst selten der Grund für irgendwelche Fehler.
Kompilierst du für den richtigen Controller?
mfg.
Ok danke, verstanden.
Beim complimieren bekomme ich weder Fehler, noch Warnungen.
Ich habe den ATmega32 ausgewählt, von daher denke ich, dass der Compiler
entsprechend arbeitet...
Der Debugger/Simulator reagiert übrigens genauso wie der AVR Simulator
IDE und wenn ich den Breakpoint unter delay setzte, bekomme ich den
Hinweis, dass dieser Punkt nicht erreicht werden kann...
Chris G. schrieb:> dass der> Controller bei delay stehen bleibt und ich finde den Fehler einfach> nicht.
Vermutlich belibt der Controller nicht stehen sondern braucht
nur sehr lang. Das wäre bei internem RC-Oszillator der Fall....
Abzuchecken wäre:
- sind die Fuses für den externen Quarz oder Ozillator rchtig gesetzt
- ist der Oszillator aktiv (an den Quarz-Pins Sinal prüfen)
Fuses kannst Du auslesen mit dem Programmiergerät und meist
(Atmel-Studio, Eclipse AVR, etc.) hast Du auch gleich eine graphische
Oberfläche dabei die Dir die Fuse-bits in menschenlesbare Information
übersetzt. Ansonsten (wenn Du es zu Fuß machst mit Batch oder Makefile
dann google mal nach fuse calculator).
Apropos Fuse: Hast Du eventuell die Watchdog-Fuse gesetzt?
Was passiert wenn Du statt 200ms mal was kürzeres nimmst, z.B. 2ms?
(wirst ein Oszi brauchen um das zu sehen)
Chris G. schrieb:> Der Prozesortakt ist auf 8MHz eingestellt.
Es ist nicht entscheidend was du eingestellt hast sondern
mit welcher Frequenz der Prozessor läuft. Ja, das kann was ganz
unterschiedliches sein.
Bis jetzt habe ich noch nicht gehört ob er mit externem Takt,
internem Takt, mit Quarz oder mit keramischen Schwinger
betrieben wird. An den XTAL Pins musst du - um Sicher zu sein -
die gewünschte Frequenz nachweisen. Mit einem Oszilloskop.
>> Wo finde ich denn die Einstellungen der Fuses?
Die Aussage ganz oben und diese Frage zeigt doch dass du deine
Schaltung bzw. deinen Prozessor noch lange nicht im Griff hast.
Zuerst musst du mal das Datenblatt lesen und wissen was du
willst und was du machst.
Chris G. schrieb:> Der Prozesortakt ist auf 8MHz eingestellt.>> Wo finde ich denn die Einstellungen der Fuses?
Das widerspricht sich. Einerseits hast du deinen Controller auf 8MHz
eingestellt, andererseits weisst du nicht, wie man die Fuses einstellt
bzw. ausliest.
Der Takt wird mit den Fuses eingestellt. Der Eintrag von F_CPU dient
dazu, dem Compiler mitzuteilen, mit welchem Takt der Controller
tatsächlich läuft. Mit dieser Angabe wird z.B. das Delay
mikrosekundengenau berechnet.
Dein Controller läuft deswegen nach wie vor mit 1MHz.
mfg.
Also erstmal vielen Dank für die Hilfe. Durch ein Gespräch mit meinem
Prof. von der Uni, habe ich jetzt die Lösung:
Am We hatte ich kein reales Board zur Verfügung und habe deshalb mit dem
AVR Simulator IDE und mit der im AVR Studio enthaltenen Debugfunktion
gearbeitet. Das Problem liegt hier in der Delayfunktion, da diese sehr
kritisch programmiert ist (siehe Dokumentation) und die Simulatoren
damit so ihre Probleme haben. Heute habe ich ein reales Board (Easy AVR
V6) angeschlossen und schon lief das Ganze auf Anhieb...
Chris G. schrieb:> und mit der im AVR Studio enthaltenen Debugfunktion> gearbeitet.
Wäre natürlich hilfreich gewesen, du hättest darauf hingewiesen ...
Chris G. schrieb:> Das Problem liegt hier in der Delayfunktion, da diese sehr> kritisch programmiert ist (siehe Dokumentation) und die Simulatoren> damit so ihre Probleme haben.
Das ist allerdings Unsinn. Das ist ganz normaler Code, und der wird von
jedem Simulator problemlos ausgeführt. Du hast schlicht nicht lange
genug gewartet, der Simulator läuft halt nicht in Echtzeit. Nach ein
paar Stunden hätte das schon geblinkt...
Oliver
Chris G. schrieb:> Am We hatte ich kein reales Board zur Verfügung und habe deshalb mit dem> AVR Simulator IDE und mit der im AVR Studio enthaltenen Debugfunktion> gearbeitet.
Das nennen ich Verarschung eines Forums das du um Hilfe bittest.
Mit keinem Wort hast du eine Simulation erwähnt, selbst als man
darauf hingewiesen hat dass an der Hardware zu "drehen" wäre.
Chris G. schrieb:> Ich habs außer mit der Schaltung auch mit dem AVR Simulator IDE versucht> un das Ergebnis ist gleich.Chris G. schrieb:> Am We hatte ich kein reales Board zur Verfügung und habe deshalb mit dem> AVR Simulator IDE und mit der im AVR Studio enthaltenen Debugfunktion> gearbeitet.Eberhard F. schrieb:> Das nennen ich Verarschung eines Forums das du um Hilfe bittest.
So ist es...
Oliver
