FTDI FT245 mit D2XX Treiber - Problem mit FT_Write

stimpy Gast #1593548
Lesenswert?
• ▲
▼ 
Hallo,

ich befasse mich gerade mit einem FT245BM. Begonnen habe ich zunächst 
mit einem einfachen Konsolenprogramm:

1
int _tmain(int argc, _TCHAR* argv[])

2
{

3
   DWORD numDevs;

4
   UINT32 dwDescFlags = FT_LIST_BY_INDEX;

5


6
   FT_STATUS ftStatus = FT_CreateDeviceInfoList( &numDevs );

7
   if (ftStatus == FT_OK)

8
   {

9
      FT_HANDLE ftHandle;

10
      if( FT_OK == FT_Open( 0, &ftHandle ))

11
      {

12
         DWORD BytesWritten;

13
         for(BYTE j=1; j<=8; j++)

14
         {

15
            BYTE b = 0xFF ^ (1<<j);

16
            ftStatus = FT_Write( ftHandle, &b, sizeof(BYTE), &BytesWritten );

17


18
            if (ftStatus != FT_OK)

19
               printf( "FT_Write Failed!" );

20


21
            Sleep( 50 ); // sonst geht es nicht! :-(

22
         }

23
      }

24
      FT_Close( ftHandle );

25
   }

26
   return 0;

27
}


Wenn ich FT_Write zu schnell hintereinander ausführe, blockiert es. 
Abhilfe schafft ein "Sleep(50)" oder FT_Purge().

Wie mache ich es aber richtig? Brauche ich evtl. 
FT_SetEventNotification?

Vielen Dank!
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Ralf Gast #1593644
Lesenswert?
• ▲
▼ 
> Habe gerade rausgefunden, daß der Takt zum Abholen der Daten extrem lang
> ist. Solange ist der Chip quasi blockiert. Trotzdem sollte die Software
> das abfangen können, aber wie?
USB ist im Gegensatz zu RS232/UART nicht Byte-orientiert, sondern am 
effektivsten bei Paketen, also mehrere Bytes in einem Rutsch. FT_WRITE() 
übergibt in deinem Fall ein Byte an den Treiberbuffer, der Treiber 
wiederum muss erst ne Transaktion draus machen, was dann in einem 
USB-Paket auf der Leitung resultiert. Das ganze braucht also seine Zeit. 
Das Sammeln mehrerer Bytes würde also schon helfen.

Abfangen in der Software könntest du es, indem du prüfst, ob der 
Sendebuffer leer ist. Allerdings kann ich mir nicht vorstellen, warum 
die Sache schon bei acht Bytes blockiert...

Ralf
Antwort Zitieren Bearbeiten Löschen Beitrag melden
stimpy Gast #1595038
Lesenswert?
• ▲
▼ 
Zwischenstand:

Meine Testhardware hat eine Besonderheit: ich setze RD# zum Auslesen der 
Daten etliche ms runter, damit ist der Chip offenbar "blockiert".
Sende ich in der Zwischenzeit weitere Bytes (mindestens 3), so blockiert 
offenbar der Treiber. Das geht sogar mit dem Terminalprogramm.

Jetzt gucke ich mal, wie ich diesen "nicht aufnahmebereiten" Status 
erkennen kann...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
stimpy Gast #1598331
Lesenswert?
• ▲
▼ 
Also der Support hat mir geantwortet. Das Verhalten ist völlig in 
Ordnung. Es ist die Aufgabe der Elektronik, die Daten abzuholen:

What you describe is the correct operation.  The buffers swap out every 
16mS or when full.  If you send 4 packets (pausing between each) but do 
not read the data from the module then it will hang as you are seeing 
now.  You must read each packet using a microcontroller or other device 
that will pull RD low.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren