hallo zusammen,
ich habe meine uart schnittstelle auf der maximum Baudrate eingestellt,
aber das problem, wenn ich daten senden will, macht sie öfters pause.
weisst jemand, an was das liegt
danke
hallo
ich habe eine hardware am pc angeschlossen, und wenn ich daten mit hohe
Baudrate senden will, geht das nicht, wie ich erwartet habe, das macht
stängig pause.
ob an windows liegt ich weiss es nicht, aber wenn du es so meist, wie
kann es passieren ??
danke
Hat die UART einen Puffer? Schickst du vom Programm aus schneller Daten
in den Puffer rein, als sie von der UART aus dem Puffer entnommen und
auf die Reise geschickt werden? Wartet die "UART-Befüllfunktion" bis
genug Platz im Puffer ist, um neue Daten aufzunehmen und entsteht
dadurch eine Wartezeit? Haben die UART am PC und die UART an deiner
"Hardware" eine Handshake-Funktion (Siehe RS232 Flußsteuerung)?
> und wenn ich daten mit hohe Baudrate senden will
Von wo nach wo?
Vom PC zu deiner Hardware?
> ob an windows liegt ich weiss es nicht
Beweg während der Übertragung mal ein Windows-Fenster.
Ruckelt es dann mehr?
> wie kann es passieren ??
Das Programm kommt nicht mit dem Befüllen des UARTs nach.
BTW: Ist dieser UART an einer USB-Schnittstelle angeschlossen?
hallo,
es gibt einpaar einstellung im datasheet die ich machen musste , ich
habe flowcontrol aktiviert aber was mit puffer zutun hat, habe ich
bessschen zweifen, da ich nich genau weiss was ich einstellen soll:
- UART Receiver, RTS/CTS Hardware Flow Control
The UART receive buffer is approx. 1024 bytes, and at lower baudrates
(9600, 19200) the system
can process data into the device without need for flow control.
If constant streaming of data into RX on the device is required, care
should be taken to set the
comm parameters to optimize the performance. If data has a termination
char, this can be used.
Also, if data has a particular frame size, this can be used.
set comm match <value> sets the value of the packet terminator.
set comm size <value> sets the number of bytes to receive before
forwarding
0-1 forwards immediately. maximum value = 1460 bytes.
The comm size is automatically set whenever the baudrate is set, but can
be modified.
Even at higher baudrates (115K and higher ) it is possible to operate
without flow control if packets
are uniform and a protocol is used to ensure that data is delivered on
the remote side before the
next packet is sent
Eine aktivierte Flow Control springt an, wenn der UART receive buffer
voll wird. Der Empfänger meldet das Vollwerden dem Sender denn der
Sender soll bis auf weiteres keine Daten mehr schicken. Ist wieder Platz
im UART receive buffer wird das Senden wieder frei gegeben. Auf der
Senderseite sieht das wie eine Pause aus.
Laut deinem Datenblatt ist der UART Receiver in der Lage bei lower
baudrates (9600, 19200) die Daten schnell genug aus dem UART receive
buffer weiterzuverarbeiten, denn es ist da kein Flow Control nötig. Bei
Verzögerungen und Pausen würde ich auf der Senderseite forschen.
Bei höheren Baudraten muss man die Kommunikationsparameter optimal
einstellen um beste Performance zu haben. Verschiedene Möglichkeiten
sind aufgeführt.
Unabhängig davon kann es auch auf der Senderseite Probleme geben. Auch
beim Befüllen des Senderpuffers aus dem Sendeprogramm heraus kann es zu
Überfüllung kommen. In diesem Fall setzt eine andere Art Flow Control
zwischen deinem Senderprogramm bzw. dessen Programmlibraries und der
Sender-UART ein - die Library kann z.B. warten bis der Sendepuffer Platz
für weitere Zeichen hat. Auch das äussert sich als Pause auf der
Senderseite
Das ist ein trübes Stochern im Nebel, was hier los ist...
Du sendest also vom PC über einen USB-UART an deine Hardware. Richtig?
Diese Übertragung wird durch kurze Pausen unterbrochen. Richtig?
Gib doch mal noch mehr Informationen:
Was ist deine Hardware?
Welche Baudrate?
Wie stellst du fest, dass die Übertragung stockt?
Wie lange stockt die Übertragung?
Verwendest du überhaupt die Flusskontrolle (RTS, CTS, DSR...)?
Oder nur RXD und TXD?
Lothar Miller schrieb:
> Das ist ein trübes Stochern im Nebel, was hier los ist...>> Du sendest also vom PC über einen USB-UART an deine Hardware. Richtig?> Diese Übertragung wird durch kurze Pausen unterbrochen. Richtig?
rechtig
>> Gib doch mal noch mehr Informationen:> Was ist deine Hardware?
wlan modul http://www.rovingnetworks.com/documents/WiFlyGSX-um.pdf> Welche Baudrate?
ich verwende jetzt die maximal baud rate 921600
> Wie stellst du fest, dass die Übertragung stockt?
durch LED und ein program (tera Term ), der mir gie übertragungszeigt
> Wie lange stockt die Übertragung?
unterschiedlich
> Verwendest du überhaupt die Flusskontrolle (RTS, CTS, DSR...)?> Oder nur RXD und TXD?
am anfang nur RXD und TXD und jetzt flow kontrolle aber brigst mir
nichts.
ich sende die daten mit einem protokol der kermit heisst.
Connect a common ground when using the external TX, RX inputs.
3
4
For a 3 wire DB-9 interface (connect tx, rx, gnd only)
5
6
Factory default is hardware flow control disabled, CTS and RTS are not required.
Hast du die CTS und RTS Pins angeschlossen?
Am besten zeichnest du mal eine Skizze, wo man alle beteiligten
Komponenten und die angeschlossenen Leitungen sieht. Vielleicht hilft
das weiter...
> Hast du die CTS und RTS Pins angeschlossen?
mit was soll ich die anschliessen?? ich arbeite mit usb-schnittstelle
>> Am besten zeichnest du mal eine Skizze, wo man alle beteiligten> Komponenten und die angeschlossenen Leitungen sieht. Vielleicht hilft> das weiter...
alle beteiligten sind hier:
http://www.rovingnetworks.com/documents/rn-134-ds.pdf
damit das problem wird klar: ich sende von diesem wlan modul zum anderem
textdaten und das funktioniert schon aber nur die pause was mich nervt
Lothar Miller schrieb:
>> alle beteiligten sind hier: ...> Das ist also nur 1 Komponente :-o>> Ohne Witz, wenn ich raten kann sieht dein Aufbau so aus:>
1
> PC #1 mit Terminal-SW --> USB --> RS232 --> WLAN -----> WLAN --> RS232
2
> --> USB --> PC #2 mit Terminal-SW
3
rechtig 1,0 :-)
4
>
> Und wenn du jetzt eine Datei vom PC #1 zum PC #2 via Kermit sendest,> dann hast du auf der Empfängerseite kurze Pausen?
das ist so: wenn ich daten sende: also von pc1 zum pc 2 blinkt eine
rote LED in meinem evaluation board dh die daten werden gesendet zum
wlan modul 1 durch usb--> rs232 ( wir sind immer nur beib pc 1 ).Wenn
das wlan module 1 daten weiter leiten im luft :also wlan 1---> wlan2
blinkt eine orengene LED in beiden module dh wlan 1 sendet und wlan 2
empfängt.
aber das problem denke ich mal ist zwichen usb und uart.
Darf ich mal etwas anderes fragen:
Wieso ist das jetzt ein Problem, wwenn du kurzzeitige Aussetzer hast?
Ich meine: Du hast in deiner Übertragungskette so viele paketorientierte
Übertragungsstrecken drinnen, dass es eigentlich ein Wunder wäre, wenn
da nicht kurzzeitig die Übertragung stockt.
Wenn du so etwas aufbaust, dann musst du IMHO damit rechnen, dass die
Übertragung immer wieder mal kurzzeitig stockt und deine Programme so
aufbauen, dass sie damit zurecht kommen -> FIFO Queues, die die
Zwischenräume auffüllen.
Karl heinz Buchegger schrieb:
> Darf ich mal etwas anderes fragen:
natürlich :-)
> Wieso ist das jetzt ein Problem, wwenn du kurzzeitige Aussetzer hast?>> Ich meine: Du hast in deiner Übertragungskette so viele paketorientierte> Übertragungsstrecken drinnen, dass es eigentlich ein Wunder wäre, wenn> da nicht kurzzeitig die Übertragung stockt.> ja schon aber nicht bei 4 Bytes und bei baudrate von 921600> Wenn du so etwas aufbaust, dann musst du IMHO damit rechnen, dass die> Übertragung immer wieder mal kurzzeitig stockt und deine Programme so> aufbauen, dass sie damit zurecht kommen -> FIFO Queues, die die> Zwischenräume auffüllen.
du hast schon recht aber es konnte sein, dass ich irgenwas nicht rechtig
verstanden habe wo ich datasheet gelesen habe.
> aber das problem denke ich mal ist zwichen usb und uart.
Wie Karl heinz Buchegger schon beschrieben hat, kann das Problem an
jeder der beteiligten Schnittstellen auftauchen. Schon beim Transfer vom
Terminalprogramm im PC #1 zum USB-Treiber kann es ruckeln, und das wird
mit jedem Teilnehmer nur noch schlimmer...
Schade eigentlich nur, dass das jetzt 3 1/2 Stunden gedauert hat, das
rauszufinden, was schon ganz zu Anfang mein Verdacht war... :-/
Und dann bleibt es bei der Frage:
>> Wieso ist das jetzt ein Problem, wenn du kurzzeitige Aussetzer hast?
hallo
> Schade eigentlich nur, dass das jetzt 3 1/2 Stunden gedauert hat, das> rauszufinden, was schon ganz zu Anfang mein Verdacht war... :-/
do hast schon recht aber es konnte, dass ich irgenwas falsch
eingestellt, was ich nicht verstanden habe
guten morgen zusammen,
ich habe die baud rate runtergesetzt und getzt funktioniert
besser.Anstatt 921600 MBit/s habe ich 11500 MBit/s eingestellt, hat
jemand von euch eine Erklärung, warum pause bei 921600Mbit/s gab
ich danke euch
Faycal Miftah schrieb:
>> Ich meine: Du hast in deiner Übertragungskette so viele paketorientierte>> Übertragungsstrecken drinnen, dass es eigentlich ein Wunder wäre, wenn>> da nicht kurzzeitig die Übertragung stockt.> ja schon aber nicht bei 4 Bytes und bei baudrate von 921600
Doch. Gerade bei 4 Bytes darfst du dich nicht wundern.
Dir scheint nicht klar zu sein, was paketorientierte Verbindung bedeutet
und wie so etwas realisiert wird.
> ich habe die baud rate runtergesetzt und getzt funktioniert> besser.Anstatt 921600 MBit/s habe ich 11500 MBit/s eingestellt, hat> jemand von euch eine Erklärung, warum pause bei 921600Mbit/s gab> ich danke euch
Du überträgst 4 Bytes, was schon mal schlecht für eine paketorientierte
Verbindung ist, da viel zu kurz.
Nun gehen die Pakethandler aber nicht her und bauen aus jedem
dahergelaufenen Byte ein neues Paket zusammen und schicken das auf die
Reise, sondern sie haben Algorithmen, die im Prinzip erst eine zeitlang
warten ob noch weitere Bytes daherkommen, die sie in das Paket
integrieren können (Für TCP/IP siehe zb der Nagle Algorithmus).
Kommen die Bytes jetzt etwas langsamer daher, kann es natürlich sein,
dass sich das alles zeitlich besser ausgeht und die Bytes als
Einzelpakete bzw. als kleinere Pakete auf die Reise geschickt werden.
Genau wird man dem nur mit teurem Messequipment auf die Schliche kommen
können, wenn überhaupt.
Ist aber im Grunde sinnlos, denn eine Einstellung die heute
funktioniert, kann morgen schon wieder die gleichen Probleme aufwerfen.
Einfach deshalb weil die Netzlast insgesamt zb höher oder niedriger ist,
du zb bei TCP/IP mehr Hops zwischen den Teilnehmern hast, die
Funkverbindung schlechter ist, etc. Sprich deine, von dir nicht
beeinflussbare, Umgebung spielt da mit rein.
Und nochmal: Wenn deine Programme mit derartigen kurzen Aussetzern eines
kontinuierlichen Datenstroms nicht klarkommen, dann musst du daran
arbeiten, das abzustellen. Deine Verbindungskette ist von der Art, dass
du immer damit rechnen musst, das solche Dinge passieren. Solange du auf
dieser Verbindungskette bleiben musst, werden solche Dinge passieren!
