Ich habe einen XBee in einen Raspberry PI gesteckt. Hier ist der Python 3.4-Code, den ich verwende:Python os.read blockt bis zum Newline-Zeichen
f = os.open("/dev/ttyUSB0", os.O_RDWR | os.O_NONBLOCK)
print("Writing...")
b = bytes("hello","utf-8")
os.write(f,b)
print("Press return to start read")
cmd = input()
print("Reading...")
ret = os.read(f,10)
if ret == None:
print("ret = None")
else:
print("ret = {}".format(ret))
os.close(f)
Gestern hat das alles funktioniert, wie ich erwartet hatte. Der Lesebefehl wurde sofort mit Null Bytes zurückgegeben, wenn nichts zu lesen war.
Heute habe ich Code zu einem anderen Teil des Projekts hinzugefügt, das in eine Textdatei schreibt und einen Thread RLock enthält. Jetzt macht der obige Code etwas anderes. Wenn es wartet kein Bytes gelesen zu werden, oder es wartet Bytes gelesen werden, aber sie nicht mit einem 0x0D beenden, bekomme ich einen Fehler:
BlockingIOError: [Errno 11] Resource temporarily unavailable
Aber bin gibt es Warte Bytes gelesen zu werden, dass Ende mit einem 0x0D, die Lesefunktion gibt diese Bytes einschließlich der 0x0D zurück.
Update: Ich habe das System neu formatiert, und der Fehler ist nicht verschwunden, was darauf hindeutet, dass es nicht das Hinzufügen des Datei- und Thread-Sperrcodes war, der das Problem verursachte.
Ich lief minicom und das Problem ist weg, also sollte ich etwas mit der seriellen Konfiguration auf dem Gerät tun, bevor ich es als Datei öffne?
Das ist die Linie, die die os.read auf ihr ursprüngliches Verhalten zurück:
Minicom -b 9600 -o -D/dev/ttyUSB0
Können Sie den Code hinzufügen, der die Sperre hinzufügt? Das Newline-Ding klingt irgendwie wie das Lesen gepuffert wird (ich weiß, dass ein normales dateiähnliches Objekt als Iterator das Warten auf den Newline oder EOF blockiert), aber afaik 'os.open' gibt ein ungepuffertes Dateihandle zurück –
Danke für die Antwort. Ich habe meine Frage mit dem Sperrcode aktualisiert. –
Schließen Sie den Griff für die serielle Schnittstelle, lesen Sie aber trotzdem davon? Wenn dies der Fall ist, ist es möglich, dass das zugrunde liegende Dateihandle für Ihre Datei "trace.txt" mit dem für den USB-Anschluss übereinstimmt. Unix-Betriebssysteme weisen Dateihandles in aufsteigender Reihenfolge zu und verwenden Griffe erneut. Probieren Sie das aus und sehen Sie selbst: https://gist.github.com/jszakmeister/e18607a026749956f0bd7a30cd148fa6 – jszakmeister