Hallo, ich habe eine Funktion AtoF, die einen String in ein Float umwandelt. Wenn ich die Funktion jetzt das Resultat zurück geben lasse, sie also deklariere als float AtoF (char* s) { float z; (...Berechnung des Resultats in z...) return z; } und in main aufrufe mit float f=0; f= AtoF ("123,123"); steht in f ein völlig falscher Wert (die Funktion arbeitet einwandfrei, kann also nur an der Übergabe liegen). Wenn ich die Funktion jedoch so deklariere, dass eine Adresse für das Ergebnis übergeben wird, funktioniert es: void AtoF (char* s, float* f) { (...Berechnung des Resultats in *f...) } Aufruf in main: AtoF ("123,123", &f); //richtiger Wert in f Kann mir jemand sagen, wo der Fehler liegen könnte? Kann es ein Problem mit dem Stack geben?
Mal probiert, probeweise return z; durch return 123.45; zu ersetzen?
Selber Fehler, anderer Wert in f. Mit einer anderen Funktion AtoI auf Integer-Basis funktioniert die Rückgabe.
Was für ein Prozessor war das noch gleich? Ich meine mich erinnern zu können, dass Du mal irgendwas exotisches hattest, wo Du keine Standard-Bibliotheken zur Verfügung hast... Das ist ja vermutlich auch der Grund dafür, dass Du keine Funktionen aus der stdlib.h verwendest, gelle? Wie sieht das denn mit der Speicherverwaltung und Zugriff aus? Beim AVR-GCC werden konstante Strings per se im Flash abgelegt und dementsprechend müssen auch die Zeiger zur Übergabe an Funktionen ausgelegt sein. Deshalb müsste eine Funktion, die einen konstanten String übergeben bekommt in der Art
1 | float funktion(char PROGMEM *s) |
2 | {
|
3 | //Code
|
4 | }
|
Klappt halt nur mit Angabe des Speicherortes. Nur so als Idee. Wie das jetzt bei Dir läuft, weiß ich natürlich nicht.
Ach ja, versuche mal einfach, den String nicht direkt als Argument zu übergeben, sondern ihn vorher im SRAM als Variable zu speichern und dann auszugeben.
1 | char string[] = "123,123"; |
2 | //...
|
3 | f = AtoF(string); |
Dann müsste ja zumindest was Sinnvolles zurückkommen (vorausgesetzt die Funktion ist korrekt...), da ja jetzt String und Zeiger kompatibel sein müssten.
Upps, hab jetzt erst gesehen, dass es mit der anderen Variante ja klappt... Dann vergiss einfach, was ich bisher geschrieben habe...
Benutze den Xilinx MicroBlaze. Mir stehen die Standardbibliotheken schon zur Verfügung, nur alle Funktionen zur Typumwandlung, die ich bis jetzt ausprobiert habe, funktionieren fehlerhaft. Andere Standardfunktionen laufen dagegen. Habe die Variable f mal global deklariert, bringt aber auch keine Änderung.
Jetzt geht's, hatte vergessen die Funktionsprototypen einzubinden. Fragt sich nur wieso der Compiler da nicht gemeckert hat.
Wenn du die adresse nutzt, wuerde ich sagen ist es effektiver, da es nur nen int ist, und somit schneller ;)
TechInfo wrote:
> Fragt sich nur wieso der Compiler da nicht gemeckert hat.
Weil du ihm das wahrscheinlich nicht gesagt hast, dass er darüber
meckern soll. Er nimmt dann die Funktion entsprechend dem
prähistorischen K&R-Standard implizit als einen int zurückgebend
und eine beliebige, nicht spezifizierte Anzahl Argumente übernehmend
an.
Hi es gibt da aber auch Compiler die dieses Problem erst bei einem Warning-Level anwarnen bei dem man von irgendwelchen "maybe performance critical" Kram bereits erschlagen wird. Ich will ja keine Namen nennen aber das Ding kommt von einer japanischen Halbleiterfirma deren Name mit F beginnt. schauder Könnte mal jemand den GCC für diese Familie portieren? duckundweg Matthias
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.