USB -> RS232 (TTL) Wandler

Hi,

ich bin gerade auf diesen USB-RS232 Wandler gestoßen:

http://www.ftdichip.com/Products/Eva.../TTL-232RG.htm

Mein bisheriger USB-RS232 Wandler funktioniert leider nur bis 19200 Baud, was mir ein bischen zu wenig ist.
(Mein AVR sendet alle Sensorwerte über RS232 bzw. USB an einen PC, der verarbeitet diese und macht zusätzlich Webcam-Bildverarbeitungen usw. und sendet dann Steuerbefehle zurück zum AVR. Daher fällt an der RS232 Schnittstelle sehr viel Datentransfer an).
Darum habe ich mir überlegt den obigen Wandler zu kaufen. Sein Vorteil ist ja, dass er direkt den TTL Pegel auf USB übersetzt, bis jetzt hatte ich immer den MAX232 der den TTL Pegel auf PC Pegel brachte, und dann erst den RS232-USB Wandler, der auf USB umwandelte.
Ich hab schon oft gelesen, dass eigentlich nur die Schnittstellenwandler die Baudrate limitieren, und da es ja beim obigen Wandler keine MAX232 oder ähnliche gibt, sollte er ja problemlos mindestens 640000 Baud erreichen können oder?
Im Datenblatt des Wandlers steht was von 3MBaud, das wär natürlich noch schöner.

Glaubt ihr das funktioniert mit dem Wandler? (mein uC ist ein Mega32)

lg Christoph


EDIT: Ich hab noch einen Wandler gefunden, der soll sogar bis zu 12MBaud schaffen: http://www.ftdichip.com/Products/Eva...eedModules.htm (der ganz unten). Wär schön wenn das mit einem Mega32 funktionieren würde...

Es hängt immer davon ab wie sicher dein Controller diese Baudraten schafft. Wenn er die schon nicht richtig schafft, also die Toleranz zu groß ist kannst du da auch einen richtig guten Wandler dran haben, nur es bringt dir nichts.

Ich glaube dass mein derzeitiger RS232-USB Wandler oder der MAX232 (zwischen RS232-USB Wandler und uC) die Geschwindigkeit auf 19200 Baud begrenzt.
Aber du hast Recht, es könnte auch der mega32 sein der nicht mehr als 19200 Baud schafft. Ich weiß aber nicht wie ich das herausfinden soll, im mega32 datenblatt habe ich nichts über die maximale Baudrate gefunden.

Sonst fällt mir nur ausprobieren ein, aber ich will das Teil nicht kaufen wenns dann nicht funktioniert...
Habt ihr noch Ideen?

lg Christoph

Zitat:

---

Zitat von Kampi

Es hängt immer davon ab wie sicher dein Controller diese Baudraten schafft. Wenn er die schon nicht richtig schafft, also die Toleranz zu groß ist ...

---

Das Thema Baudratenfehler bzw. Toleranz wegen der ganzzahlingen UBRR hatte ich mir mal angesehen, beispielhaften Tabellenauszug siehe unten. Mit einem USB-nach-232TTL-Wandler von minimikro auf Basis des FT232RL, mit der "normalen" FTDI-Initialisierung, schaffe ich trotz des von mir errechneten Fehlers locker 256000 (megaxx8, Fujitsu Siemens, Celsius M 410 Workstation, WinXPpro). Ich vermute, dass der FT232 ziemlich fehlertolerant ist.

........Bild hier  

Das von mir benutzte Teil ist eigentlich ein ISP-Programmer für die AT89LP Familie, siehe hier, klick auf "ISP-Programmer", der erste in der Liste.

........Bild hier   © gms2000.de

Verstehe ich das richtig, dass die Schwierigkeit nur die ist, dass die Baudraten von Sender und Empfänger übereinstimmen?

Ich habe am PC der als Empfänger fungiert Labview laufen, das die Daten empfängt. In Labview kann ich die Baudrate auf die Einerstelle genau einstellen, ich könnte also statt z.B. 19200 auch 19201 nehmen.

Könnte ich z.B. mit einem Externen Quarz Oszillator (die Dinger mit den 4 Beinen mein ich) höhere Taktraten erreichen?

lg Christoph

Lies Dich vielleicht mal eben ein, hier.

Zitat:

---

Zitat von Christoph2

... dass die Baudraten von Sender und Empfänger übereinstimmen ...

---

Im Rahmen der zulässigen Abweichungen sollten die übereinstimmen. Lies vielleicht mal dies über das Timing der Seriellen Schnittstelle. Nimm doch mal an - nur mal so als Beispiel - dass das letzte Bit erst dann gesendet wird, wenn der Empfänger schon das erste Bit des neuen Datenpaketes erwartet (Datenpaket: Übertragungsbyte inklusive dessen Start- und Stopbits) dann kommt der doch ins Schleudern, oder?

Zitat:

---

Zitat von Christoph2

... In Labview kann ich die Baudrate auf die Einerstelle genau einstellen, ich könnte also statt z.B. 19200 auch 19201 nehmen ...

---

Ja ja, ich hatte früher auch mal die Baudrate in meinem Controller so eingestellt *ggg* - auf ein Digit genau. Solange Du den Code dahinter nicht kennst, kannst Du es machen - und es geht, oder auch nicht *ggg*

Hallo!

Praktisch müssen die Baudraten nur während eines Bytes in Toleranz bleiben, da bei Pausen zwischen Bytes, synchronisiert sich das neu. Versuchswert wäre eine deutlich höhere Baudrate mit genügenden Pausen zwischen Bytes.

Theoretisch wäre möglich permanent senden mit "dummy" Bytes und den Clock für Rucksenden verwenden.

MfG

probier mal den usb->TTL Adapter von ulrich radig!
Der geht mit nem tiny locker bis ~57600 baud.
Theoretisch sollten auch baudraten im 250000er bereich möglichs sein!
(hier die passende Quarztabelle)

LG Jakob

Je nach dem wie viele Pins du noch frei hast: FT245.
Der Käfer wird parallel angesteuert, d.h. zwischen AVR und FT245 brauchst du dir schon mal keine Gedanken über die Baudrate machen.
Zwischen FT245 und PC ist die Baudrateneinstellung dann eh kein Problem.

Wenn man die Atmegas mit externem Quarz auf 14,7456 MHz betreibt, gehen auch zuverlässig 115200 Baud. Sowohl mit den FT232 als auch mit den PL2303 basierenden Adaptern.

Gruß
Daniel

Hallo Christoph,

wenn du einen schnellen USB-RS232 Konverter benötigst, guck mal hier:

http://www.deditec.de/de/entwicklung...ttl-stick.html

Der hat sogar eine galvanische Trennung.

Zitat:

---

Zitat von handyman

... wenn du einen schnellen USB-RS232 Konverter ... sogar eine galvanische Trennung.

---

Puhhh - der kostet auch nur schlappe 70 Flocken, vermutlich ohne Versand. Ich habe diesen hier für erheblich weniger als die Hälfte (klick links auf ISP Programmer, der AT89LP USB Flash Programmieradapter).

............Bild hier  
............ © GMS

Der läuft bei mir problemlos bis 256 kBd - mehr habe ich bisher nicht getestet - kann BitBanging und schafft laut Spezifikation 300 Baud bis 3 Mega Baud. Bei watterott gibts etws Ähnliches für 12 Steine. Die galvanische Trennung hatte ich offensichtlich noch nie benötigt *ggg*.