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
> habe meine uart schnittstelle auf der maximum Baudrate eingestellt Die Schnittstelle vom PC? > weisst jemand, an was das liegt An Windows?
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
ich habe vergessen euch zusagen, dass ich die daten (file daten) mit kermit protokol sende.. sagt euch was??
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.
1 | 2.3 UART |
2 | 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
> 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 --> USB --> PC #2 mit Terminal-SW |
Und wenn du jetzt eine Datei vom PC #1 zum PC #2 via Kermit sendest, dann hast du auf der Empfängerseite kurze Pausen?
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!
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.