FT232H写命令之间的延迟

Question

我想在SPI模式下使用FT232H IC来驱动显示器。 我已将时钟频率设置为5 MHz。 在测试我的代码时，我注意到即使在紧密循环中，命令也会执行大约120微秒。 在下面的代码中，我发出一个写4个字节的命令。 我用VB中的秒表计时并观察示波器上的信号。 代码执行一次需要大约200微秒，连续执行两次大约需要320微秒，3次需要450微秒，依此类推。 每次实际发送的字节只需要大约7微秒。 在其余时间没有任何事情发生，即每次传输似乎浪费了120微秒。 问题：这个非活动时间只是恢复FT232H中的例程吗？ 我在这里错过了什么吗？ 有更好的命令可以使用吗？ 我想使用SPI尽快将数据输入ILI9341显示驱动芯片。 我知道其他人已经做到了。 欢迎提出建议！

 'Start
    'Data transmit, no receive
    SendBuffer(0) = &H10    'Output on rising clock, no input, MSB first, clock a number of bytes out
    SendBuffer(1) = &H3     'Length L
    SendBuffer(2) = &H0     'Length H
    SendBuffer(3) = &HA
    SendBuffer(4) = &HAA
    SendBuffer(5) = &HA
    SendBuffer(6) = &HAA

    'About 1-3 microseconds to this point

    FT_Status = FT_Write_Bytes(FT_Handle, SendBuffer(0), 7, BytesWritten)   ' Write buffer to the device

    '201 microseconds to this point

    'Data transmit, no receive
    SendBuffer(0) = &H10    'Output on rising clock, no input, MSB first, clock a number of bytes out
    SendBuffer(1) = &H3     'Length L
    SendBuffer(2) = &H0     'Length H
    SendBuffer(3) = &HA
    SendBuffer(4) = &HAA
    SendBuffer(5) = &HA
    SendBuffer(6) = &HAA
    FT_Status = FT_Write_Bytes(FT_Handle, SendBuffer(0), 7, BytesWritten)   ' Write buffer to the device

    '321 microseconds to here

    'Data transmit, no receive
    SendBuffer(0) = &H10    'Output on rising clock, no input, MSB first, clock a number of bytes out
    SendBuffer(1) = &H3     'Length L
    SendBuffer(2) = &H0     'Length H
    SendBuffer(3) = &HA
    SendBuffer(4) = &HAA
    SendBuffer(5) = &HA
    SendBuffer(6) = &HAA
    FT_Status = FT_Write_Bytes(FT_Handle, SendBuffer(0), 7, BytesWritten)   ' Write buffer to the device

    '450 microseconds to here

Answer 1

没有你的芯片（ FT232H ）的经验，但这里有一些可能性：

1. 一些IC具有用于内部通信的独立时钟

   如果设置得太低，那么你要等到命令发送到SPI模块而不是SPI传输本身。

2. 中断时间

   如果你正在使用中断，那么你的ISR会被延迟调用（有时候中断模块也有自己的时钟），或者你被后台或USB / DMA传输或配置中的定时器/计数器或其他ISR等其他进程阻止。

3. 调试界面

   如果您正在使用调试接口（如JTAG ），您可能会被它停止。 在这种情况下尝试没有这样的接口的原始应用程序，并通过示波器测量只是为了排除这一点。

4. 能源管理

   为了节省电力，一些芯片已经关闭了未使用的模块，在使用之前必须启动它们需要一些时间。 即使您正在更改模块的配置，也可能出现这种情况。

5. 芯片中的错误

   现在，管理层迫使/推出新芯片，有更高的可能性来消除芯片中的漏洞（比过去高得多）。 所以不要排除这种情况。我已经偶然发现了这几次。 通常尝试联系芯片生产商，或检查其数据表以获取更新/勘误表和已知错误列表。

Answer 2

我从芯片工厂了解到，延迟与USB批量传输考虑因素有关。 我会通过每次传输缓冲尽可能多的数据来处理时间。