|
Anzeige
|
#define funktioniert nicht
Gast
#4171040
Hallo, kann mir jemand sagen, wieso die Berechnung von FAKTOR nicht funktioniert? Eigentlich hätte ich einen wert von 92 erwartet. Tatsächlich kommt aber irgendetwas deutlich kleineres raus. Ohne die äußeren Klammern lässt es sich sogar gar nicht kompilieren, was ich auch nicht verstehe. Ich benutze den XC8 Compiler von Microchip.
Gast
#4171048
Besser so: ((R_OBEN + R_UNTEN)/ R_UNTEN / 255) * V_DD
Gast
#4171050
R_OBEN + R_UNTEN > als max_int -> überlauf
Gast
#4171053
Peter II schrieb: > R_OBEN + R_UNTEN > als max_int -> überlauf sorry noch mal richtig (R_OBEN + R_UNTEN) * V_DD > als max_int -> überlauf Bernd schrieb: > Ohne die äußeren Klammern lässt es sich sogar gar nicht kompilieren Da du weder den eigentlichen Code zeigst noch die Fehlermeldung nennst, kann man auch nicht sagen wo der Fehler liegt. Klammern sind aber grundsätzlich eine gute Idee wenn man defines verwendet. Es herrscht immer wieder der Irrglaube, dass der Präprozessor Berechnungen tätigt. Das tut er nicht, er ersetzt nur Zeichenketten durch andere Zeichenketten. Berechnen tut der Prozessor, wenn der Compiler nicht optimiert. Und das tut der XC8 nicht in der Free-Version. Es entsteht ein Überlauf. Den kannst du umgehen, wenn du die entsprechende Speicherbreite angibst, hier uint32_t.
Gast
#4171064
also mit gcc geht's. FAKTOR = 92
Gast
#4171070
> kann mir jemand sagen, wieso die Berechnung von FAKTOR nicht > funktioniert? Weil die Zahlen alles normale int sind, sind die berechnung mit den Algorithmen für int durchgeführt. Dabei treten zwischenergebnisse auf, die für int jedoch zu groß (10000+2700)*4990 = 63373000
Gast
#4171071
Stefan Us schrieb: > Das passt nicht in einen int rein. Wenn das ein Ausdruck in C wäre, > würde ich irgendwo (long int) einbauen, um größere Zwischenspeicher zu > erzwingen. Ich bin allerdings nicht sicher, wie man das bei einem > Präprozessor Kommando macht und ob es dort überhaupt geht. genauso, weil der Präprozessor nichts anders macht als eine Textersetzung. Er rechnet an dieser stelle überhaupt nicht.
Gast
#4171073
Wow, danke für die ganzen schnellen Antworten! Joe schrieb: > ((R_OBEN + R_UNTEN)/ R_UNTEN / 255) * V_DD Geht leider auch nicht. Ich vermute die Klammer würde 0 ergeben. Peter II schrieb: > (R_OBEN + R_UNTEN) * V_DD > als max_int -> überlauf Danke, das ist schon mal die Erklärung. Fehlt die Lösung ;) Little Basdart schrieb: > Es entsteht ein Überlauf. Den kannst du umgehen, wenn du die > entsprechende Speicherbreite angibst, hier uint32_t Das ist dann wohl die Lösung. Aber ich muss leider fragen, wie ich das genau mache? So wie bei einer normalen Berechnung mit typecast?
Gast
#4171081
Peter II schrieb: > genauso, weil der Präprozessor nichts anders macht als eine > Textersetzung. Er rechnet an dieser stelle überhaupt nicht.
Angehängte Dateien:
Gast
#4171087
genau schrieb: > Peter II schrieb: >> genauso, weil der Präprozessor nichts anders macht als eine >> Textersetzung. Er rechnet an dieser stelle überhaupt nicht. und was willst du damit sagen?
Gast
#4171096
Little Basdart schrieb: > s herrscht immer wieder der Irrglaube, dass der Präprozessor > Berechnungen tätigt. > > Das tut er nicht, er ersetzt nur Zeichenketten durch andere > Zeichenketten. > Berechnen tut der Prozessor, wenn der Compiler nicht optimiert. Das spielt aber eigentlich keine Rolle, denn auch wenn der Compiler optimiert, muß das Ergebnis das gleiche sein, wie wenn der Prozessor es berechnet hätte.
Gast
#4171103
Peter II schrieb: > genau schrieb: >> Peter II schrieb: >>> genauso, weil der Präprozessor nichts anders macht als eine >>> Textersetzung. Er rechnet an dieser stelle überhaupt nicht. > > und was willst du damit sagen? Er will dir nochmal anhand des Bildes zeigen, daß du Recht hast.
... und schon ändert sich das Verhalten. Antwort schreiben |
Anzeige
|
