FT245 Buffer Problem

Bir mir funktioniert das eigentlich problemlos.
Der FT245 hat 384Bytes.
Wenn du alle 50us sendes, reicht der Buffer für 19,2ms und das sollte
für USB eigentlich kein Problem sein.

Was verwendest du zum Empfangen der Daten auf dem PC ?

Also ich verwende das "DLP Design Test Application" Terminal Programm
(später soll es Borland C++ Builder empfangen). Jedoch mit dem
Virtuellen Com Port! Ich habe gelesen, der D2XX wäre schneller!?
Was genau passiert: Ich schreibe alle 50µs 11Byte in den Buffer und
sende diese mit den SND Pin ab! Also wäre der Buffer nach etwa 1,75ms
voll.

Habe gerade den DLL Treiber installiert...aber das selbe Problem! :-(

Funktioniert das ganze denn, wenn du weniger Daten sendest (z.B. die 11
Byte alle 500us) ?

Habe es jetzt wie folgt getestet:
Ich schreibe mehrere Meßzyklen (a 11Byte) in den Buffer und sende sie
dann zusammen ab; soll heißen nachdem z.B. 187 Byte in Buffer sind,
wird gesendet. Mit der Methode habe ich 4488 Byte schon Fehlerfrei
übertragen können (12Meßzyklen a 11 Byte). Doch bei 13Meßzyklen
(4862Bytes und höher) kommt es erneut zu Fehlern!
Ich habe auch deinen Rat befolgt die Datenrate von 50µs auf 500µs zu
reduzieren, doch das führt zu keiner Veränderung! :-(

Klare Diagnose, der Buffer ist voll - TXF Pin geht auf high! ...obwohl
ich Datenpackete in den Buffer schreibe und sie dann mittels SND Pin
abschicke! Laut Datenblatt sind 300Kbyte/s mit dem VCP möglich! Ich
will ja nur 220Kbyte/s (11Byte alle 50µs)!!! Wie zum Teufel kann da
mein Buffer überlaufen??

Ich würde mir mal genau ansehen, was im PC passiert. Wenn dort die Daten
nicht aus dem Puffer genommen werden, läuft auch irgendwann alles über.

Gruß, Michael

>Klare Diagnose, der Buffer ist voll - TXF Pin geht auf high! ...obwohl
ich Datenpackete in den Buffer schreibe und sie dann >mittels SND Pin
abschicke!

Das kommt davon, wenn man keine Datenlätter liest:
TXE#: When high, do not write data into the FIFO.

Weiterhin steht im Datenblatt:
The Send Immediate / WakeUp signal combines two functions on a single
pin.
During normal operation (PWREN# = 0), if this pin is strobed low any
data in the device TX buffer will be sent out over USB on the next
Bulk-IN request from the drivers regardless of the pending packet size.
This can be used to optimise USB transfer speed for some applications.
Tie this pin to VCCIO if not used.

Wenn du die Daten also sendest (was man eigentlich nicht braucht, da
der FT245 alleine entscheidet, wann er sendet), dann heißt das nicht,
dass die Daten sofort weggehen, sondern die Daten werden erst im
nächsten Zeitintervall gesendet, wenn der PC USB wieder abfragt !
Da du die Packetgröße reduzierst, können weniger Daten in jedem
Abfrageintervall übertragen werden.

Lass also den SND Pin weg, und frag stattdessen TXE ab !

Die Datenrate von 300kB lässt sich übrigends leicht erreichen (zumindest
von PC -> uC). Mit dem VCP Treiber habe ich schon über 600kByte/s
erreicht.
Allerdings muss dazu die Packetgröße entsprechend groß gewählt werden:
Solche Datenraten erreicht man nur, wenn man die Daten in einigen
10kByte Blöcken an den Virtuellen COM Port übergibt bzw. davon liest.

Wie kann ich denn die Häufigkeit der Abfrage (also das USB Data-In
request) beeinflussen, z.B. bei mein Borland C++ Builder? Damit die
Daten möglichst schnell aus dem USB Puffer rauskommen.

Klar ist, dass ich TXF nun teste bevor ich reinschreibe. Also brauche
ich eine Sendepuffer, in den ich schreibe, wenn TXF high ist und aus
dem ich in den FT245 Puffer schreibe, wenn TXF wieder low ist. Habt ihr
da einen Realisierungsvorschlag? ...bin noch nicht so lange dabei!

Also, Lösung des ganzen: Ich sende in Packeten a 222 Byte mittels
Puffer! Läuft super!