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.
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.
habe es so versucht:
OCR1A=(int)k;
funktioniert auch nicht...
fehler meldung ist für mich auch nicht verständlich:
Build started 30.4.2010 at 21:14:40
avr-gcc -mmcu=atmega32 -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT
Pflichtsoftware1.o -MF dep/Pflichtsoftware1.o.d -c
../Pflichtsoftware1.c
avr-gcc -mmcu=atmega32 -Wl,-Map=Pflichtsoftware1.map Pflichtsoftware1.o
-o Pflichtsoftware1.elf
c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5\lib
c.a(log.o): 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)
c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5\lib
c.a(log.o): In function `log':
(.text.fplib+0x4e): 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)
make: *** [Pflichtsoftware1.elf] Error 1
Build failed with 1 errors and 0 warnings...
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.
Hallo,
wieso verwendest du überhaupt "float" Variablen? Sollte auch ohne gehen.
Denn ich sehe nur ganzzahlige Werte. Und eine Division kommt auch nicht
vor ...
Verwende einfach Int16 bzw. Int32. Das macht auch den Code deutlich
kleiner.
hm das Problem ist aber nur beim laden ins OCR1A Register.. ich konnte
mit float rechnen, diese Werte ans Display übergeben, das hat keine
Probleme verursacht..
float Bibliothek ist vorhanden, hab es soeben überprüft.
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.
Karl heinz Buchegger, sie haben recht, wenn ich die Log funktion
ausklammere kommt die Fehlermeldung nicht...
aber ich kann auf diese Funktion leider nicht verzichten...
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.
Eine Frage am Rande: wie oft wird der Timer0-Interrupt aufgerufen? Ich
werde aus
> Initialize_Timer0(2,2,256);
nicht schlau ...
Unabhängig vom Compilier-Fehler: In einer ISR fasst man sich kurz. Hier
solltest du nur die Messwerte der Sensoren einlesen und sie dann im
Hauptprogramm bearbeiten.
Gerade Floating Point Berechnungen brauchen viel Zeit ... (und die hat
man in einer ISR normalerweise nicht.)
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:> 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.-)
Ist bei der Fehlermmeldung eigentlich eindeutig. Wenn der Linker
versucht Fließkommaroutinen (wie log) aus der libc.a zu benutzen, fehlt
immer die libm.a. Entweder weil sie nicht mit angegeben wurde oder wenn
doch, dann aber an der falschen Stelle.
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...