AVR-GCC unter Vista erkennt Geschwindigkeit nicht

[Hugo (Gast)]

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

[Christian R. (supachris)]

Das ist dann wohl eher ein Problem der FuseBits, und nicht von Vista....

[Hugo (Gast)]

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

[STK500-Besitzer (Gast)]

>(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.

[Thomas K. (muetze1)]

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.

[Karl H. (kbuchegg)]

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.

[Rolf Magnus (Gast)]

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.

[STK500-Besitzer (Gast)]

>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...

[Karl H. (kbuchegg)]

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.

[Oliver (Gast)]

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

[Hugo (Gast)]

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

[Oliver (Gast)]

>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

[Hugo (Gast)]

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

[Oliver (Gast)]

Häng mal das ganze Projekt (den ganzen Order mit allen Dateien, 
zusammengezippt) hier an.

Oliver