FTDI FT245 mit D2XX Treiber - Problem mit FT_Write

[stimpy (Gast)]

Hallo,

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

int _tmain(int argc, _TCHAR* argv[])
{
   DWORD numDevs;
   UINT32 dwDescFlags = FT_LIST_BY_INDEX;

   FT_STATUS ftStatus = FT_CreateDeviceInfoList( &numDevs );
   if (ftStatus == FT_OK)
   {
      FT_HANDLE ftHandle;
      if( FT_OK == FT_Open( 0, &ftHandle ))
      {
         DWORD BytesWritten;
         for(BYTE j=1; j<=8; j++)
         {
            BYTE b = 0xFF ^ (1<<j);
            ftStatus = FT_Write( ftHandle, &b, sizeof(BYTE), &BytesWritten );

            if (ftStatus != FT_OK)
               printf( "FT_Write Failed!" );

            Sleep( 50 ); // sonst geht es nicht! :-(
         }
      }
      FT_Close( ftHandle );
   }
   return 0;
}

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!

[stimpy (Gast)]

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?

[Ralf (Gast)]

> 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

[stimpy (Gast)]

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

[stimpy (Gast)]

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.