Hallo!
Ich verwenden den AT32UC3C (AVR Studio6) und berechne in meinem Programm
float variablen. Das Ganze hat immer funktioniert, nun bin ich auf ein
neues Board (eigene Hardware) umgestiegen und habe auf einmal Probleme
mit den float-Variablen.
Hier der Code:
1
void SamplingTimerCallback()
2
{
3
float voltage = 5.5;
4
5
for (U8 i = 0; i < TEMP_CONTROL_NUM_CONTROLS; i++)
6
{
7
control_array[i].Ta_counter++;
8
if(control_array[i].Ta_counter > control_array[i].Ta * 100 ) // sampling time is reached, * 100 because Ta is adjusted in s, and this callback function is called every 10ms -> * 1000/10
das Ganze wird einfach alle 10ms aufgerufen und float werte (z.B.
voltage) berechnet. Alle float variablen haben jedoch sehr hohe werte
und stimmen überhaupt nicht.
voltage = (adc_value * TEMP_CONTROL_REF_VOLTAGE) /
TEMP_CONTROL_ADC_RANGE;
adc_value ist ein normaler S16, dessen wert auch immer stimmt (1345)
TEMP_CONTROL_REF_VOLTAGE ist eine Konstante mit 2.345 definiert
TEMP_CONTROL_ADC_RANGE ist eine Konstante mit 2048 definiert.
für voltage kommt jedoch immer die Zahl 1065353216 raus, keine Ahnung
warum!
Kann mir dabei jemand weiterhelfen?
Danke, lG
Und weshalb muss man float in eibnen timer rechnen ? Die gezeigten float
Rechnungen dienen dem benutzerinterface und brauchen daher nur mit
Userinterface Geschwindigkeit neu berechnet werden.
Zum Problem. Der UC3C hat eine FPU, andere ev nicht, dann macht es die
Library. Allenfalls in dieser Richtung weitersuchen.
Dann sich Zwischnewerte per UART oder so ausgeben lassen um den fehler
zu finden.
Siebzehn Zu Fuenfzehn schrieb:> Zum Problem. Der UC3C hat eine FPU, andere ev nicht, dann macht es die> Library. Allenfalls in dieser Richtung weitersuchen.
Ich verwende weiterhin den gleichen Controller.
Keine Ahnung, warum das nicht mehr funktioniert :(
Hans Peter schrieb:> es ist übrigens egal, wie groß adc_value ist. der wert von voltage> bleibt imme rgleich, kann sich das jemand erklären?
wo siehst du denn den wert? Im Debugger, wenn ja mal ohne Optimierung
testen.
Um das Ganze einfacher zu machen:
Hab nun zum test in der Main aingefügt:
float a = 5.3;
float b = 2.4;
float c = a*b;
Wenn ich unmittelbar nach diesen 3 Zeilen einen Breakpoint setzte, und
mir die werte anschaue:
a= 1084856730
b= 1075419546
c= 1095468320
Siehe Anhang!
Schön langsam verstehe ich die Welt nicht mehr...
Bitte um Hilfe!
Danke!
Hans Peter schrieb:> Schön langsam verstehe ich die Welt nicht mehr...
sicher das du ohne Optimierung arbeitest?
Verwende mal die Variabel C ( z.b in einem Printf )
printf("%f", c );
wenn ich volatile vor float setze, habe ich das gleiche Problem. Meines
wissens dürfte er mit volatile deklarierte variablen nicht
wegoptimieren, also liegts nicht an der Optimierung. :(
Hier wird einfach der Speicherwert des Floats angezeigt.
Ggf. kann man dies im Debugger umstellen.
Gibt man bei folgendem Link z.B. 5.3 ein, kommen genau die oben
angegebenen 0x40a9999a == 1084856730 raus:
http://www.h-schmidt.net/FloatConverter/IEEE754.html
WOW!
warum wird denn hier auf einmal der speicherwert angezeigt?
das heißt, es ist nur ein anzeigefehler, im Hintergrund wird richtig
gerechnet?
Wie kann ich denn den tatsächlichen wert anzeigen lassen?
Ihr seid wirklich spitze!
Vielleicht handelt es sich um dieses Problem:
http://asf.atmel.com/bugzilla/show_bug.cgi?id=3429
Zur Not könntest Du den Wert testweise mit sprintf in einen String
speichern und Dir den im Debugger anschauen.
Hans Peter schrieb:> Wie kann ich denn den tatsächlichen wert anzeigen lassen?
Float sind Bits, die genauso im Speicher liegen, wie die anderen
Variablen auch. Wie du die Bits interpretierst und anzeigen läßt, bleibt
dir überlassen. Int kannst du auch als Dezimal, Hex, Binär oder sonstwie
anzeigen lassen.
DirkB schrieb:> Nein. Das Problem tauchte hier schon öfter auf.
Und warum finde ich dann nichts diesbezüglich bzw. kann jemand posten,
woran das wirklich liegt?
Ist das Problem jenes, das Hans gepostet hat, das es also ein Bug im AVR
Studio ist?
HAllo,
ich habe nun schon von einigen gehört, dass man das " Use GDB" Flag
setzen kann, dann funktioniert es wieder. Aber bei mir nicht, wenn ich
das aktiviere, bekomm ich beim Versuch zu debuggen andauernd
Fehlermeldungen, der Debugger wird nicht mehr erkannt und das Atmel
Studio stürzt dauernd ab.
Schön langsam reichts mir mit ATmel Studio, andauernd bringen sie neue
Versionen raus, die mehr Bugs besitzen wie die alten. Beim 6.1. hat das
nämlich einwandfrei funktioniert. Ich habe das schon öfters erlebt, dass
in einer neuen Version auf einmal manche Dinge nicht mehr funktionieren,
die in der alten Version einwandfrei funktioniert haben.
Hans Peter schrieb:> Schön langsam reichts mir mit ATmel Studio, andauernd bringen sie neue> Versionen raus, die mehr Bugs besitzen wie die alten.
ich weiss warum ich immer noch mit 4.18 arbeite
wozu updaten wenns geht ?
m.n. schrieb:> Joachim B. schrieb:>> ich weiss warum ich immer noch mit 4.18 arbeite>>>> wozu updaten wenns geht ?>> Aber die 4.19 könntest Du Dir doch schon gönnen!
hatte ich versucht, aber da gab es auch ein Problem, -> verdrängt ....
wieder 4.18 installiert, geht !
ich progge gleiche Projekte an 5 Rechnern und da ist es optimal wenn es
an allen gleich läuft
@m.n. (Gast)
>> ich weiss warum ich immer noch mit 4.18 arbeite>> wozu updaten wenns geht ?
EBEN! Mach ich auch so!
>Aber die 4.19 könntest Du Dir doch schon gönnen!
Nö, die hat Probleme mit dem AVR GCC da geht was nicht so richtig. Darum
"nur" 4.18. Läuft wie geschmiert.
Joachim B. schrieb:> hatte ich versucht, aber da gab es auch ein Problem, -> verdrängt ....>> wieder 4.18 installiert, geht !
Interessant; werde ich mir für den Fall merken, dass es mal haken
sollte.
Für AVR32 aber wohl keine Lösung, da diese noch nicht unterstützt werden
(oder ich es mal wieder nicht raffe und auch nicht brauche).
Auch die ATtiny441/841 sind dort nicht bekannt; das stört mich am
meisten.
