neue Chips von FTDI: FT230X, FT234XD

Es ist halt immer eine Design-Frage.

Wer gibt schon gerne 2-3 Euro extra aus?

Vor ein paar Jahren war das sicherlich eine gute Alternative zu 'echtem' 
USB. Aber heute?

Selbst Atmel hat es mittlerweile hinbekommen und bei Microchip und 1000 
anderen klappt das mit USB und guter Firmware sowieso schon lange.

Das war eine Antwort auf eine nicht gestellte Frage ...

Ok, die Frage will ich Dir nicht vorenthalten:

Es gibt tolle neue FTDI-Chips!
Aber warum eigentlich?

Pit schrieb:
> Ok, die Frage will ich Dir nicht vorenthalten:
>
> Es gibt tolle neue FTDI-Chips!
> Aber warum eigentlich?

Kleiner? Günstiger? Besser?
;-)

>Kleiner? Günstiger? Besser?
>;-)
Womit wir wieder bei meiner ersten Antwort wären :)

Pit schrieb:
> Es gibt tolle neue FTDI-Chips!
> Aber warum eigentlich?

Pit schrieb:
> Selbst Atmel hat es mittlerweile hinbekommen und bei Microchip und 1000
> anderen klappt das mit USB und guter Firmware sowieso schon lange.

Habs selbst mit dem ST32F4xx probiert und wirklich für mich 
nichtzufriedenstellend hinbekommen.

Mag sein, dass es dafür (möglicherweise kostenplichtige) befiedigende 
USB_Stacks gibt. Wenn man das mit den freien Resourcen hinbekommen will, 
ohne dass man den USB im Detail gut kennt, ist das keine leichte 
Aufgabe. Da waren einige Interrupts die die CPU belastet haben, weil 
auch noch in der ISR unnötige Abfrageschleifen waren. In Summe dauerte 
manche ISR (bei Ein-Ausstecken vom USB) sher lang. Wie weit mich das bei 
meiner Hauptapplication stört wollte ich lieber dann nicht ausprobieren.
Bei Verwendung eines FTDI-Chips hast du eine klar definierte 
Uart-Schnittstelle, Interruptbelastung ist gering und gut überschaubar.
Man kann sich auf die Hauptapplikation konzentieren.

Bei nicht wirklich großen Stückzahlen ist das auch billiger. Kannst die 
von FTDI vorgegebenen Seriennummern verwenden, bist mit den Treibern von 
FTDI für den PC auch auf der sicheren Seite.

Fritz schrieb:
> Habs selbst mit dem ST32F4xx probiert und wirklich für mich
> nichtzufriedenstellend hinbekommen.
Klar, einige Demos vom Hersteller sind da schon von Vorteil.

Fritz schrieb:
> Da waren einige Interrupts die die CPU belastet haben, weil
> auch noch in der ISR unnötige Abfrageschleifen waren.
Interrupts hast Du auch bei UART und ob die tatsächlicher weniger 
'belasten' lass ich mal offen.

Fritz schrieb:
> bist mit den Treibern von
> FTDI für den PC auch auf der sicheren Seite.
Das halte ich nur für bedingt richtig:
Beitrag "Problem FT2232H von FTDI"

@Pit:
Die FTDI Chips sind gut und die Treiber sind die stabilsten aller 
USB->UART Wandler. Ich hatte damit noch nie Probleme - und ich habe 
ein Produkt damit entwickelt (mehrere tausend in den letzten Jahren 
verkauft).
So gut wie nie gab es Probleme mit den FTDI Treibern die nicht 60cm vorm 
Bildschirm zu suchen waren ;-)

USB VID kaufen ist teuer und Treiber selbst pflegen auch (für alle 
Windows Versionen von 1998 bis 2013 und dasselbe für Linux und Mac und 
dann auch noch 32 und 64 Bit... nö danke)

Pit schrieb:
> Interrupts hast Du auch bei UART und ob die tatsächlicher weniger
> 'belasten' lass ich mal offen.

Üblicherweise habe ich da nur Receive und Transmit Interrupt, damit eine 
gepufferte Übertragung zu schreiben ist nicht schwer.
"Belastung" ist vielleicht der falsche Ausdruck, aber ich kann eine 
ziemich kurze Interruptzeit garantieren.
Bei USB ist das viel undurchschaubarer.
Schau mal bei USB wie vile ISR-Möglichkeiten da vorhanden sind.

Pit schrieb:
>> Habs selbst mit dem ST32F4xx probiert und wirklich für mich
>> nichtzufriedenstellend hinbekommen.
> Klar, einige Demos vom Hersteller sind da schon von Vorteil.

Nur bedingt, die Demo von ST ist eine standalone UART - USB bridge, 
klingt recht gut, aber ist es nicht eine vernünftige Schnittstelle zu uC 
Anwendersoftware ist darin nicht enthalten. Nur USB rein -> Seriell 
raus.

Martin Wende schrieb:
> Nächstes Gegenargument bitte.

Wie handelst Du die Hersteller, Seriennummer für dein Gerät?
Mit FTDI bekommst du das gratis mit.

> Leider etwas höherer Aufwand, zwei Widerstände + zwei Kondenstoren für
> den USB.

Das ist ja doof, da nehme ich doch lieber einen FT232RQ

Martin Wende schrieb:
> Da haste jetz was falsch mitbekommen, ging um den Link von Pit mit dem
> Treiberproblem des FT ICs.

Treiberproble kann es überall geben, das stimmt schon.
Aber FTDI lebt von ihren USB-Chips und haben dadurch ureigenstes 
Interesse ihre Treiber aktuell und so fehlerfrei wie möglich zu halten.
Was man vom VCOM-Port driver von Windows nicht behaupten kann.

Erstmal vielen Dank für die Erweiterung meines Horizontes :)

Martin Wende schrieb:
> Nächstes Gegenargument bitte.

Die Treiber funktionieren aber auch nur solange man die VID/PID nicht 
ändert.

Martin Wende schrieb:
> Nächstes Gegenargument bitte.

Mangelnde Flexibilität: Bei 'echtem USB' kann ich mir die Schnittstelle 
bauen wie ich will - mit Keyboard/Maus-Funktion, Datenschnittstelle 
(Bulk) usw. Wenn ich HID nehme brauch ich nicht mal eine .inf-Datei.

Martin Wende schrieb:
> Nächstes Gegenargument bitte.

Und wie bereits erwähnt: Zusätzlicher IC mit Kosten.

Martin Wende schrieb:
> Nächstes Gegenargument bitte.

Und zusätzlichen Platz auf der Platine brauch ich auch noch.

Und das bring mich zum wiederholten Male zu dem Schluss:
Es ist eben Geschmacksache.

>True 3.3V CMOS drive output and TTL input.
>(operates down to 1V8 with external pull ups and is also 5V tolerant)
Das deute ich anders, erste Seite Datenblatt.


Gruß Matthias

>in 5V-Systemen ... zusätzliche Maßnahmen

Hast du dazu einen guten Vorschlag?

Spontan fällt mir dazu 74LVC1T45 ein, der kostet aber auch nochmal 15 
Cent extra. Dann schrumpft die Einsparung zum FT232R wieder auf 50 Cent 
zusammen.
Ein 74HCT125 Gatter müsste IMHO auch passen, das Teil ist dann aber noch 
teurer & größer.

Martin Wende schrieb:
> Vor allem frisst das wieder den Platzvorteil gegenüber eines FT232RL
> wenn da jetzt noch mit Pegelwandlern rumgewurschtelt wird ;)

Manchmal muss man einfach nur genau hinschauen.

Rangi Jones schrieb:
> In einem Projekt durfte keine ISR-Last aufkommen und
> da hilft dieser Chip prima. Man pollt den RXF-Out oder liesst Daten,
> sobald im Programm Zeit dafür ist, ganz ohne Interrupts.

Als ob man USB nicht auch pollen könnte. Denkst Du etwa, da gibt es 
einen Unterschied? Das Interrupt-Argument ist Quatsch.
Bei jeder Hardware müssen zwingenden ein paar Register gelesen werden 
(ob UART, USB oder sonst was). Das macht man im Interrupt und setz ein 
Flag um es dann in der Main auszuwerten - jedenfalls wenn der Interrupt 
viel 'Arbeit' nach sich zieht.
Und da die bei Microchip und sonst wo auch nicht zum ersten mal 
programmieren, kann man davon ausgehen, dass die schon das Richtige tun.

Rangi Jones schrieb:
> oh oh, ich glaube da muss nochmal jemand auf die Schulbank. Was
> passiert, wenn die Main nicht rechtzeitig drankommt? Dann ist das Byte
> Weg!

Zum Thema Schulbank: 'weg' schreibt man klein.

Rangi Jones schrieb:
> Also musst du die Daten in der ISR auslesen, und weil es
> prinzipiell viele sein können, brauchst du einen Puffer und der braucht
> wieder Zeiger und das ganze braucht wieder Zeit in der ISR.

Da passiert garnix, da der USB den Puffer erst wieder füllt, nachdem ich 
die Daten (ganz gemächlich) in der Main gepollt habe und den 
Empfangspuffer frei gebe. Bis das erledigt ist, sendet der USB einfach 
NACK an den Host.

Rangi Jones schrieb:
> fg haste mal versucht bei einem PC die RTS-Leitung
> zu ziehen, während der sendet? da kommen noch 5 bis 10 Bytes mindestens
> raus, bevor der aufhört zusenden. Und da rede ich nur von 115200Bd.

Im Übrigen haben sich meine Aussagen auf USB bezogen, da ja angeblich 
der USB mit den vielen Interrupts sooo viele Probleme macht - es scheint 
mir eher anders rum :)!
Danke für Deine Unterstützung!

Ich denke die sachlichen Dinge sind besprochen. Viel Spass noch beim 
lästern :)

Christian Schmidt schrieb:
>
> Er scheint kein Double Buffering zu haben,
>


Wozu sind denn dann die 512+512 Bytes RX/TX Buffer?

Vom Aufbau her sind die ja fast identisch zum FT232R und ham sogar 
deutlich größere Buffer - und beim 232R hab ich bislang noch kein 
Handshake benötigt - ohne Datenverlust bei 1MBit/s...?

Christian Schmidt schrieb:
> 2. Ohne RTS/CTS Handshake völlig unbenutzbar. Er scheint kein Double
> Buffering zu haben, und verliert einfach Daten wenn man während des USB
> Transfers weiter sendet.

Und du bist dir sicher, dass du die Daten nicht in deinem AVR verlierst.
Solche Aussagen sollte man schon genauer ausführen:
Welche CPU, CPU-Clock, Baudrate, RX und TX mit Interrupt? ...
Ich kann mirs nicht vorstellen, dass deine Behauptung stimmt!