pySerial: wieso ein sleep nach flush?

[Mehmet K. (mkmk)]

Servus allerseits

Um endlich mit Python etwas weiterzukommen habe ich mich dazu 
entschlossen, von nun an alle meine Test damit auszuführen.

z.Zt. arbeite mit einer STM32F407 Hardware, die von der UART Befehle 
entgegennimmt und dies und jenes macht.
Solange diese Befehle von HTerm eintreffen, werden sie korrekt 
ausgeführt.

Dieselben Befehle gesendet von Python werden nur dann korrekt erkannt, 
wenn sie max. 4 - 6 Bytes lang sind. Laengere Befehle kommen nur dann 
korrekt an, wenn ich zwischen flush() und close() ein sleep(.5) einfüge.

- Python3.3 (dasselbe Problem mit Python 2.7.5)
- PySerial 2.7
- Windows 7 64bit
- USB-ComPort
- Baudrate 115200 (9600 aendert nichts)

Das Setzen des Send-FIFO auf 1 Byte hat nichts gebracht.
Und wie bereits erwaehnt: mit HTerm keinerlei Probleme.

Kann mir jemand sagen, wieso ich nach flush() noch ein sleep() benötige? 
Hat flush() nicht die Aufgabe zu warten, bis alle Zeichen gesendet sind?

MfG
Mehmet

[Kaj (Gast)]

Mehmet Kendi schrieb:
> von nun an alle meine Test damit auszuführen.
Gute Entscheidung!

Mehmet Kendi schrieb:
> - Windows 7 64bit
Ich weiß nicht wie es bei den STM32-Boards ist, aber bei einem 
Arduino-Board (mit Bootloader, weiß nicht wie es ist, wenn der 
Bootloader gelöscht wurde) wird der µC immer beim öffnen des COM-Ports 
automatisch resetet, unter Linux muss man den reset im Python-Script von 
Hand durchführen. Man muss also nach dem Öffnen des COM-Ports mind. 
warten bis der Bootloader fertig ist. Das aber nur so als kleiner 
Hinweis!

Mehmet Kendi schrieb:
> Dieselben Befehle gesendet von Python werden nur dann korrekt erkannt,
> wenn sie max. 4 - 6 Bytes lang sind. Laengere Befehle kommen nur dann
> korrekt an, wenn ich zwischen flush() und close() ein sleep(.5) einfüge.
Was für Befehle sind das denn, also wie sind die Wertebereiche der 
einzelnen Bytes? Du musst beim Senden auf die richtige Codierung der 
Bytes achten, sonst kann es (und wird es auch) passieren das, wenn du 
ein Byte mit einem Wert >127 senden möchtest, der PC nicht ein Byte, 
sondern zwei Byte sendet. Ich glaube wenn du keine Codierung angiebst, 
benutzt Python ab einem bestimmten Wertebereich UTF-8 codierung. (siehe 
dazu wikipedia: utf-8; http://de.wikipedia.org/wiki/Utf-8#Kodierung)

Mehmet Kendi schrieb:
> Hat flush() nicht die Aufgabe zu warten, bis alle Zeichen gesendet sind?
Laut pyserial-Doku, sollte flush solange warten, ja.

Mehmet Kendi schrieb:
> Und wie bereits erwaehnt: mit HTerm keinerlei Probleme.
das ist aber auch ein ziemlich ausgereiftes Terminal-Programm, und kein 
einfaches Python-Script :)

Mehmet Kendi schrieb:
> Kann mir jemand sagen, wieso ich nach flush() noch ein sleep() benötige?
Poste doch mal bitte dein Python-Script (am besten als Anhang), 
vielleicht ist da noch was im Code nicht ganz richtig. Ohne 
irgendwelchen Code zu sehen ist helfen immer schwer ;)

Grüße

[Mehmet K. (mkmk)]

Kaj schrieb:
> Du musst beim Senden auf die richtige Codierung der
> Bytes achten

Yep, bis ich das raus hatte, hat's a bisl gedauert :)

Kaj schrieb:
> Ohne irgendwelchen Code zu sehen ist helfen immer schwer

Der Kod funktioniert ja. Aber nur, wenn ich zwischen flush() und close() 
eine Gedenkminute einlege.
Ich wollte nur wissen, wieso das so ist.

Edit:
Da das Ganze aus mehreren Modulen besteht, waere ein Zeigen des Codes 
etwas umsaendlich.
Ich habe mal ein einfaches Beispiel auf 2 Dateien zusammengefasst.

[Detlef K. (adenin)]

Nach flush() ein os.fsync() ausführen sollte das Problem lösen.
Warum das so ist, steht ind er Pytondoku.

[Mehmet K. (mkmk)]

fsync braucht doch einen file descriptor.
Den habe ich aber hier nicht.
Müsste ja dann den ganzen Bettel umschreiben und die COM mit os.open 
öffnen.

[Mehmet K. (mkmk)]

Also das mit dem sleep hat sich erledigt.
Aber leider habe ich nicht die geringste Ahnung, wieso es jetzt ohne 
geht.

Für alle, die ihre Geraete mit dem PC testen: es lohnt sich wirklich auf 
Python einen Blick zu werfen.
Der Umstieg von C auf Python3 war nicht ganz so einfach.
Unicode, Byte & Co. gaben mir oft Anlass dazu, mich am Kopf zu kratzen.
Aber sobald man das mal durch hat, macht es geradezu Spass die 
Testszenarien zu programmieren.