USB/RS232 - welche Limits ?

Pass auf, dass Dir VB die Zugriffe nicht aufspaltet.

Schau mal das Receive Buffer Timeout an..

Wenn alles schnell genug reagiert, braucht man es wohl nicht...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Hi!

Warum fragst Du _uns_ das, wenns _Dein_ Konzept und damit _Deine_ Entscheidung ist? Der FTDI kann mit originalem Treiber auch 115200 und

128000 bit/s. Mit entsprechender Änderung am Treiber (dann sollte man aber ein EEPROM vorsehen, damit der Treiber mit den "verbogenen" Baudraten auch nur die entsprechende Hardware anspricht) geht auch noch deutlich mehr.

Du solltest den µC natürlich mit einem Takt betreiben, der ein Herunterteilen auf die exakte Baudrate zulässt.

Nunja, das ist recht wenig, da schlägt die Latenz schon zu.

Wäre es denn so viel Aufwand, das einfach mal auszuprobieren?

Ja: Geräte-Manager -> Anschlüsse -> USB Serial Port -> Settings ->

Advanced: Latenz runter. Je nach PC hab ich bei 1-4ms die höchste effektive Übertragungsrate.

Ja: Wenn Dir die 128000 nicht reichen, kannst Du dem Treiber auch noch weitere Baudraten unterjubeln:

ab Seite 13.

Nein, das EEPROM dient dazu, mehrere FT232 voneinander zu unterscheiden und mit verschiedenen Treibern ansprechen zu können. Zwingend notwendig ist das nicht.

Ich glaube nicht, daß das den USB-Transfer in irgendeiner Weise beeinflusst.

Gruß, Michael.

"Nicolas Nickisch"

Fragen, insbesondere nachdem ich einen Artikel in einer

Pakete à 16 Byte.

Da liegt der Fehler. RS232 ist für Stücke nicht geeignet, weil der Receiver auf PC-Seite oft nen paar Bytes benötigt, bis der sich überhaupt auf den Datenstrom eingestellt hat.

Also entweder am besten an einem Stück senden oder in den Pausen nur Nullen oder so senden.

Dadurch dass du Handschake benutzt, verkürzt du die Zeit nur erheblich die der Receiver benötigt, um sich auf das Signal einzustellen. deshalb funktioniert das besser. Denn wenn das Signal ohne Handshake in den Rechner reingesendet wird, muss ja nach jedem Datenfragment eine neue zeitliche synchronisation erfolgen. Jetzt wird zwar wieder irgendwer kommen und behaupten, dass dafür ja Start und Stopbit da sind, aber dem ist in der Realität nicht ausschließlich so.

lg,

Markus

Ok, ich werde mal weiter probieren. Ich hatte eigentlich gehofft, irgendjemand kann auf ganz konkrete Aussagen verweisen, aus denen solche Sachen hervorgehen.

Danke erstmal ..

"Makus Gr0n0tte" schrieb im Newsbeitrag news:435dbb0f$0$12675$ snipped-for-privacy@newsread4.arcor-online.net...

Hallo Markus,

Markus Gronotte schrieb:

das Gegenteil ist der Fall. Bei einzelnen Bytes kann ein UART immer das Startbit erkennen und sie korrekt empfangen. Bei nahtlosen Datenfolgen könnte es mehrere Möglichkeiten der Einrastung geben, wenn er erst mitten im Datenstrom initialisiert wird bzw. mit dem Sender verbunden wird.

Der Hardware Handshake hat mit dem Erkennen von Startbits nichts zu tun, er soll ein Überlaufen des Empfangspuffers durch Anhalten der Quelle bewirken.

Ja, hier! ;-)

Doch.

Gruß Ernst

Hi!

Vor allem, da ja nicht festgelegt ist, _wann_ der Handshake kommt, bzw. _wann_ nach dem Handshake die Daten kommen. Wie sollte man sich dann darauf synchronisieren?

Gruß, Michael.

Makus Gr0n0tte schrieb:

Receiver

f den

Nullen

Hallo,

mal wieder das =FCbliche von Gronotte... Der Unterschied zwischen synchroner und asynchroner serieller=20 =DCbertragung ist ihm wohl nicht klar, das oben geschriebene gilt f=FCr=20 synchrone =DCbertragung.

Bye

Fragen, insbesondere nachdem ich einen Artikel in einer

Pakete à 16 Byte.

Gab es da nicht mal ein Startbit? Bei bekannter Baudrate sollte es das dann doch gewesen sein mit der Synchronisation.

wird,

Stopbit

Die Handshakesignale hatte ich in der Tat anderen Funktionen zugeordnet.

Lutz

--
Temperatur und mehr mit dem PC messen - auch im Netzwerk: http://www.messpc.de
jetzt neu: Ethernetbox für direkten Anschluss der Sensoren im Netzwerk
Test im IT-Administrator: http://www.messpc.de/MessPC-Testbericht-ITA.pdf
http://www.netzwerkseite.de - die Seite rund um EDV-Netzwerke

Wir hatten mal die Idee von der Webseite: www.gefährliches_Halbwissen.de Wir haben es nie realisiert, Gronottes Sprüche könnten die Seite echt füllen...

Marte

Fragen, insbesondere nachdem ich einen Artikel in einer

Pakete à 16 Byte.

Und'n Stopbit (oder 1,5, oder 2). Macht 10 Bit für 8 Nutzbit. Startbit 0, Stopbit 1: 0xxxxxxxx1.

Jetzt übertrag mal 0100011101 lückenlos. Einfach mal

010001110101000111010100011101

im fixed Font drunter lang schieben und gucken, bei welchen Folgen ein

0xxxxxxxx1-Rahmen ausgefüllt wird. Ich seh auf Anhieb 0100011101, 0101000111 und 0001110101.

Das war's dann wohl mit der Synchronisation, zumindest theoretisch. In der Praxis sendet natürlich a) kaum ein System kontinuierlich und b) erst recht kein System fortwährend identische Daten - zumindest könnte man sich da ja dann die Übertragung sparen.

Von daher passt's schon - ein paar Byte können schon zur richtigen Synchronisation nötig sein, je nachdem, wie Sender und Empfänger sich treffen. Ist Kommunikation, halt wie im wirklichen Leben, manchmal braucht's schon ein Weilchen, bis man sein Gegenüber versteht :-)

Andreas

--
Yogi Berra said, "In theory, theory and practice are the same, but in
practice they are different".

Ich hatte ihn so verstanden, dass der Sender meist nichts sendet (ausser 6 x 16 Byte pro Sekunde):

Damit sollte der Empfänger beim ersten Startbit hellhörig werden und alles mitlesen, bis der Puffer im UART voll (dann wird überschrieben?) ist oder es mal jemand abholt.

Übrigens habe ich ausser

gar nicht so genau gefunden, worin das Problem eigentlich besteht. Am Durchsatz wird es aber bei 38400 bit/sec und 6 x 16 zu übertragenden Bytes (mit Start/Stopbit ca. 960 bit/sec wohl eher nicht liegen.

Lutz

--
Temperatur und mehr mit dem PC messen - auch im Netzwerk: http://www.messpc.de
jetzt neu: Ethernetbox für direkten Anschluss der Sensoren im Netzwerk
Test im IT-Administrator: http://www.messpc.de/MessPC-Testbericht-ITA.pdf
http://www.netzwerkseite.de - die Seite rund um EDV-Netzwerke

Lutz Schulze schrieb:

Hallo,

was Gronotte schreibt ist grunds=E4tzlich nur mit =E4usserster Vorsicht z= u=20 geniessen, da darf man sich nicht von irref=FChren lassen.

Bye

"Lutz Schulze"

Fragen, insbesondere nachdem ich einen Artikel in

Pakete à 16 Byte.

Einige aktuelle USB->RS232 Adapter kennen die Baudrate ebend nicht. Trotz Einstellungsmöglichkeit leitet der Treiber diese Information nichtmal weiter. Ich hatte zuletzt ein Gerät bei dem ich mit einem Poti zwischen 100 und 24000 Hz verstellen konnte. Während der Datenübertragung konnte ich bei einem USB-RS232-Adapter während der Übertragung, wenn diese Synchronisiert war, von 14400 langsam nach 1200 runterdrehen ohne Datenabriss. Die ursprünglichen Standards für RS232 scheinen heutzutage einfach nicht mehr wirklich zu gelten.

Hallo,

Bei ausreichenden Pausen vor dem Byte(strom) ja. Die Pause sollte, im Optimum, mindestens das 1,5fache eines Bytes haben dann klappts auch zuverlässig sofort mit dem ersten Startbit (also ohne Datenverlust).

doch, das kommt schon mal vor

manchmal ist ein dafür erforderliches Highlevel-Protokoll schon zu viel Aufwand

Also darauf sollte man sich nicht verlassen. Ich hab selber mal das Problem gehabt das verschiedene PC's (mit verschiedenen Chipsätzen) sich _nicht_ auf einen kontinuierlichen Datenstrom syncronisieren konnten. Ich musste meinen Sender auf die nächst höhere Standartbaudrate umstellen und zwischen den einzelnen Datensätzen eine angemessene Pause lassen damit alle verfügbaren PC's (und auch einige zum Test benutzte Microcontroller) sich zuverlässing syncronisieren konnten.

Schade das die modernen UART's nur selten die Option "1,5 Stopbitlänge" anbieten. Damit währe eine Syncronisation (eventuell sogar eine automatische Baudratenerkennung), auch bei einem kontinuierlichem Datenstrom, zuverlässig möglich.

Grüße Erik

"Makus Gr0n0tte" schrieb :

Also bei Leuten mit so viel Halbwissen sollte man ernsthaft an die Einführung eines Internetführerscheins denken. In der Klasse "Veröffentlichen von Beiträgen in ernsthaften NGs" währe Markus wohl durchgefallen.

Grüße Erik

Bespiel Bitte (am besten mit Aufzeichnung vom USB-Traffic).

Meinst Du wirklich ein Gerät das einen UART mit einer variablen Frequenz versorgt?? Wenn ja, dann bitte mal Type + Hersteller nennen. Ich kenne nur UART's die eine feste Frequenz bekommen und mit einem Teiler entsprechend runterteilen.

Datenabriss.

Also da währe ich gerne dabei gewesen. Obwohl ich schon der Meinung bin dass das technisch machbar ist kenne ich nichts wo sowas umgesetzt wird.

Tja, Du weist ja : "Regeln sind zum Brechen da".

Grüße Erik

Datenabriss.

Und die Abtastpunkte beim Empfänger verschoben sich von Zauberhand einfach so mit? Grandios.

Oder in der Deutung des Effekts ist ein Fehler.

Lutz

--
Temperatur und mehr mit dem PC messen - auch im Netzwerk: http://www.messpc.de
jetzt neu: Ethernetbox für direkten Anschluss der Sensoren im Netzwerk
Test im IT-Administrator: http://www.messpc.de/MessPC-Testbericht-ITA.pdf
http://www.netzwerkseite.de - die Seite rund um EDV-Netzwerke

"Erik G."

versorgt??

eine feste Frequenz bekommen und mit einem Teiler

kA was ein UART ist.

Das Teil habe ich über ein Internetauktionshaus ersteigert. Finde die alte Auktion aber nicht meha wieder. Der in dieser Auktion abgebildete entspricht aber in Form und Farbe 100%.