Re: timeouts on USB ISP programmer

On Fri, Apr 8, 2022 at 6:04 PM Tomek CEDRO <tomek@cedro.info> wrote:
> This is not the problem. It uses "real USB mode" to transport commands
> between PC and FT2232 too. Most of those Programmer dongles uses
> Virtual-COM-Port-over-USB (aka VCP / USB CDC). No matter if you use
> dedicated IC like FT2232H that you can simply put in your design and
> control with a predefined command sequences using libraries like
> LibUSB+LibFTDI, or you use a microcontroller with embedded USB Device
> silicon that puts additional burden on you to create a base firmware
> for that in the first place just then to get the commands to control
> it like FT2232.
>
> Using FT2232H is cheaper when you consider firmware + software
> developer time cost and you need no extra functionalities beyond GPIO
> control. This is really powerful chip and I still keep my KT-LINK in
> my backpack every day :-)

Just a curiosity, if you wonder what is the difference between generic
FT2232 and MCU+USB, then in practice you can construct almost any
protocol on both, the difference is overall speed.

However, you need to send single commands to FT2232 to control its
GPIO, that goes over USB with a predefined latency, and that low level
USB protocol latency is a killer bottleneck that limits the overall
interface speed. It depends on the USB Transfer mode and with LibUSB
1.0 asynchronous operations showed up but still the USB latency is the
limit here. Especially when you bitbang single GPIO pins, change input
to output, send small chunks of data, etc, that results in kHz/Kbps
speed.

On the other hand with MCU+USB design you are limited only with the
GPIO port speed (usually single MHz/Mbps). There may be even
on-silicon peripherals like SPI with speeds far greater than GPIO
itself (tens or hundreds of MHz/Mbps). But you need to create a
firmware that will handle on-silicon USB Device peripheral and then
some protocol between PC and the MCU. Then you send high-level command
quickly to the MCU, the firmware handles the bit operations, and MCU
returns single or packed data with higher USB utilization.

If you go down below to the silicon, for instance in ARM-Cortex, you
will notice that Debug Ports can access almost any peripheral inside
MCU including RAM and Flash. However, handling on-chip Flash Memory
from the DP is different and more complicated than handling it by the
CPU itself. CPU has fast access to simply read/write Flash Memory. DP
needs to perform dozens of operations at low level to drive Flash
Controller in the first place. RAM is usually mapped to the main bus
and can be written even faster than Flash. This is why in modern
solutions like Open-Sourcee OpenSDA/DAPLink and commercial Interfaces
so called Flash Algorithms are used. At first Interface detects the
Target MCU, then it uploads chunk of binary (so called Flash
Algorithm) to RAM, then FlashAlgo takes over the CPU and control the
flashing process from within the MCU. This is the fastest possible
way. PC with dedicated software called Debug Bridge like pyOCD or
OpenOCD connects to Debug Probe over USB, that connects to MCU Debug
Port over GPIO, that launches FlashAlgo binary from MCU's RAM, then
Debug Bridge simply sends request and takes data to/from FlashAlgo
(for instance using CMSIS-DAP protocol).

Kind of interesting :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info