Hallo zusammen, ich versuche die reale Zeitdauer zur Seriellen UART-USB Übertragung zu ermitteln. Zwischen einem Arduino Uno (ATMega328P) und Win7. Dazu habe ich mir unten angehängte Testfunktion geschrieben. Den Pin Status schaue ich mir mit dem Oskar an. Erwarten würde ich einen linearen Anstieg der Zeitdauer pro gesendetem Zeichen - Dies ist aber nicht der Fall! Könnte mir jemand auf die Sprünge helfen, warum das so auftritt?? Die Baudrate ist auf 19200 eingestellt. Das Phänoment tritt aber auch bei anderen Geschwindigkeiten auf. Danke für Euer Input! Felix --- EDIT: Der gelbe Verlauf stellt den Status von "test_pin" dar! --- void FunktionSerialPrint() { for (int k=0;k<25;k++) { digitalWrite(test_pin,HIGH); for(int j=(25-k);j<20;j++) { Serial.print("O"); } Serial.println(""); digitalWrite(test_pin,LOW); delay(2); } }
:
Bearbeitet durch User
Merkwürdig. Häng doch mal zusätzlich noch den Kanal 2 an den UART-TX - vielleicht sieht man dann was los ist. Am besten dann als PNG anhängen.
Felix G. schrieb: > Erwarten würde ich einen linearen Anstieg der Zeitdauer pro gesendetem > Zeichen - Dies ist aber nicht der Fall! Könnte mir jemand auf die > Sprünge helfen, warum das so auftritt?? Weil Serial.print in einen Puffer schreibt. Die ersten Bytes füllen den Puffer - das geht quasi "instant" - und sobald er voll ist, wird gewartet bis ein Platz im Puffer durch die Übertragung frei wurde. Der USB-Adapter fügt aber weitere Verzögerungen hinzu. Darüber ist quasi keine echtzeitfähige Übertragung zu erreichen. Wenn du das Timing genau steuern willst, müsstest du ein eigenes USB-Gerät implementieren und z.B. Isochrone Transfers nutzen.
versendest du die Zeichen über USB (also ist der ATMEGA über USB verbunden) und das Protokoll ist RS232 oder hast du einen UART2USB Konverter dran?
> Die Baudrate ist auf 19200 eingestellt. > Das Phänomen tritt aber auch bei anderen Geschwindigkeiten auf. Ich finde, dass 19200 Baud ganz gewöhnlich sind, also eher kein Phänomen. > ich versuche die reale Zeitdauer zur Seriellen UART-USB Übertragung > zu ermitteln Das ist doch ganz einfach. Da die Schnittstelle mit Puffer sendet, kann sie die Zeichen lückenlos nacheinander senden. Jedes Zeichen umfasst ein Start-Bit, 8 Daten-Bits und ein Stop-Bit. Die Schnittstelle sendet also 1920 Zeichen pro Sekunde - es sei denn, du sperrst Interrupts für ungewöhnlich lange Zeit oder fügst absichtlich Verzögerungen ein. Ich nehme mal an, dass die gelbe Linie das Signal von deinem "test_pin" darstellt. Das Signal geht anfangs nur sehr kurz auf High, weil der Sendepuffer Platz frei hat. Sobald er voll ist, wartet die Funktion Serial.print() darauf, dass Platz frei wird. Und das dauert genau so lange, wie die Übertragung eines Zeichens dauert.
Niklas G. schrieb: > USB-Adapter fügt aber weitere Verzögerungen hinzu. Aber nicht auf der µC Seite. Der 328P hat AFAIK keine Datenflusskontrolle, und bei 19200 Baud ist die dank groszügiger FIFOs im USB2UART auch nicht notwendig.
Jim M. schrieb: > Aber nicht auf der µC Seite. Stimmt. Aber wenn eine Übertragung echtzeitfähig sein soll impliziert das meistens auch die Gegenstelle :) Wenn es nur darum geht, wie lange der Controller damit beschäftigt ist, gibt's eh bessere Lösungen als Busy Waiting - z.B. Interrupts und FIFO's (und DMA bei Controllern die es können), dann ist die Zeit pro Byte immer minimal. Jim M. schrieb: > und bei 19200 Baud ist die dank groszügiger FIFOs > im USB2UART auch nicht notwendig. Ja. Aber wenn man möchte dass Datenpakete innerhalb einer bestimmten Zeit am PC ankommen bzw. man eine Antwort erhält, wird das mit so einem Adapter schwierig, wenn die Zeit nicht "lang" ist.
:
Bearbeitet durch User
Bitte 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.