Hallo,
nachdem ich einige bekannte Probleme mit AVRDUDE und WinAVR auf Vista
nicht beheben musste weil sie nicht auftraten habe ich nun ein seltsames
Problem mit dem gcc:
egal was ich im MakeFile für F_CPU definiere oder was ich sonst so
mache, das Programm läuft viel zu schnell auf dem ATMEGA16; der selbe
Quelltext auf der selben Version von avr-gcc kompiliert (.hex-datei
beide male mit vista und ponyprog übertragen) läuft einmal im richtigen
Tempo (XP-gcc) und einmal in einem 1/schneckentempo also sehr viel zu
schnell.... (dumm-dumm-vista-schrott).
Kennt wer das Problem?
danke fürs durchlesen und nachdenken;
Hugo
hmm dachte ich zuerst auch; aber die Fuses werden doch nicht beim
proggen geändert; und beim aufspielem vom XP-code gings ja im normalen
tempo (außerdem sagt ponyprog dass sich die Fuses nicht geändert haben)
LG,
Hugo
>(dumm-dumm-vista-schrott).>Kennt wer das Problem?
Ja, es liegt an dir. Die Angabe zu FCPU im Makefile spielt für den
Controller keine Rolle. Die ist höchstens für die delay-Makros
interessant.
STK500-Besitzer schrieb:
>>(dumm-dumm-vista-schrott).>>Kennt wer das Problem?> Ja, es liegt an dir. Die Angabe zu FCPU im Makefile spielt für den> Controller keine Rolle. Die ist höchstens für die delay-Makros> interessant.
Und wenn man mal einen Meter weiter denkt, beeinflusst dies die
Wartezyklen im Programcode und somit wird bei falschen Zyklenzeiten das
Programm schneller als gewollt. GCC übersetzt nur den Code und der Code
bzw. die Makros berechnen die Schleifendurchläufe anhand der F_CPU, die
dadurch nicht mehr stimmen.
Oder um eine Analogie heranzuziehen
Es spielt keine Rolle, welche Endgeschwindigkeit (F_CPU) du auf einen
Autotacho schreibst (#define F_CPU), ein Trabbi (µC) wird keine 300km/h
schnell fahren, nur weils am Tacho so steht. Wenn man das haben möchte,
muss man den Motor/Getriebe (Quarz,Oszillator,Fuses) verändern.
F_CPU informiert das Programm über die Taktgeschwindigkeit, sie stellt
sie aber nicht ein.
Jungs, ich glaube das weiß er alles. Er schrieb doch, daß sich das
Programm bei gleichen Fuse-Einstellungen, nur dadurch, daß es unter
zwei verschiedenen Systemen mit dem selben F_CPU-Wert übersetzt wurde,
unterschiedliches Timing-Verhalten zeigt.
> Es spielt keine Rolle, welche Endgeschwindigkeit (F_CPU) du auf> einen Autotacho schreibst (#define F_CPU), ein Trabbi (µC) wird> keine 300km/h schnell fahren, nur weils am Tacho so steht.
Aber wenn der Fahrer nach Tacho 30 fährt (delay_ms), ist das Auto viel
zu schnell, weil der Tacho Mist anzeigt.
>Und wenn man mal einen Meter weiter denkt, beeinflusst dies die>Wartezyklen im Programcode und somit wird bei falschen Zyklenzeiten das>Programm schneller als gewollt. GCC übersetzt nur den Code und der Code>bzw. die Makros berechnen die Schleifendurchläufe anhand der F_CPU, die>dadurch nicht mehr stimmen.
Tut mir leid, aber mit sowas wie "delay" denke ich nicht.
Karl-Heins hat es wesentlich besser ausgedrückt...
Rolf Magnus schrieb:
> Jungs, ich glaube das weiß er alles. Er schrieb doch, daß sich das> Programm bei gleichen Fuse-Einstellungen, nur dadurch, daß es unter> zwei verschiedenen Systemen mit dem selben F_CPU-Wert übersetzt wurde,> unterschiedliches Timing-Verhalten zeigt.
Dann kanns eigentlich nur noch an unterscheidlichen
Optimizereinstellungen des Compilers liegen.
Aber noch weigere ich mich zu glauben, dass der Compiler
unterschiedlichen Code generiert, je nachdem ob er auf Vista oder XP
läuft. Und auch wenn ich sonst kein gutes Haar an Vista lasse, Vista
kann da überhaupt nichts dafür.
Noch unwahrscheinlicher ist es, daß der Compiler unter Vista x-mal
schnelleren, funktionsfähigen Code generiert.
Wenn es überhauot was mit Vista zu tun hat, dann vielleicht eher in der
Art, daß make nicht ordentlich funktioniert, und nach Änderungen im
makefile oder in einer headerdatei nicht alle Sourcen neu übersetzt.
Aber wie gesagt, reine Vermutung.
Isch 'abe gar kein Vista...
Oliver
Joa also... der Optimierungsgrad wird doch soweit ich weiß auch im
Makefile eingestellt? das bleibt auch das selbe (mit WinAVR erstellt).
Also die Situation ist recht seltsam im Nachhinein: mein grafisches
Display funktioniert über delay mit sehr optimierten Zeiten (beim enable
eine mikrosekunde weniger und schon geht das ganze nimmer so toll).
Scheinbar scheint diese Zeit nicht beeinträchtigt zu sein (kp wieso),
denn die Anzeige geht ganz toll. Allerdings sind alle delays in der
mainmethode ultraschnell; (unter dem Vistacode).
Also nochmal es ist die gleiche version von WinAvr (folglich der gleiche
Compiler etc). Wenn ich mit PonyProg einmal den auf Vista kompilierten
Code übertrage ist es kaputt (viel zu schnell) und den selben Code unter
XP kompiliert und über Vista + PonyProg übertrgaen geht ganz toll. Es
kann eigentlich nur am Compiler liegen da die .hex-files scheinbart
anders sind. Und die Fuses bleiben auch gleich und den Quarz habbich
auch nicht ausgetauscht. Und wie gesgat in der Display.c scheinen alle
delays zu stimmen...
LG
Hugo
>denn die Anzeige geht ganz toll. Allerdings sind alle delays in der>mainmethode ultraschnell; (unter dem Vistacode).
Lösch doch mal alle Objecfiles von Hand, um sicherzustellen, daß
wirklich alles neu kompiliert wird. Auserdem mal die Include-Pfade
überprüfen.
Oliver
So ich hab das ganze nochmal versucht:
ein neues Project mit nur einer main.c und dem Makefile.
Ne LED soll toggeln. Egal wa ich mache, der Aufruf von _delay_ms(x) wird
einfach ignoriert!
LG
der Hugo
