Hallo, Ich bin zu blöd dieses Problem in Test-Exponent.ino in Code zu fassen. Es kommt immer 0 heraus. Wo steckt mein Fehler?? Danke schon mal für Euere Hilfe!
Hallo, Was soll denn rauskommen? Ich erhalte 0,52. Edit: die Rubrik hier ist PC Programmierung. .ino ist Arduino und damit Rubrik µC. Vielleicht verschiebt es der Mod sobald er es sieht?
:
Bearbeitet durch User
Meint dein "exp" ein
? Dann wäre es:
1 | val = b * pow(M_E, e * wert / 10); |
wobei natürlich „e“ als Konstantenname ungünstig gewählt ist, da man dort eigentlich die Eulersche Zahl impliziert (die in <math.h> jedoch M_E heißt). Achso, #include <math.h> ist natürlich notwendig.
Veit D. schrieb: > die Rubrik hier ist PC Programmierung. Wobei sich das erstmal nicht grundlegend unterscheidet an dieser Stelle.
In https://www.arduino.cc/en/Reference/LiquidCrystalPrint steht geschrieben:
1 | data: the data to print (char, byte, int, long, or string) |
Da steht nichts von float oder double. Folglich werden die 0.517 zu int abgerundet, und das ergbit 0.
Jörg W. schrieb: > Achso, #include <math.h> ist natürlich notwendig. Mit einer aktuellen IDE nicht. Sonst würde er wegen fehlender include meckern. Macht es bei mir jedenfalls nicht. Ist wie mit 'progmem', ist auch nicht mehr notwendig extra zu inkludieren. Das nur am Rande.
Schön wäre so etwa 255. Das rechnet EXEL aus. Die Pulse 0-400 sollen exp auf 0-255 umgerechnet werden.
Hallo, normalerweise sollte auch lcd.print automatisch 2 Kommastellen mit float ausgeben, denn die Print Klasse wird "nur" vererbt. Mich wundert die Beschreibung in der Reference. Was macht dein Exponent dabei? Einen Bereich von einem zum anderen ginge auch mit map.
Friedhelm K. schrieb: > Schön wäre so etwa 255. Kommt auch raus, wenn du die Formel richtig hinschreibst.
Veit D. schrieb: > Einen Bereich von einem zum anderen ginge auch mit map. Genau das war der alte Code. Ich möchte aber keinen linearen Anstieg sondern so einen schön langsamen exponentiellen.
Fiete11 schrieb: > Hätte ich nur schreiben gelernt?! Es genügt vollauf, wenn du Lesen lernst … ich habe die Lösung schließlich wenige Minuten nach deiner Frage gepostet. Allerdings solltest du natürlich zusätzlich deine Allgemeinbildung verbessern und dir einprägen, wofür "exp(x)" typischerweise steht. Aber auch das schrieb ich bereits.
Jörg W. schrieb: > Es genügt vollauf, wenn du Lesen lernst … ich habe die Lösung > schließlich wenige Minuten nach deiner Frage gepostet. Gott sei Dank - Lesen geht noch. Ich habe <math.h> includiert und erhalte jetzt auch 0,52. Jörg W. schrieb: >> Schön wäre so etwa 255. > > Kommt auch raus, wenn du die Formel richtig hinschreibst. Die 255 suche ich noch? Trotzdem schon mal Danke bis jetzt!
Fiete11 schrieb: > Gott sei Dank - Lesen geht noch. Ich habe <math.h> includiert und > erhalte jetzt auch 0,52. Das war allerdings der kleinere Teil der Übung. >> Kommt auch raus, wenn du die Formel richtig hinschreibst. > > Die 255 suche ich noch? Dann lies dir bitte die Formel hier nochmal durch und vergleiche sie mit dem, was du dir ausgedacht hast: Beitrag "Re: Exponentialrechnung"
Friedhelm K. schrieb: > Test-Exponent.ino Hab mich zwar grad gewundert, dass es in der Arduino-Lib nur pow() gibt und kein powf(), somit nutzt pow() bereits nur float und nicht wie standardmäßig double. Aber ich würde es an deiner Stelle trotzdem so schreiben:
1 | val = pow(b, (M_E * wert / 10.0f)); // Exp.-Umrechnung |
Bei float Konstanten ein "f" anhängen. Hat beim Arduino evtl. keine Folgen, aber kann bei anderen Boards zu extremen Unterschieden führen, wenn der Compiler ohne dem "f" die Zahl als double annimmt - vor allem da du keine FPU hast. Beitrag "Re: SAM4E oder SAM7x" Punkt 2) Nur ein kleiner Tipp :)
Jörg W. schrieb: > Achso, #include <math.h> ist natürlich notwendig. Veit D. schrieb: > Mit einer aktuellen IDE nicht. welche meinst du? die 1.8.10 ist buggy, die 1.8.9 ist OK
Adam P. schrieb: > Hab mich zwar grad gewundert, dass es in der Arduino-Lib nur pow() gibt > und kein powf(), somit nutzt pow() bereits nur float und nicht wie > standardmäßig double. Huh? Ist aber egal, da bei AVR-GCC bislang sizeof(float) = sizeof(double) gilt. (Johann arbeitet gerade daran, dass es auch 64-bit double geben kann.) > Aber ich würde es an deiner Stelle trotzdem so schreiben: Das wird nicht besser. Solange ihr nicht verstanden habt, das exp(x) etwas anderes ist als a^x, bleibt das einfach Unfug. Die Eulersche Zahl e gehört nicht „irgendwie“ in den Exponenten hinein, sie ist die Basis.
So, ich habs gefunden!!! 255,56 ! Hatte mich streng an die Arduino-Anleitungen "POW" gehalten. Danke an Jörg und Adam!
Friedhelm K. schrieb: > Hatte mich streng an die Arduino-Anleitungen "POW" gehalten. Hast du da mal einen Zeiger, wo das wie beschrieben worden ist?
Jörg W. schrieb: > Aber ich würde es an deiner Stelle trotzdem so schreiben: > > Das wird nicht besser. Das Problem mit der Zahl e meinte ich damit auch nicht ;)
Ich hatte das hier so verstanden: http://www.arduino.cc/reference/en/language/functions/math/pow/
:
Bearbeitet durch Moderator
Friedhelm K. schrieb: > Ich hatte das hier so verstanden: Jetzt weis ich auch was Jörg meint, und ja, natürlich hat er recht. Dein Kommentar ganz oben im Code hat nichts mit deiner Berechnung zu tun. Kannst du mal mathematisch formulieren, was du eigentlich rechnen möchtest?
Die Beschreibung ist korrekt. Lag also vermutlich eher daran, dass du "exp(x)" also Schreibweise für "e^x" nicht kanntest, welches man dann mit pow() schreiben muss als "pow(M_E, x)".
Joachim B. schrieb: > Jörg W. schrieb: >> Achso, #include <math.h> ist natürlich notwendig. > > Veit D. schrieb: >> Mit einer aktuellen IDE nicht. > > welche meinst du? > > die 1.8.10 ist buggy, die 1.8.9 ist OK Was soll denn buggy sein? Abgesehen davon das ich immer die aktuelle Version verwende funktioniert das schon länger. Ich kann aktuell nicht nachvollziehen warum der TO plötzlich mit inkludierter math die fehlenden Nachkommastellen erhält. Entweder ist pow verfügbar oder nicht. So halb geht nicht. Mir soll es egal sein.
Veit D. schrieb: > Entweder ist pow verfügbar oder nicht. „Verfügbar“ ist es immer, weil die IDE offenbar immer auch -lm automatisch mit linkt. Aber ohne <math.h> gibt's eine Warnung "implicit function declaration" oder dergleichen (aber wer liest schon Warnungen, wenn man nicht durch -Werror dazu gezwungen wird? ;-). Dann wirkt halt der uralte Mechanismus, dass die Funktion als "returns int and takes an arbitrary number of arguments" angenommen wird.
:
Bearbeitet durch Moderator
Veit D. schrieb: > Was soll denn buggy sein? kann ich nicht mal so genau sagen, sowas schmeisse ich gleich aus dem Kopf. Kann mit der ESP32 Erweiterung zu tun haben, andere bestätigten die Probleme welche mit der Installation der 1.8.9 gelöst wurden. Meist nehme ich nie diie neuste Version, erst Recht nicht ohne Not, denn neue Versionen haben neue Fehler und warum soll man sich die holen wenn alles funktioniert?
Hallo Adam, Die Formel hat Jörg ja schon richtiggestellt. Ich hatte Messpunkte in eine Exel-Datei eingetragen und für diesen Werteverlauf hat Exel mir eine Trendlinie mit Formel angeboten. Die Formel lautete F(x) = 0,89 * exp(0,1415 * inputwert/10) Diese Formel will ich im Sketch verwenden um lineare Steuerwerte (0-400) in Ausgabewerte (0-255) umzurechnen. Die Ausgebewerte sollen exponentiell ansteigen.
Joachim B. schrieb: > Veit D. schrieb: >> Was soll denn buggy sein? > > kann ich nicht mal so genau sagen, sowas schmeisse ich gleich aus dem > Kopf. > Kann mit der ESP32 Erweiterung zu tun haben, andere bestätigten die > Probleme welche mit der Installation der 1.8.9 gelöst wurden. > > Meist nehme ich nie diie neuste Version, erst Recht nicht ohne Not, denn > neue Versionen haben neue Fehler und warum soll man sich die holen wenn > alles funktioniert? Hallo, deswegen ist die Aussage "soll buggy sein" nicht sinnvoll. Entweder man hat selbst ein Problem oder nicht. Die aktuelle Version zu meiden widerspricht im Grunde der Logik von Updates. Demzufolge dürftest du nie updaten. Verstehe ich nicht. Lies dir die Releasenotes durch was alles geändert wurde. Und Probleme mit einer Erweiterung für fremde Boards (ESP) kann man nicht der IDE zu schieben.
Fiete11 schrieb: > Die 255 suche ich noch? Friedhelm K. schrieb: > F(x) = 0,89 * exp(0,1415 * inputwert/10) Jörg W. schrieb: > "exp(x)" [...], welches man dann > mit pow() schreiben muss als "pow(M_E, x)". So, jetzt soll es nicht mehr so schwer sein die Lösung zu finden.
Jörg W. schrieb: > Ist aber egal, da bei AVR-GCC bislang sizeof(float) = sizeof(double) > gilt. Hängt jetzt an der Konfiguration von avr-gcc: 64-bit double erhält man z.B.mit --with-double=64 oder --with-double=64,32. Oder mit --with-double=32,64 und -mdouble=64 als Option. http://gcc.gnu.org/install/configure.html#avr Wobei das >> If more than one value is specified, respective multilib variants >> are available eigentlich heißen müsste >> If more than one value is specified, respective multilib variants >> are supported ob die wirklich verfügbar sind — und das betrifft alle Funktionen aus libc, libm, libdevice und Startup-Code — hängt davon ab, was avr-libc kann (oder aktuell eben nicht kann).
Veit D. schrieb: > Entweder man > hat selbst ein Problem oder nicht. was hast du nicht verstanden? mit der 1.8.10 hatte ich Probleme ein anderer User auch, nach zurückschalten auf 1.8.9. hatten wir beide dann Erfolg! Veit D. schrieb: > Und Probleme mit einer Erweiterung für fremde Boards (ESP) kann man > nicht der IDE zu schieben. Mich hat das dann auch nicht mehr interssiert, aber OK die 1.8.2 bis 1.8.8 gingen alle bei mir. ach
:
Bearbeitet durch User
Beitrag #6062289 wurde vom Autor gelöscht.
Hallo, das verstehe ich nicht. Du hast doch gesagt du machst keine Updates, weil die alle Fehler enthalten. Deine v1.8.9 war auch einmal ein Update von der 1.8.8, diese ein Update der 1.8.7 usw.. Warum verwendest du verbuggte Versionen? Erkennst du denn tieferen Sinn deiner Aussage? Das die ESP Erweiterungen selbst Updates bringen weißt du hoffentlich. Das diese Bugs haben können und hatten weißt du hoffentlich.
Veit D. schrieb: > Deine v1.8.9 war auch einmal ein Update > von der 1.8.8, diese ein Update der 1.8.7 usw.. Warum verwendest du > verbuggte Versionen? nö du verstehst es nicht, ich nutze min. 5 Rechner und mal bekommt der eine ein nötiges Update mal der andere, auch wenn ich weiss das 1.8.2 bei einem funktioniert dann muss ich den ja nicht updaten auch wenn die 1.8.8 raus ist. Die 1.8.8 kommt dann auf einen anderen Rechner an dem ich weiterarbeiten möchte und als ich bei einem weiteren Rechner merkte das die 1.8.10 nicht funktionierte trat ich eben einen Schritt zurück auf 1.8.9 und siehe da es funktionierte. Mir kommts gerade so vor als wenn du Streit suchst oder absolut verständnislos bist, ja solche Menschen gibt es auch, ich wünsche dir trotzdem gutes Gelingen.
:
Bearbeitet durch User
Jörg W. schrieb: > Dann wirkt halt der uralte Mechanismus, dass die Funktion als "returns int > and takes an arbitrary number of arguments" angenommen wird. Den Mechanismus gibt's aber nur in C, und Arduino setzt doch auf C++ auf. Da sollte beim Versuch, eine nicht deklarierte Funktion aufzurufen, ein Fehler kommen.
Rolf M. schrieb: > Den Mechanismus gibt's aber nur in C, und Arduino setzt doch auf C++ > auf. Stimmt auch wieder. Dann habe ich dafür auch keine Erklärung.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.