Date: Fri, 8 Apr 2022 18:35:09 +0200 From: Tomek CEDRO <tomek@cedro.info> To: hardware@freebsd.org Cc: Axel Rau <Axel.Rau@chaos1.de>, Hans Petter Selasky <hps@selasky.org> Subject: Re: timeouts on USB ISP programmer Message-ID: <CAFYkXjmK5y8EX33QUc-sZwjBntpROiWVJb7ja_dR8%2BHwdvEgLw@mail.gmail.com> In-Reply-To: <CAFYkXjnwvba60u3_tRMReEiyb5dohNZDLoenZWieNB2q_c_-0w@mail.gmail.com> References: <3A781DFA-1E2C-41A5-8053-C90A806244DC@Chaos1.DE> <34a747ea-2ee5-660f-71c6-dc00d5de337f@selasky.org> <9334c4f0-3ecf-c046-420f-516e39379981@selasky.org> <976BDBEB-8B57-4541-A0B7-3F2C89498DC6@Chaos1.DE> <7190bdde-22bc-79ee-06d0-d0114a3ffbad@selasky.org> <CAFYkXj=HMdxZG%2B8x0gpLCDy8cbu_qOpFqcN37RO9EG=WOBHkqw@mail.gmail.com> <CAFYkXjmjnFX1a3%2BCQxAxdwX=-oASSEWLdzrmx=%2B4QbX3_Og2Gw@mail.gmail.com> <CAFYkXjmgLi0F4gLVWQxtVwS6tCXCni%2BxU2-7KQM4ve%2B%2B-aEiBw@mail.gmail.com> <CAFYkXjnG5uOzF5_BbNZUgzBzTN8hpU9RmTTh1h_KDZ0EonZgEQ@mail.gmail.com> <CAFYkXjnbneNUszR8ZwS50xY8924uvCQyYQ9d3ohT_t1HZrjmDw@mail.gmail.com> <CAFYkXjmf8DpZw5hQ6Cc_FBurHufKNHhKGYiXpK%2BArB0SGCbqsg@mail.gmail.com> <7CDFB049-241F-4C31-A7B1-A7D6BDE6A002@Chaos1.DE> <CAFYkXjnwvba60u3_tRMReEiyb5dohNZDLoenZWieNB2q_c_-0w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFYkXjmK5y8EX33QUc-sZwjBntpROiWVJb7ja_dR8%2BHwdvEgLw>