Subject: Re: Problem with Bitbang mode on some computers
From: "support2" <[email-masked]>
To: "Bernhard Michelis" <[email-masked]>
Date: Wed, 18 May 2005 12:10:00 +0100

Bernhard,

The drawing is correct.

Caps between connector and 27R, NOT between 27R and FTDI chip.

Regards,

Gordon Lunn
Support Engineer

FTDI Ltd
373 Scotland Street
Glasgow
Scotland
UK
G5 8QB

Tel:     +44 (0) 141 429 2777
Fax:    +44 (0) 141 429 2758
Web:   www.ftdichip.com

  ----- Original Message ----- 
  From: Bernhard Michelis 
  To: support2 
  Sent: Tuesday, May 17, 2005 4:01 PM
  Subject: Re: Problem with Bitbang mode on some computers

  Hi,

  just one more question. The two 47p caps mentioned in your last e-mail.
  What side of the 27R resistors do they belong to? Between USB-connector and the 27R resistors or between the 27R resistors and the FT232BM?
  Is the attached e-mail correct?

  Thank you,
  Bernd
    ----- Original Message ----- 
    From: support2 
    To: Bernhard Michelis (by way of Keith Dingwall <[email-masked]>) 
    Sent: Monday, November 22, 2004 12:08 PM
    Subject: Re: Problem with Bitbang mode on some computers

    Bernard,

    We have found with some of the newer USB 2.0 interfaces our design requires 47pF caps to be added on USB DP and USB DM data lines to GND to improve the line termination. Your symptoms suggest adding the device is locking up due to this poor termination and adding these capacitors will fix the problem.

    Regards,

    Gordon Lunn
    Support Engineer

    FTDI Ltd
    373 Scotland Street
    Glasgow
    Scotland
    UK
    G5 8QB

    Tel:     +44 (0) 141 429 2777
    Fax:    +44 (0) 141 429 2758
    Web:   www.ftdichip.com

      ----- Original Message ----- 
      From: Bernhard Michelis (by way of Keith Dingwall <[email-masked]>) 
      To: support2 
      Sent: Monday, November 22, 2004 8:28 AM
      Subject: Re: Problem with Bitbang mode on some computers

      Hi,
       
      I have some additional information.
      There seems to be a driver related problem on some computers.
      In this case non of the drivers mentioned below will work on my completely new installed (Recovery CD run) Toshiba Satellite 1130-Z23 (2GHz Celeron/Win XP SP2/USB2) notebook.
      Here's what happens.
      The following fragment of programme code is repeated several times without any delay.
       
             Begin of loop.....
       
              length = (SendBufferSendPos+128)<SendBufferWritePos ? 128:SendBufferWritePos-SendBufferSendPos;
              FT_Write (hDevice, SendBufferSendPos, length, &BytesWritten);
              SendBufferSendPos+=length;
       
              if ( (result = FT_Read (hDevice, receivebuffer, 384, &BytesWritten)) != FT_OK) 
                  return result;
             
             .......end of loop
       
      As you can see, I am sending small chunks of data and reading back bigger chunks of data, to prevent data loss.
      What happens now is, that suddenly the FT-Read function-call returns the value 4 (FT_IO_ERROR according to the headerfile).
      Sometimes this happens after 10 cycles, sometimes I can perfom this cycle for a while, but it is guaranteed that the error will happen, sooner or later.
      From that moment on, all other function-calls will fail. That was the reason, why I wasn't able to reopen the driver after closing (see below).
      At lease at the Toshiba notebook, mentioned above, this failure happens all the time, no matter what I am doing.
      On the other hand, the same application is running quite fine on my Athol 2000+/WinXP w/o SP (USB2, too).
      The IO_ERROR can only be solved by disconnecting the hw and reconnecting it.
       
      BR,
      Bernhard Michelis

        ----- Original Message ----- 

        From: Bernhard Michelis 

        To: [email-masked] 

        Sent: Thursday, November 18, 2004 7:28 PM

        Subject: Problem with Bitbang mode on some computers

        Hi,

          
        I have the following problem and cannot find a solution.

          
        I tried the driver packages D10606, Drp10504 (with Product ID set to 6006 = XP bug) and D10620 (6001).

          
        I'm using a FT232BM in BitBang mode.

          
        Sending data @ about 1MB/s works without problems on all computers.

          
        According to the "FT232BM&FT245BM_BitBangMode.pdf" (Application Note AN232BM-01) it is possible to configure several pins as outputs and others as inputs (at the same time). So far so good.

        What I need now, are the data from the Read Pipe. Therefore I reduced transfer rate to about 300kB/s. BecauseI have to transmit and receive data simultaneously.

            FT_STATUS FT_SetLatencyTimer ( FT_HANDLE ftHandle, UCHAR ucTimer ) 

        I set the Latency Timer to 1ms. As far as I understand, now every millisecond data are transfered from and to the FT232BM/FT245BM. (Short latency).

          
        The read buffer is 384Bytes and if I query information every 1 ms I should be able to read up to 384000 Byte/s without loosing any data while I am sending at about 384000 Bytes/s in the other direction. 

        The problem is that I am loosing a lot of data from the read stream.

        On one computer (Athlon 2000+/WinXP without SPs) the loss of data is little and it is possible to work at about 300kB/s. Even if it is a little tricky to empty the read pipe. For this purpose I close and re-open the device. Works for me.

          
        But on my other computer (Celeron 2GHz/WinXP SP1) I got into trouble. The same application won't work anymore. Sending data at 1MB/s is still no problem, but when I want to re-read an interruption free modified output stream, I have to lower the clockrate to about (500*16=) 8KB/s instead of 300KB/s (20000x16) what was possible on the Athlon 2000.

          
        That would mean: 8000Bytes/s  /   384Byte(Buffer)   =   20,8 reads/s   ->   So the computer reads about one 384Byte packet every 48ms and not every 1ms as set with the latency timer function. (Maybe it does, but if it misses it sometimes, it's worthless).

          
        Further more I get into trouble when I close and reopen the device on the Celeron 2Ghz quite often (to empty the read pipe). Suddenly, it is no longer possible to open the device, despite closing the device properly before. Only unpluging the device and reconneting it makes it available again. Sometimes FT_Read calls result in IOErrors, too, on this system.

          
        So there are 2 main problems. The too slow reading (only every 48ms) of the input data stream and the problem that the device cannot be reopened, in spite of closing it before.

          
        The funny thing is, that the complete system, application sw and hardware is working on the Athlon.

          
        Is there are way to make the driver work with a more guarantied timing. I tried to stream in some data (only FT_Read requests), but I lost to much data. In the application note under 3 (FT_GetBitMode) is mentioned that the incoming data are sampled in the input buffer (384Bytes)  as long as it is not full. How can I make sure, it gets read in time before data get lost, so that there is always enough headroom for new incoming data?

          

        With kind regards,

        Bernhard Michelis