Ich habe folgendes Problem: In meinem C-Code sende ich den Wert 49,00 und will in python dies in 4,9 umwandeln. Habe also den wert in Python durch 10 genommen, aber dieser schneidet mir die 9 weg und gibt mir nur die 4,00 an. Habe auch versucht das im C-Prgramm zu ändern aber ohne Erfolg. wie kann ich dies in Python umsetzen? Code: # Ermitteln von Messwerte import serial ser = serial.Serial(port='COM4', baudrate=9600, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE) x=ord(ser.read()) y=ord(ser.read()) print "X-Achse: %.2f" % float(x/10), print "Y-achse: %.2f" % float(y/10),
Empfängst du denn überhaupt einen Kommawert von der seriellen Schnittstelle? Ansonsten sieht das nach einem Datentyp Problem aus, bei Python kann ich dir nur leider nicht helfen :(
Python ist nicht gleich Python.. In v2.x ist
1 | 4/3 = 1 |
In Python v3.x ist
1 | 4/3 = 1.33333 |
2 | 4//3 = 1 |
Das könnte hier ein Problem sein. Gruß Dennis
ich soll das ja umgehen in dem ich den Wert im Mikrocontroller mal 10 nehme und dann im PC durch 10 nehme
RCB schrieb: > ich soll das ja umgehen in dem ich den Wert im Mikrocontroller mal 10 > nehme und dann im PC durch 10 nehme WAS sollst du umgehen? Ich habe es so verstanden, dass auf deinem PC ein Python-Programm läuft welches die Zahl 49 empfängt. Du willst daraus 4,9 machen, also musst du durch 10 dividieren. Dies ist aber in Python 2 und Python 3 unterschiedlich zu realisieren. Entweder / oder // so wie ich oben geschrieben habe. Gruß Dennis
Langsam, Ganz schrieb: > Du muss wirklich 49.00/10 rechnen, nicht 49/10. > Dann gehts! Korrekt... die wichtigste Info kam vom TO halt nicht gleich am Anfang.
Rafael B. schrieb: > x=ord(ser.read()) > y=ord(ser.read()) Ist das wirklich richtig so? Meiner Meinung nach empfängst du hier ein Byte über die serielle Schnittstelle und machst mit ord() ein ASCII-Zeichen draus. Aber eben nur ein Zeichen. Was kommt denn über die serielle Schnittstelle rein? Kommt da die "49,00" als String? Dann wäre das ord() fehl am Platz...
Nein ich bekomme ein ASCII zeichen. und mit ord wandle ich dies in einer Zahl um. im Internet habe ich diesen Befehl gefunden
RCB schrieb: > Nein ich bekomme ein ASCII zeichen. und mit ord wandle ich dies in > einer > Zahl um. im Internet habe ich diesen Befehl gefunden Dann ist das dein Fehler. Schau dir mal die Beschreibung von ord() an. https://docs.python.org/2/library/functions.html#ord
Rafael, dir ist klar, dass der 8-Bit Wert vom ADC erstmal in einen entsprechenden Spannungswert umgerechnet werden muss ? 0 entspricht dabei 0V, aber 255 entspricht
:
Bearbeitet durch User
The D. schrieb: > Rafael, dir ist klar, dass der 8-Bit Wert vom ADC erstmal in einen > entsprechenden Spannungswert umgerechnet werden muss ? 0 entspricht > dabei 0V, aber 255 entspricht die Umrechnung mache ich. aber mit 1024 da der ADc 10 Bit hat
> Dann ist das dein Fehler. Schau dir mal die Beschreibung von ord() an. > https://docs.python.org/2/library/functions.html#ord ohne diesen Befehl kriege ich den ASCII zeichen was ich já nicht will
RCB schrieb: > die Umrechnung mache ich. aber mit 1024 da der ADc 10 Bit hat Wenn du aber nur ein Byte überträgst, kannst du nur Werte bis max. 255 kriegen. Und Kommazahlen schon gar nicht...
RCB schrieb: > The D. schrieb: >> Rafael, dir ist klar, dass der 8-Bit Wert vom ADC erstmal in einen >> entsprechenden Spannungswert umgerechnet werden muss ? 0 entspricht >> dabei 0V, aber 255 entspricht > > > die Umrechnung mache ich. aber mit 1024 da der ADc 10 Bit hat Ok, im C-code, den du mir gezeigt hast schickst du nur 8-Bit vom ADC über die serielle Schnittstelle.
ich will doch keine senden. und dies zu umgehen will ich ja eine Umrechnung machen
The D. schrieb: > Ok, im C-code, den du mir gezeigt hast schickst du nur 8-Bit vom ADC > über die serielle Schnittstelle. Was meinst du damit? Ich sehe nur ein Stück python, was ein Byte empfängt. Wo ist hier c-Code, der was sendet? :-)
RCB schrieb: > ich will doch keine senden. und dies zu umgehen will ich ja eine > Umrechnung machen den adc wert den ich rauskriege ist 1023. deswegen nehme ich das 1024 da es 10 Bit ist.
Rafael B. schrieb: > # Ermitteln von Messwerte > > import serial > > ser = serial.Serial(port='COM4', baudrate=9600, > bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE) > > x=ord(ser.read()) > y=ord(ser.read()) > > print "X-Achse: %.2f" % float(x/10.0), > print "Y-achse: %.2f" % float(y/10.0), ^ !
RCB schrieb: > ich will doch keine senden. und dies zu umgehen will ich ja eine > Umrechnung machen Du rechnest also den ADC-Wert auf dem uC um in eine Fließkommazahl, multiplizierst diese mit 10 und schickst davon den ganzzahligen Anteil über die serielle Schnittstelle zum PC ?
ohne die Umrechnung schicke ich die Zahl 4 in den PC. also habe ich im C Code die Zahl mal zehn genommen um am PC 49 zu bekommen (am Mikrocontroller werden ganze zahlen gesendet). nun da ich die 49 kriege möchte ich in Photon die 4.9 machen
print "X-Achse: %.2f" % float(x/10.0), print "Y-achse: %.2f" % float(y/10.0), probiers doch endlich aus ;-)
RCB schrieb: > der Wert ansich ist ja richtig Ähm... was ist jetzt dein Problem? Es kommt das richtige am PC an und die zig Mal erwähnte Lösung funktioniert. Kreuz an: [] Ja, danke für die Hilfe. [] Nein, aber ich werde das Problem genauer erläutern. [] Ich weiß auch nicht was ich will. Gruß Dennis
ich kann zurzeit die ersten Lösungsmöglichkeiten nicht ausprobieren weil ich gerade im Zug sitze. Wie oft noch: der Wert ansich ist richtig nur anstatt nur die vier möchte ich noch eine Nachkommastelle haben um einen genaueren Wert zu erhalten. sobald ich kann werde ich die ersten Lösungsvorschläge ausprobieren
RCB schrieb: > Nein ich bekomme ein ASCII zeichen. und mit ord wandle ich dies in einer > Zahl um. im Internet habe ich diesen Befehl gefunden Wenn du ein ASCII-Zeichen bekommst, kann da nicht "49,00" drin stehen.
Rolf M. schrieb: > RCB schrieb: > Nein ich bekomme ein ASCII zeichen. und mit ord wandle ich dies in einer > Zahl um. im Internet habe ich diesen Befehl gefunden > > Wenn du ein ASCII-Zeichen bekommst, kann da nicht "49,00" drin stehen. das gebe ich aus im print
Reinhard M. schrieb: > ok > that's the problem genau das muss die Lösung sein. sobald ich kann probiere ich genau das aus
RCB schrieb: >> Wenn du ein ASCII-Zeichen bekommst, kann da nicht "49,00" drin stehen. > > das gebe ich aus im print Oben hast du aber gesagt, daß die "49,00" über die serielle Schnittstelle kommt. Rafael B. schrieb: > In meinem C-Code sende ich den Wert 49,00 Ein Stück weiter schriebst du, daß du EIN Zeichen bekommst. RCB schrieb: > Nein ich bekomme ein ASCII zeichen. und mit ord wandle ich dies in > einer > Zahl um. im Internet habe ich diesen Befehl gefunden Häng doch am besten mal den C-Code von der Sendeseite an, damit wir wissen, was eigentlich passiert. Bis jetzt ist es nur ein großes Ratespiel mit mehreren unbekannten.
ich habe dann aber auch gesagt dass ich den ASCII Zeichen mit ord um wandle in die 49
Häng doch bitte mal den C-Code, der die Daten über die serielle Schnittstelle sendet, hier an. Danke!
@ rcb nach meinem Endruck, ist das Hauptproblem im Moment, dass Du folgendes noch nicht so genau überblickst: 1. Informationen werden im Computer durch Bitmuster repräsentiert. (Das wirst Du wissen, aber ich wiederhole es der Vollständigkeit halber). 2. Diese Bitmuster werden wiederum "interpretiert". Z.B. als ASCII-Zeichen, als Integer-Zahlen (ganze Zahlen) mit oder ohne Vorzeichen, als Fliesskomma oder Festkommazahlen. 3. In den Programmiersprachen gibt es Wörter, die dem Compiler sagen, wie er ein Bitmuster zu interpretieren hat. In C beispielsweise: char x = 'a'; ein Zeichen int x = -16; eine ganze Zahl mit Vorzeichen unsigned x 5; eine ganze Zahl ohne Vorzeichen float x = 6.7; eine Fliesskommazahl mit Vorzeichen char [3] x = "ab"; eine aus drei Elementen bestehende Folge aus ASCII-Zeichen (einschl. der abschliessenden Null) uswusf. Wie das in python ist, kann ich nicht wirklich kompetent beschreiben. Aber ich meine mich zu erinnern, dass es wie in perl ist. Vielleicht kann das jemand noch kurz direkt dafür beschreiben. Wenn ich mich nicht irre, dann schlussfolgert python den Datentyp aus den Daten selbst und aus den Operationen die darauf angewendet werden. Das kann zu Problemen führen, denn wenn es auch zunächst eine Erleichterung beim Schreiben ist, so muss man sich dennoch bewusst sein, was python da genau macht und was nicht. Was aber in Deinen Fragen und Antworten grundsätzlich fehlt ist eine Angabe, was die Datentypen sind. Da Dir deren Bedeutung selbst nicht bewusst ist, stocherst Du im Nebel und zeigst uns auch nur diesen Nebel. Das führt zu Unklarheiten und Nachfragen. Ich empfehle Dir, nocheinmal Dein Problem neu zu beschreiben und diesmal zu berücksichtigen, was die Datentypen sind: Ich beginne mal mit einer Annahme die an der Quelle anfängt. 4. Du liest 10-Bit-vorzeichenlose Integerzahlen aus dem ADC-Datenregister. Diese rechnest Du in eine andere Zahl um. (Da fängt die Unklarheit an). Ist das Ergebnis nun eine Fliesskommazahl (das ist wahrscheinlich) oder eine Integerzahl mit oder ohne Vorzeichen? Wenn Du damit weiter etwas machst, was sind die Datentypen und warum verwendest Du sie? Wenn Du es schaffst, das konsequent zu beschreiben, könntest Du sogar alleine auf die Ursache Deines Problems kommen. Allerdings ist mir klar, dass das zur Zeit sehr viel verlangt ist. Versuche es aber wenigstens so weit wie möglich und sobald Du auf ein Problem stösst, beschreibe bitte was das Problem ist. Nur so lernst Du etwas, dass Du später wieder benötigst. Noch ein allgemeiner Rat: Es ist immer gut Quellcode zu zeigen. Hole das bitte nach.
só was ist schwer wenn man unterwegs ist und sein Laptop kein internetzugang hat!
RCB schrieb: > só was ist schwer wenn man unterwegs ist und sein Laptop kein > internetzugang hat! Ja. Das ist schwer. Was ich da schrieb ist nicht unnötige Erbsenzählerei, sondern unvermeidbar. Offen gesagt, ist das überhaupt nur eines der Probleme mit Deiner Frage und Du hast da noch einiges zu verbessern, wenn Du es möchtest. Also ist es ohnehin nützlich wenn Du Dir Zeit lässt, Dich in Ruhe und mit allen Codes und nötigen Dingen umgibst und dann erst daran arbeitest. Du hast wohl versucht, mal so nebenbei ein triviales Problem zu lösen. Aber für Dich ist es halt nicht trivial und es benötigt daher viel Aufmerksamkeit. Dann gelingt es Dir sicher auch, vollständige Sätze korrekt zu formulieren (wobei Perfektion hier nicht gefordert ist) und zusammenhängende Darstellungen zu geben. Wir haben Geduld. Schaue Dir das einfach an, sobald Du in Ruhe daran arbeiten kannst.
RCB schrieb: > ich habe dann aber auch gesagt dass ich den ASCII Zeichen mit ord um > wandle in die 49 Das ASCII-Zeichen mit der Nummer 49 ist die '1'. Bist du sicher, dass du hier wirklich ein ASCII-Zeichen meinst und nicht einfach nur ein Byte mit dem Wert 49? Und wieso hast du oben von "49,00" geschrieben? So wie ich verstanden habe, willst du doch das Komma vermeiden durch die Multiplikation mit 10.
So derC-Code ist im Anhang. Ich sende einen Ascii Zeichen, welches den Wert 1023 hat (ADC Wert). Um den Spannungswert rauszukriegen rechne ich es um. Da das Ergebniss 4,9.... ist wollte ich auch eine 4,9 mit meinen Python Programm lesen. Da ich aber keine Kommazahlen sende, wollte ich die Zahl die ich sende mal 10 nehmen damit er die 49 schickt und nicht nur eine 4. In python wollte ich das wieder zurück umrechnen um 4,9 zu bekommen. Die 4.9 entspricht die Spannug an dem ADC
Rolf M. schrieb: > RCB schrieb: >> ich habe dann aber auch gesagt dass ich den ASCII Zeichen mit ord um >> wandle in die 49 > > Das ASCII-Zeichen mit der Nummer 49 ist die '1'. Bist du sicher, dass du > hier wirklich ein ASCII-Zeichen meinst und nicht einfach nur ein Byte > mit dem Wert 49? Und wieso hast du oben von "49,00" geschrieben? So wie > ich verstanden habe, willst du doch das Komma vermeiden durch die > Multiplikation mit 10. das geschieht nach einer umrechnung. siehe c-code
Also ohne die Umrechnng kommt ein ADC wert von 1023 raus. mit der umrechnung die 4,...
Rafael B. schrieb: > So derC-Code ist im Anhang. > > Ich sende einen Ascii Zeichen, welches den Wert 1023 hat (ADC Wert). Du sendest gar keine ASCII-Zeichen. Was du sendest, hat nichts, aber auch gar nichts mit ASCII zu tun. ASCII ist ein Zeichensatz für Text, und du sendest keinen Text. Du sendest also weder ein ASCII-Zeichen mit dem Wert 1023, noch sendest du 49,00 als ASCII. Deshalb sind hier auch einige etwas verwirrt. > In python wollte ich das wieder zurück umrechnen um 4,9 zu bekommen. Die > 4.9 entspricht die Spannug an dem ADC Die Lösung dazu wurde ja oben bereits genannt. Du musst dafür sorgen, dass dein Python auch eine Gleitkomma- und keine Integer-Division durchführt.
das habe ich auch ausprobiert und hingekommen. wenn es keine ASCII Symbole sind dann sind es irgendwelche Symbole xd
RCB schrieb: > das habe ich auch ausprobiert und hingekommen. wenn es keine ASCII > Symbole sind dann sind es irgendwelche Symbole xd Schön. Aber das liegt daran, dass Du in Deinem Code keine konsistente Interpretation der Daten beschreibst. Das habe ich aber oben schon gesagt. Z.B. ist 1023 kein ASCII-Zeichen und ist nicht einmal die Ordinalzahl eines ASCII-Zeichens. Die kann nämlich höchstens 255 sein. Aber das ist Grundlagenwissen und unter dem Stichwort "ASCII" wirklich einfach zu finden. Du kommst einfach nicht darum herum, Dir darüber einmal ausführliche Gedanken zu machen, sie zu dokumentieren und mit der Sprachdefinition in Beziehung zu setzen und daraus Folgerungen zu ziehen. Stattdessen beharrst Du weiter darauf: "Es geht nicht" zu schreiben und das führt Dich nirgendwohin. Letztlich wird sich vielleicht einer hier erbarmen und das für Dich schreiben, aber was würdest Du daraus lernen? Nichts!
wenn du der meinung bist das ich darauf beharrt habe: "es geht nicht" dann muss ich dich wiedersprechen. natürlich kann ich mir darüber gedanken machen, aber zum x-ten mal: ICH WAR UNTERWEGS UND DAS DANN ZU VERFOLGEN IST NICHT EINFACH!!!! dann kann ich nicht verstehen wie die leute immer wieder was zum code fragen oder so und ich ausdrücklich gesagt habe ich bin untergwegs. dann ist es nicht einfach die fragen zu beantworten. Diese VERWIRRUNG wäre nicht passieren, wenn man bemerkt hätte, dass zu beginn schon die Antwort geschrieben wurde! und mit dem ascii zeichen habe ich mich vertan. ich hatte vergessen das diese bis 255 geht. aber wie gesagt schon zu begonn wurde die antwort geschrieben
> Stattdessen beharrst Du weiter darauf: "Es geht nicht" zu schreiben und > das führt Dich nirgendwohin. Letztlich wird sich vielleicht einer hier > erbarmen und das für Dich schreiben, aber was würdest Du daraus lernen? > Nichts! ich verstehe deine logik nicht. ich war unterwegs, wie konnte ich das dann ausprobieren? sehr logisch von dir. ah ok gut zu wissen: kurz die information zu bekommen wie man genau mit python dividiert ist sehr schlimm. und das nennst du jetzt die anderen die arbeit machen lassen? ich kann nur lachen
Rafael B. schrieb: > und mit dem ascii zeichen habe ich mich vertan. ich hatte vergessen das > diese bis 255 geht. ASCII geht sogar nur bis 127. RCB schrieb: > das habe ich auch ausprobiert und hingekommen. wenn es keine ASCII > Symbole sind dann sind es irgendwelche Symbole xd Nein, es sind gar keine Symbole. Es sind einfach nur Werte.
Rolf M. schrieb: > Rafael B. schrieb: >> und mit dem ascii zeichen habe ich mich vertan. ich hatte vergessen das >> diese bis 255 geht. > > ASCII geht sogar nur bis 127. Richtig. Mein Fehler. Allerdings für das Wesen der Frage nicht entscheidend, oder? Und auf einem PC wird er wohl schon Codepage 850 oder sowas installiert haben. Aber richtig: Formal ist oberhalb von 127 kein ASCII mehr. > RCB schrieb: >> das habe ich auch ausprobiert und hingekommen. wenn es keine ASCII >> Symbole sind dann sind es irgendwelche Symbole xd > > Nein, es sind gar keine Symbole. Es sind einfach nur Werte. Na, wenn wir denn schon klugscheissen :-), dann sieht er schon Symbole und keine Werte. Werte sind das Ergebnis einer Interpretation. Aber das spielt natürlich auch keine Rolle.
Staubfänger schrieb: > Rolf M. schrieb: >> Rafael B. schrieb: >>> und mit dem ascii zeichen habe ich mich vertan. ich hatte vergessen das >>> diese bis 255 geht. >> >> ASCII geht sogar nur bis 127. > > Richtig. Mein Fehler. Allerdings für das Wesen der Frage nicht > entscheidend, oder? Entscheidend ist, dass es sich gar nicht um Text handelt und damit sowohl ASCII, als auch sonst irgendein Zeichensatz überhaupt nicht relevant ist. Der TE spricht trotzdem dauernd von ASCII, und das hat hier zu Verwirrung geführt. Ich habe nur versucht, ihm diesen Sachverhalt zu erklären.
Rolf M. schrieb: > Staubfänger schrieb: >> Rolf M. schrieb: >>> Rafael B. schrieb: >>>> und mit dem ascii zeichen habe ich mich vertan. ich hatte vergessen das >>>> diese bis 255 geht. >>> >>> ASCII geht sogar nur bis 127. >> >> Richtig. Mein Fehler. Allerdings für das Wesen der Frage nicht >> entscheidend, oder? > > Entscheidend ist, dass es sich gar nicht um Text handelt und damit > sowohl ASCII, als auch sonst irgendein Zeichensatz überhaupt nicht > relevant ist. Da stimme ich Dir zu. Danach habe ich auch nicht gefragt, sondern danach, ob die Information das ASCII nicht 255 sondern 126 Zeichen umfasst, wesentlich ist. Verstehe mich bitte recht. Aber das Du so genau sein willst, reizt doch meine Erbsenzählerseite, wenn Du auf eine nicht-gestellte Frage antwortest, auf die gestellte Frage aber nicht. Nichts für ungut. :-)
Staubfänger schrieb: >> Entscheidend ist, dass es sich gar nicht um Text handelt und damit >> sowohl ASCII, als auch sonst irgendein Zeichensatz überhaupt nicht >> relevant ist. > > Da stimme ich Dir zu. Danach habe ich auch nicht gefragt, sondern > danach, ob die Information das ASCII nicht 255 sondern 126 Zeichen > umfasst, wesentlich ist. Du hattest geschrieben, dass ASCI bis 255 ginge und nicht bis 1023. Das war schon genauso wenig relevant wie meine Korrektur dieser Aussage. Warum fragst du dann auf einmal mich nach der Relevanz? Ich wollte es nur richtig stellen, sonst nichts. Auch wenn eine Antwort eigentlich nicht für die Frage relevant ist, finde ich es sinnvoll, sie zu korrigieren, wenn sie falsch ist. Also, zurück an dich: Warum hältst du den Wertebereich von ASCII für relevant für die Frage?
Rolf M. schrieb: > Staubfänger schrieb: >>> [...] >> >> Da stimme ich [...] > > Du hattest geschrieben, dass ASCI bis 255 ginge und nicht bis 1023. Das > war schon genauso wenig relevant wie meine Korrektur dieser Aussage. > Warum fragst du dann auf einmal mich nach der Relevanz? Ich wollte es > nur richtig stellen, sonst nichts. Auch wenn eine Antwort eigentlich > nicht für die Frage relevant ist, finde ich es sinnvoll, sie zu > korrigieren, wenn sie falsch ist. > Also, zurück an dich: Warum hältst du den Wertebereich von ASCII für > relevant für die Frage? Der ursprüngliche Einwand war in dem Moment meiner Meinung nach deswegen als Beispiel einer der Eigenschaften für die fehlerhafte Interpretation der Daten relevant; weil er auf den Unterschied zwischen den Wertebereichen hinwies, nicht eigentlich weil die Grenze 255 oder 127 ist. Mich hat die Korrektur von Dir getriggert, weil ich mich wunderte, wozu Du das schreibst, wo ich doch was anderes mitteilen wollte. Ich erkenne allerdings jetzt, dass mein Beispiel ungünstig gewählt war, weil der für den TO wesentliche Unterschied vielmehr in der Interpretation der Daten liegt und der Wertebereich für sich genommen lediglich einen quantitativen Widerspruch bedeutet, der dem TO nicht unbedingt etwas sagen muss. Da war ich schlampig, beim schreiben. OK. Ich danke Dir, dass Du geantwortet hast. War lehrreich für mich.
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.