FT232H写命令间隔时间

Question

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

 '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. 芯片Bug

   现在，管理层强迫/匆忙将新芯片推向市场，在芯片中留下bug的可能性更高(比过去高得多)。所以不要排除这种可能性。我已经偶然发现过几次了。通常尝试联系芯片制造商或检查其数据表的更新/勘误表和已知的错误列表。

Answer 2

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