This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320F28377D: EMIF interface to FT232H USB bridge

Part Number: TMS320F28377D

Tool/software: Code Composer Studio

Hello,

we are currently trying to connect a Delfino board with a FTDI FT232H USB bridge chip, with the goal of reaching faster USB transfer speeds than the Delfino USB supports (the target is about 15MB/s). To achieve this, we are trying to connect the two chips using the 8-bit asynchronous interface of the FT232H.

In this mode, the FT232H uses two lines (RXF and TXE) to signal to the processor if more data can be read from or written to the USB buffers. Unfortunately, these lines are also used to synchronize access to the FT232. On every read cycle, the RXF line is asserted and the processor may not read more data until the RXF line becomes de-asserted again:

Note that the RXF line does not become asserted until after the read-strobe signal is done, otherwise we could use the EMIF extended wait mode. Is there a way to make the extended wait mode add cycles after the read strobe?
Can you think of any other way we can interface with this USB chip and have sufficient throughput? Alternatively, are there any USB bridge chips that are more suitable?

Since we are using DMA to transfer the data, is there a way to halt a DMA transfer until the RXF line becomes de-asserted? I have tried using an external interrupt to trigger the DMA, but that seemed to incur a very large delay between the falling edge and the next read cycle.



Thank you very much and best regards,
Bart

  • Bart,

    EMIF interface is master interface and does not acknowledge any input from external device except WAIT and that also only during active transfer. WAIT can not be used to initiate the transfer. You have to use the external input as interrupt and trigger the DMA (or CPU) transfer based on that but please note that is for some reason external input goes inactive then also DMA transfer will complete unless you have just one transfer for each DMA trigger and in that case using CPU may be better.  Overall it does not look very effective in term of throughput.

    Have you looked at using SPI instead of parallel interface?

    Regards,

    Vivek Singh

  • Hi Vivek,

    thank you for your help. We are currently only transferring single bytes for each DMA trigger, so I will investigate if using CPU transfers are more efficient.

    SPI only supports up to 30 MHz on the FTDI chip, which is not enough for our requirements.

    I will update this thread or resolve it when I have further details or questions.

    Thank you very much and best regards,
    Bart