Bitbang is slow

[RHSResearchLLC]

Currently running at ~300K Baud, due to data stall during write that appears to be inherent in the chip. Currently following up with FTDI and will update this issue as FTDI responds.

[swarren]

My guess: The FTDI is connected to the host via USB2. USB2 has an 8KHz frame rate, which translates to 125us per frame. Perhaps the xvcd protocol is performing "round trip" transactions (reading then writing then reading then writing, so waiting for a USB frame to complete each time), or simply isn't batching up enough write transactions at one go to stream multiple write packets to the device in one USB frame (I can't remember if multiple packets can be transferred to the device in a single frame in the USB protocol). So, what you're seeing is roughly 25us of time to write the data and then waiting 100us until the USB frame is over before the next write happens, repeatedly.

[swarren]

Oh, and the 64 comes from:

Bus 001 Device 002: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Device Descriptor:
  Configuration Descriptor:
    Interface Descriptor:
      Endpoint Descriptor:
        wMaxPacketSize     0x0040  1x 64 bytes

[makslevental]

Is there any update on this?

[RHSResearchLLC]

Not really- except that using OpenOCD is much faster than using Vivado to program the flash

…

On Sat, Feb 5, 2022, 7:03 AM Maksim Levental ***@***.***> wrote: Is there any update on this? — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3OOAFG3GQYNRW5OCRXDW3UZUG2RANCNFSM4ECXGNUQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>