1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Slow data rate FT245BM to PC

Discussion in 'Embedded' started by Guest, Aug 25, 2005.

  1. Guest

    Guest Guest

    I am working on a PIC project that uses an FT245BM to transfer data to
    the PC over USB. I am transferring about 3MB of data and want to do it
    as fast as possible. However, my current solution is way too slow.
    Maybe someone can point out what I am doing wrong.

    Let me start off by saying that I know VB isn't a speed demon, but I
    don't think it is the bottle neck here. I am running this on a P4
    3.2Ghz machine, so even VB is quick.

    Here are the symptoms of my problem. The 245's TXE seems to go high
    (signaling that the internal buffer is full) for "long" periods of time
    even though I am doing FT_Reads as fast as possible on the PC. I've
    run into issues like this before using the FTDI chips, but was able to
    solve them by tweaking the timeouts, latency timer, and buffer sizes.
    However, this time, tweaking the settings just seem to slow things down
    even more.

    Here are the basic init commands I am using (note this is not runnable

    FT_OpenEx("Device Name", FT_OPEN_BY_DESCRIPTION, lngHandle)
    FT_SetTimeouts(lngHandle, 500, 0)
    FT_SetLatencyTimer(lngHandle, 1)
    FT_SetChars(lngHandle, 126, 1, 0, 0)
    FT_SetUSBParameters(lngHandle, 16384, 0)
    FT_Purge(lngHandle, 3)

    Here is the code I use to poll the device:
    lngBytesRead = 0
    queue_length = 0
    ftStatus = FT_GetQueueStatus(lngHandle, queue_length)
    If queue_length > 32000 Then
    queue_length = 32000
    End If
    ftStatus = FT_Read(lngHandle, strReadBuffer, queue_length,

    If (ftStatus = FT_OK) Or (ftStatus = FT_IO_ERROR) Then
    If lngBytesRead > 0 Then
    bigarray() = StrConv(strReadBuffer, vbFromUnicode)
    ReDim Preserve bigarray(lngBytesRead)
    CopyMem imgarray(data_buffer_pointer),
    data_buffer_pointer = UBound(bigarray) +
    lngTotalBytesRead = lngTotalBytesRead + lngBytesRead

    End If
    flFatalError = True
    End If
    Loop Until (lngTotalBytesRead >= 3145728) Or (cancel_but = True) Or
    (flFatalError = True)

    The code functions well, it is just a bit slow. It can take up to 30
    seconds to transfer 3 megs. I tried not using the FT_GetQueueStatus
    and just used a fixed number for the FT_Read. This seemed to be less

    Any suggestions would be helpful. Thanks!

    Guest, Aug 25, 2005
    1. Advertisements

  2. Guest

    Guest Guest

    Using one of FTDI's examples, I recoded this using VC++ 6.0. It was a
    little faster, but still nowhere close to the rated speed. Here is the
    main loop I used to empty the receive buffer (I know it does not store
    the data yet):

    Read(rx, bytes_in_buf, &ret_bytes);
    if(ret_bytes==0) Read(rx, bytes_in_buf, &ret_bytes);

    Any suggestions would be helpful. Thanks!

    Guest, Aug 25, 2005
    1. Advertisements

  3. Guest

    Lanarcam Guest

    Did you try to remove the DoEvents?
    Lanarcam, Aug 26, 2005
  4. Guest

    Guest Guest

    Yes, I tried removing the DoEvents. Still nowhere near the rated speed.
    Guest, Aug 26, 2005
  5. Guest

    Donald Guest

    Your rash assumption about USB on VB is wrong.

    The generic driver used in Windows _is_ the basic bottleneck.

    I am not a PC driver programmer. So I can not address the problems there.
    Donald, Aug 27, 2005
  6. How slow exactly _is_ "way too"? Try to give some hard numbers.
    Ahh... now I see you did, at the far end of your post:
    Well, let's see: that means you got at least 100 kByte/s, or .8 Mbit/s
    of payload throughput. That's only one order of magnitude below the
    baud rate. What USB transfer mode are you using?

    You should also try to relate them with the bandwidth of the interface
    between your PIC and the FT245BM, and the speed of the PIC itself.
    It may feel quick, but that doesn't mean it actually is. You're
    trying to talk to a low-level driver here --- there could be all kinds
    of internal delays involved, not the least the context switching time
    between your application and the kernel's USB layer.
    How long is "long"?
    Hans-Bernhard Broeker, Aug 28, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.