USB/RS232 - welche Limits ?

[Nicolas Nickisch]

Hi NG,
meine Schaltung wird mit einem FT232BM betrieben, am anderen Ende hängt ein
ľC und am USB ein PC.

Da nicht alles ganz so funktioniert wie ich es mir vorstelle hier ein paar
Fragen, insbesondere nachdem ich einen Artikel in einer elektor diesen
Sommer las.
Danach wird die Leistungsfähogkeit der USART durch die Eigenheiten des USB
stark eingeschränkt.

Mein Konzept sieht vor mit 38400 (warum eigentlich nicht 57600 oder
schneller ?) Daten zu übertragen und zwar immer als Paket mit 16 Bytes. Von
diesen Paketen sende ich wiederum mehrere (z.Zt. 6 ) hintereinander. Eine
deutliche Besserung brachte die umstellung auf Hardware-Handshake CTS/RTS,
aber perfekt ist es nicht.

Das PC-Programm sendet die Datenpakete und zwar 5x/sek 6 (unterschiedliche)
Pakete ŕ 16 Byte. Programmtechnisch wird das Aussenden in Form von 6
Aufrufen erledigt, praktisch kommen aber die 6 Pakete direkt hintereinander.

Das Programm ist in VB geschrieben.

1. Frage: Kann ich durch gemeinsames Aussenden der gesamten Datenmenge den
Durchsatz verbessern ? Ich würde dann alle 76 Bytes zunächst in einer
string-Variablen zusammenfassen und dann den String senden. So sende ich 6
Strings ŕ 16 Bytes.

2.Lässt sich das Verhalten des USB-CVhips mit Treibereinstellungen oder mit
Einstellungen im EEPROM verbesern ?

3. Macht es Sinn jeweils nach einem Zeichen Empfang durch den ľC die
CTS-Leitung zu ändern oder sollte man den kompletten Empfang eines Paketes
abwarten ?

Gruss Nico

 

[Michael Eggert]

"Nicolas Nickisch" <nicolas.nickisch@gmx.de> wrote:

Hi!

Mein Konzept sieht vor mit 38400 (warum eigentlich nicht 57600 oder
schneller ?)

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.

und zwar immer als Paket mit 16 Bytes.

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

1. Frage: Kann ich durch gemeinsames Aussenden der gesamten Datenmenge den
Durchsatz verbessern ? Ich würde dann alle 76 Bytes zunächst in einer
string-Variablen zusammenfassen und dann den String senden. So sende ich 6
Strings ŕ 16 Bytes.

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

2.Lässt sich das Verhalten des USB-CVhips mit Treibereinstellungen

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:
http://www.ftdichip.com/Documents/AppNotes/AN232B-10_Advanced_Driver_Options.pdf
ab Seite 13.

oder mit Einstellungen im EEPROM verbesern ?

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

3. Macht es Sinn jeweils nach einem Zeichen Empfang durch den ľC die
CTS-Leitung zu ändern oder sollte man den kompletten Empfang eines Paketes
abwarten ?

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

Gruß,
Michael.

 

[Uwe Bonnes]

Nicolas Nickisch <nicolas.nickisch@gmx.de> wrote:

Hi NG,
meine Schaltung wird mit einem FT232BM betrieben, am anderen Ende h?ngt ein
?C und am USB ein PC.

1. Frage: Kann ich durch gemeinsames Aussenden der gesamten Datenmenge den
Durchsatz verbessern ? Ich w?rde dann alle 76 Bytes zun?chst in einer
string-Variablen zusammenfassen und dann den String senden. So sende ich 6
Strings ? 16 Bytes.

Pass auf, dass Dir VB die Zugriffe nicht aufspaltet.

2.L?sst sich das Verhalten des USB-CVhips mit Treibereinstellungen oder mit
Einstellungen im EEPROM verbesern ?

Schau mal das Receive Buffer Timeout an..

3. Macht es Sinn jeweils nach einem Zeichen Empfang durch den ?C die
CTS-Leitung zu ?ndern oder sollte man den kompletten Empfang eines Paketes
abwarten ?

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

 

[Makus Gr0n0tte]

"Nicolas Nickisch"

Da nicht alles ganz so funktioniert wie ich es mir vorstelle hier ein paar Fragen, insbesondere nachdem ich einen Artikel in einer
elektor diesen Sommer las.

Das PC-Programm sendet die Datenpakete und zwar 5x/sek 6 (unterschiedliche) 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

 

[Nicolas Nickisch]

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" <lliillii@gmx.net> schrieb im Newsbeitrag
news:435dbb0f$0$12675$9b4e6d93@newsread4.arcor-online.net...

"Nicolas Nickisch"

Da nicht alles ganz so funktioniert wie ich es mir vorstelle hier ein
paar Fragen, insbesondere nachdem ich einen Artikel in einer elektor
diesen Sommer las.

Das PC-Programm sendet die Datenpakete und zwar 5x/sek 6
(unterschiedliche) 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

 

[Ernst Schwab]

Hallo Markus,

Markus Gronotte schrieb:

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.

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.

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.

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

Jetzt wird zwar wieder irgendwer kommen und behaupten, dass dafür ja Start
und Stopbit
da sind,

Ja, hier! ;-)

aber dem ist in der Realität nicht ausschließlich so.

Doch.

Gruß
Ernst

 

[Michael Eggert]

"Ernst Schwab" <no.spam.for.me@onlinehome.de> wrote:

Hi!

Jetzt wird zwar wieder irgendwer kommen und behaupten, dass dafür ja Start
und Stopbit
da sind,

Ja, hier! ;-)

aber dem ist in der Realität nicht ausschließlich so.

Doch.

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.

 

[Uwe Hercksen]

Makus Gr0n0tte schrieb:

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.

Hallo,

mal wieder das übliche von Gronotte...
Der Unterschied zwischen synchroner und asynchroner serieller
Übertragung ist ihm wohl nicht klar, das oben geschriebene gilt für
synchrone Übertragung.

Bye

 

[Rainer Jenning]

Nicolas Nickisch wrote:

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

http://www.ftdichip.com/Documents/AppNotes/AN232B-04_DataLatflow.pdf

 

[Lutz Schulze]

On Tue, 25 Oct 2005 06:56:38 +0200, "Makus Gr0n0tte"
<lliillii@gmx.net> wrote:

"Nicolas Nickisch"

Da nicht alles ganz so funktioniert wie ich es mir vorstelle hier ein paar Fragen, insbesondere nachdem ich einen Artikel in einer
elektor diesen Sommer las.

Das PC-Programm sendet die Datenpakete und zwar 5x/sek 6 (unterschiedliche) 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.

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

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.

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

 

[Marte Schwarz]

mal wieder das übliche von Gronotte...
Der Unterschied zwischen synchroner und asynchroner serieller Übertragung
ist ihm wohl nicht klar, das oben geschriebene gilt für synchrone
Übertragung.

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

 

[Andreas Hadler]

Lutz Schulze <lschulze@netzwerkseite.de> wrote:

On Tue, 25 Oct 2005 06:56:38 +0200, "Makus Gr0n0tte"
lliillii@gmx.net> wrote:


"Nicolas Nickisch"

Da nicht alles ganz so funktioniert wie ich es mir vorstelle hier ein paar Fragen, insbesondere nachdem ich einen Artikel in einer
elektor diesen Sommer las.

Das PC-Programm sendet die Datenpakete und zwar 5x/sek 6 (unterschiedliche) 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.

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

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

 

[Lutz Schulze]

On Tue, 25 Oct 2005 19:45:38 +0200, Andreas Hadler
<Andreas.Hadler@t-online.de> wrote:

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

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

Das PC-Programm sendet die Datenpakete und zwar 5x/sek 6 (unterschiedliche)
Pakete ŕ 16 Byte. Programmtechnisch wird das Aussenden in Form von 6
Aufrufen erledigt, praktisch kommen aber die 6 Pakete direkt hintereinander.

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

Da nicht alles ganz so funktioniert wie ich es mir vorstelle

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

 

[Uwe Hercksen]

Lutz Schulze schrieb:

On Tue, 25 Oct 2005 06:56:38 +0200, "Makus Gr0n0tte"
lliillii@gmx.net> wrote:

Hallo,

was Gronotte schreibt ist grundsätzlich nur mit äusserster Vorsicht zu
geniessen, da darf man sich nicht von irreführen lassen.

Bye

 

[Makus Gr0n0tte]

"Lutz Schulze"

Da nicht alles ganz so funktioniert wie ich es mir vorstelle hier ein paar Fragen, insbesondere nachdem ich einen Artikel in
einer
elektor diesen Sommer las.

Das PC-Programm sendet die Datenpakete und zwar 5x/sek 6 (unterschiedliche) 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.

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

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.

 

[Erik G.]

Hallo,

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

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

In der Praxis sendet natürlich a) kaum ein System kontinuierlich und

doch, das kommt schon mal vor

b) erst recht kein System fortwährend identische Daten - zumindest
könnte man sich da ja dann die Übertragung sparen.

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

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

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

 

[Erik G.]

"Makus Gr0n0tte" <lliillii@gmx.net> schrieb :

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.

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

 

[Erik G.]

Einige aktuelle USB->RS232 Adapter kennen die Baudrate ebend nicht.
Trotz Einstellungsmöglichkeit leitet der Treiber diese Information
nichtmal weiter.

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

Ich hatte zuletzt ein Gerät bei dem ich mit einem
Poti zwischen 100 und 24000 Hz verstellen konnte.

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.

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.

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.

Die ursprünglichen Standards für RS232 scheinen heutzutage einfach nicht
mehr wirklich zu gelten.

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

Grüße
Erik

 

[Lutz Schulze]

On Wed, 26 Oct 2005 12:42:01 +0200, "Makus Gr0n0tte"
<lliillii@gmx.net> wrote:

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.

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

Die ursprünglichen Standards für RS232 scheinen heutzutage einfach nicht
mehr wirklich zu gelten.

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

 

[Makus Gr0n0tte]

"Erik G."

Ich hatte zuletzt ein Gerät bei dem ich mit einem
Poti zwischen 100 und 24000 Hz verstellen konnte.

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.

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

http://cgi.ebay.de/USB-Adapter-Seriell-Com-Port-NEUWARE-9-Polig-RS232_W0QQitemZ5822765986QQcategoryZ3668QQrdZ1QQcmdZViewItem