Float to Int?

Lea Weiss schrieb:
> Hey Leute, ich möchte gerne meine Output Compare Register mit einer
> Variable laden
>

1

> OCR1A=k;

2

>

> dies funktioniert nicht weil k ein Float Wert ist.

Nö. das funktioniert schon.
Bei der Zuweisung eines float an einen int werden alle Kommastellen 
abgeschnitten und das Ergebnis als int weiterbehandelt.

Wäre mir neu, mWn muss man diesen Verlust an Informationen explizit 
erlauben mit einem Cast zu einem int.

1

OCR1A = (int)k;

Eine Erweiterung mit Informationen, also einen int einem Float zuweisen, 
das ist aber ohne Cast möglich.

Thomas K. schrieb:
> Wäre mir neu, mWn muss man diesen Verlust an Informationen explizit
> erlauben

Nö, muss man nicht.
Einige Compiler warnen, wenn so etwas passiert. Aber grundsätzlich ist 
das nicht verboten.

Aber genau das war doch der Unterschied zwischen expliziten und 
impliziten Casts. Implizite macht der Compiler stillschweigend (und alle 
samt ohne Datenverlust) und explizite waren immer bei Datenverlust nötig 
(oder bei komplexen Typen).

Ok, das war nun nicht der Unterschied der definiert was implizit und 
explizit Casts sind. Sondern der Unterschied der die Anwendung dieser 
beschreibt/nötig macht.

/EDIT: Aber du hast Recht. Habe mich nochmal kundig gemacht und 
getestet. Bin wohl noch etwas von Delphi/Pascal geschädigt, da ist es 
wie ich es geschrieben hatte. Aber eine strenge Typprüfung ist ja einer 
der Punkte von Delphi Language/Pascal. In C/C++ ist kein Cast notwendig.

Thomas K. schrieb:
> Aber genau das war doch der Unterschied zwischen expliziten und
> impliziten Casts. Implizite macht der Compiler stillschweigend (und alle
> samt ohne Datenverlust) und explizite waren immer bei Datenverlust nötig
> (oder bei komplexen Typen).

Du must unterscheiden zwischen einem Fehler, von dem die 
Sprachdefinition fordert, das er angemäkelt wird und einer Warnung, die 
ein Compilerbauer von sich aus, aus freien Stücken, eingebaut hat.

Die Zuweisung eines float an einen int ist kein Fehler. Selbst wenn 
einige Compiler (aus guten Gründen) eine Warnung geben. So nach dem 
Motto: "Ich tu schon was du von mir willst, aber bist du dir da wirklich 
sicher? Oft ist das ein Flüchtigkeitsfehler, drum werfe ich mal 
sicherheitshalber eine Warnung."

Aber auf jeden Fall ist das kein Kandidat für
<Zitat>
dies funktioniert nicht
</Zitat>

Im übrigen ist diese Version, die auch noch rundet

1

  OCR1A = (int)( k + 0.5);

meistens die bessere Wahl. Sonst kann es nämlich ganz schnell passieren, 
das aus 5.99999999 (also praktisch 6) trotzdem 5 wird und nicht 6.

Das müsste sein:
Du hast die Floating Point Library nicht eingebunden, oder mit deiner 
Installation stimmt etwas nicht.

Und wie zum Teufel kommst du von der Fehlermeldung auf die o.g. 
Fehlerzeile?

@khbuchegg: hatte oben schon editiert, du hast vollkommen Recht. Hatte 
das noch anders im Kopf aufgrund der langen Delphi/Pascal 
Programmierung. Hatte es auch schon ausprobiert.

Die float.h hilft nur dem Compiler.
Wenn der Linker Fehlermeldungen spuckt, fehlt meist die libm,
und die wird mit -lm eingebunden.

Das war damit wohl gemeint:
Karl heinz Buchegger schrieb:
> Du hast die Floating Point Library nicht eingebunden, oder mit deiner
> Installation stimmt etwas nicht.

Klaus Wachtler schrieb:
> Die float.h hilft nur dem Compiler.
> Wenn der Linker Fehlermeldungen spuckt, fehlt meist die libm,
> und die wird mit -lm eingebunden.
>
> Das war damit wohl gemeint:
> Karl heinz Buchegger schrieb:
>> Du hast die Floating Point Library nicht eingebunden, oder mit deiner
>> Installation stimmt etwas nicht.

Genau.
Aber ich wusste nicht mehr auswendig, wie man das im AVR-Studio macht 
:-)

Inzwischen hab ich nachgesehen:

Menüpunkt "Project" / "Configuration Options"
Im Dialog dann links "Libraries" anklicken
Im linken Listfeld die libm.a auswählen und "Add Library"

Alles mit OK bestätigen und erneut Builden lassen.

Lea Weiss schrieb:
> In der Subroutione wird mit einer Log() funktion gerechnet, daher
> entstehen Zahlen mit Kommastellen

LOL.
Wusste gar nicht das der gcc soooo gut ist.

Die Fehlermledung beschwert sich dass etwas mit log nicht stimmt.

In function `log':
(.text.fplib+0x46): relocation truncated to fit: R_AVR_13_PCREL against
symbol `__addsf3' defined in .text section in
c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_addsub_sf.o)


und in deiner ISR kommt ein log vor.
Was ist dein logischer Schluss?

> das Problem ist aber nur beim laden ins OCR1A Register.

Das ist der falsche Schluss. Der hat damit nichts oder nur auf Umwegen 
zu tun.

Aber temperatur_ist_NTC

Ist die volatile?

Im übrigen brauchst du nicht mit mir streiten, denn: Der Compiler/Linker 
hat immer recht. Und dein Linker (nicht der Compiler) beschwert sich, 
dass er ein Problem mit der Funktion log() hat. Steht schwarz auf weiß 
dort.

Das kann nichts mit der Zuweisung zu tun haben. Ausser: Lässt du die 
Zuweisung weg, kann es sein, dass die Voraussetzung für die Berechnung 
des log() in der ISR wegfällt und der Optimizer den log ganz einfach 
rauswirft. Kein log() mehr, kein Problem für den Linker.

Lea Weiss schrieb:
> ist nicht volatile..

Dann solltest du die ganz schnell volatile machen. Genauso wie alle 
anderen Variablen, die sowohl in der ISR als auch in main() benutzt 
werden. Und eine Absicherung auf atomaren Zugriff wäre auch dringend 
angeraten. Vor allen Dingen dann, wenn du darauf bestehst alles in float 
zu lassen.

Es ist irgendein Problem in deiner Konfiguration.
Die libm.a sagst du hast du beim Projekt dabei.

Hmm.
Dein WinAVR ist schon reichlich angestaubt. Nimm mal eine andere 
Version.

Spielt kaum eine Rolle. Dieser PID Regler wird, wenn überhaupt, nur 
durch Zufall funktionieren.
Das ist wie wenn du einem 100-m Sprinter einen Betonklotz ans Bein 
bindest. Der kommt auch nicht weit.

Lea Weiss schrieb:
> libm.a??

Ich habs dir doch weiter oben aufgeschrieben
Beitrag "Re: Float to Int?"

Lea Weiss schrieb:
> soso, wie würdest du es denn machen?

Auf jeden Fall nicht mit float

> bisher hats nicht so schlecht funktioniert ;)

Ach. Ich dachte du konntest es bisher noch gar nicht linken.-)

Du bist nicht die erste mit so einer (oder so einer ähnlichen) 
Fehlermeldung :-)

Karl heinz Buchegger schrieb:

> In function `log':
> (.text.fplib+0x46): relocation truncated to fit: R_AVR_13_PCREL against
> symbol `__addsf3' defined in .text section in
> c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/avr5\libgcc.a(_addsub_sf.o)

Das Problem ist also, daß bestimmte Relocs nicht passen, weil Offsets 
für PC-relative Adressierung zu groß werden. Irgendwer ruft da die 
__addsf3 auf, und das kann eigentlich nur avr-gcc sein, weil die 
__addsf3 zur libgcc gehört. Möglicherweise kann der Linker das 
ausbügeln, wenn man ihn Sprünge relaxen lässt.

Daß das Problem (zunächst) verschwindet, wenn man das Programm kleiner 
macht, hat nix zu sagen. Dadurch passt die Adresslage wieder, weil dann 
anders lokatiert wird. Irgendwann hat man das Ding aber wieder am 
Schenkel kleben...