Minimale Verzögerung für die serielle Kommunikation mit Python

Ich habe ein einfaches Python-Skript für die Kommunikation mit einem Mikrocontroller (STM32F103C8T6) über den seriellen Port. Ich verwende pySerial, um ein paar 44-Byte-Nachrichten gleichzeitig zu schreiben.Minimale Verzögerung für die serielle Kommunikation mit Python

[...] 
serial = serial.Serial(serial.tools.list_ports.comports()[0].device, 115200) 

packet0 = bytearray(INSERT_RELEVANT_44-BYTES) 
packet1 = bytearray(INSERT_RELEVANT_44-BYTES) 
serial.write(packet0) 

time.sleep(0.1) # Delay between communications 

serial.write(packet1) 
[...]

Ich musste eine Verzögerung zwischen den Kommunikationen einfügen, sonst würde es nicht funktionieren. Meine Argumentation ist, dass für eine Baudrate von 115200 bps die Nachrichten 44 * 8/115200 = ~ 0,003 Sekunden gesendet werden sollten, daher sollte dies das minimale ideale Intervall zwischen dem Senden der Pakete sein. Der Code funktioniert jedoch für nichts kleiner als 0,1.

Warum? Fehle ich etwas? Ich nehme an, dass es wegen des Betriebssystems und des USB etwas Verzögerung gibt, aber es sollte ~ 0,7 Sekunden nicht berücksichtigen. Wie kann ich dies optimieren, um die minimal mögliche Verzögerung zu nutzen?

Quelle

2016-12-03 gabrieljcs

* "Es würde nicht funktionieren" * - Das ist eine Zusammenfassung, die keine Diagnoseinformationen enthält. Ihr * "Argument" * ist etwas aus; es berücksichtigt nicht 2 Bits Framing pro Zeichen. Was lässt Sie denken, dass das Übertragen mit minimaler Verzögerung praktisch ist; d.h. ist der Empfänger in der Lage, eine solche Paketrate zu verarbeiten (zu empfangen und zu verarbeiten)? Berücksichtigen Sie auch die Genauigkeit der Schlaffunktion und des Overheads einer interpretierten Sprache. – sawdust

hängt davon ab, wie Sie den seriellen Port in Stm32 verwenden. Ist es möglich, Code zu teilen, den Sie in stm32 schreiben? – saygins

Sie scheinen nur auf der sendenden Seite nach der Ursache zu suchen. Es gibt den Absender, der Zeichen verlieren könnte, und der Empfänger (In Ihrem Fall haben Sie offenbar einen USB-zu-Seriell-Adapter, der auch Zeichen verlieren könnte). Ohne weitere Diagnose auf * wo * das Problem liegt, können wir wahrscheinlich nicht helfen. – tofro

Vielmehr dann eine nominale Verzögerung auf dem UART Link basierend Berechnung Sie einfach den seriellen Treiber abfragen könnte, um zu bestimmen, ob der Tx-Puffer leer ist:

serial.write(packet0) 
while serial.outWaiting() > 0 : 
    pass 
serial.write(packet1)

Dies hat den Vorteil der Buchhaltung automatisch für jede Latenz hat, Software-Overhead- und Puffer-Beschränkungen überall in der Kette von Anwendungscode, Bibliothek, Treiber, USB-Seriell-Brücke. Es wird jedoch kein Problem mit der seriellen STM32-E/A-Implementierung lösen, Sie sollten wahrscheinlich das Grundproblem ansprechen, warum die Daten nicht gestreamt werden können, was höchstwahrscheinlich auf eine schlechte Implementierung des STM32-Geräteendes zurückzuführen ist.

Quelle

2016-12-03 16:58:35 Clifford

Der USB <> serielle Adapter benötigt immer noch 10 Baud, um jedes Byte auszugeben, genau wie ein herkömmlicher COM-Port, also "kann" (um nicht zu sagen, dass es eine gute Wahl ist) eine minimale Verzögerung berechnen, wahrscheinlich einen Fudge-Faktor für den Overhead hinzufügend . Die Größe des Puffers im USB <> Serial Adapter hat hier keine Auswirkung - völlig irrelevant. – barny

@ Barny: Vielleicht war mein Punkt unklar. Wir wissen nicht, was das eigentliche Problem ist, die Frage ist die Lösung, nicht das Problem.Wenn der Adapter 128 Bit Pufferspeicher hat, können Sie beide Datenblöcke ohne Verzögerung senden, und alle Daten werden aus Sicht des PC weit weniger als die UART-Verbindung vom Adapter zum STM32 übertragen. Der USB-Teil der Verbindung wird eine Flusssteuerung haben, während der UART-Abschnitt dies nicht tun kann. Die Pufferung ist natürlich irrelevant, wenn die Daten gestreamt werden, aber hier tritt der Fehler nach nur zwei 44-Byte-Blöcken auf. – Clifford

Sie sprechen immer noch über Pufferung im USB <> RS232-Gerät, als ob es darauf ankommt. Insbesondere, wenn keine Flusssteuerung vorhanden ist, ist der COM-Port, was den Python-Code betrifft, ein herkömmlicher Port, und Daten werden so schnell übertragen, wie sie aus dem "UART" an das STM32 übertragen werden. Ich nehme an, serielle und Windows werden beide auch puffern. Daher ist die Größe der Puffer in den USB <> RS232 Adaptern völlig irrelevant und eine vollständige Ablenkung in Ihrer "Antwort" – barny

Minimale Verzögerung für die serielle Kommunikation mit Python

Antwort

Verwandte Themen