Forum: Mikrocontroller und Digitale Elektronik uart problem


von Wesam C. (fay79)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> habe meine uart schnittstelle auf der maximum Baudrate eingestellt
Die Schnittstelle vom PC?

> weisst jemand, an was das liegt
An Windows?

von Wesam C. (fay79)


Lesenswert?

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

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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)?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Wesam C. (fay79)


Lesenswert?

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

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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

von Wesam C. (fay79)


Lesenswert?

hallo,
uart ist mit usb angeschlossen.

von Wesam C. (fay79)


Lesenswert?

ich habe vergessen euch zusagen, dass ich die daten (file daten) mit 
kermit protokol sende.. sagt euch was??

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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?

von Wesam C. (fay79)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Wesam C. (fay79)


Lesenswert?

> 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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Wesam C. (fay79)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

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.

von Wesam C. (fay79)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Wesam C. (fay79)


Lesenswert?

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

von Wesam C. (fay79)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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!

von Wesam C. (fay79)


Lesenswert?

vielen dank

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
Noch kein Account? Hier anmelden.