ausgeben von Kommazahlen

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 :(

ich soll das ja umgehen in dem ich den Wert im Mikrocontroller mal 10 
nehme und dann im PC durch 10 nehme

Bei 49/10 macht Python eine Ganzzahldivision.
Probiere mal 49.0/10.0

ich benutze 2.7. also 4/3 in deinem Beispiel geht bei mir nicht?

Du muss wirklich 49.00/10 rechnen, nicht 49/10.
Dann gehts!

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

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...

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),

                                   ^
                                   !

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 ;-)

der Wert ansich ist ja richtig

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

ok
that's the problem

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.

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,...

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

Nun, ich kann Dir anscheinend nicht helfen.

Viel Erfolg noch.

logik pur

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.

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. :-)

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.