Serial.print timing

[F. G. (no_pilot)]

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

}

[Stefan P. (form)]

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.

[Niklas G. (erlkoenig)]

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.

[Benjamin S. (recycler)]

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?

[Stefan F. (Gast)]

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

[Jim M. (turboj)]

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.

[Niklas G. (erlkoenig)]

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.