From nobody Fri Apr 08 16:35:09 2022 X-Original-To: hardware@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 92EA7180A9DE for ; Fri, 8 Apr 2022 16:35:29 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZkPr1DpSz3BxD for ; Fri, 8 Apr 2022 16:35:27 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-dacc470e03so10256857fac.5 for ; Fri, 08 Apr 2022 09:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9MI5FFuBww6tQJb3C0CWsdpr+5+/u6ZMO9f42oHuzQQ=; b=fF1WaaEo98F3huZKx4x6+mpZ6eELZNSMtzkjgbtZRDDiJAx+cmHAqGAhULobpsrtmL L8pcW5QYuIKCOfryz6rOstE6OaRBgNIP2XaiHrtPDIZIjbO1IXTkt5KJjMn1SiRDljQS KXJ9pS2MRzCmCt8+Vy8RzdNnfxGKOZbChM2tfs2jE3XcSSMpiCEmwOM3PTuzZm8fAcjn J633r/D6J2fGKbHxI5g0QzmFyn5wNWRz/4a21zGEp/0u97rxA+U1MlnsI+q93/Wdsofd aVq6J4n6sbMu55+K5784KT1vRmNeynfC6jgdxlqfk8dfRaQ/VNOh/txe33pdLnvU+z1K C9hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9MI5FFuBww6tQJb3C0CWsdpr+5+/u6ZMO9f42oHuzQQ=; b=7oqGqHa0V5rqowUdLVQhtii5iiNlDw5k+jOKTwMGx9ksPOUuIZVCx65VQwt4i1P0aI Q7QJAo0ZHMJbliSN2JtskxzS9D1Kqu7b6iOLTs47MmLoTwwizSECK7hI9vCkAFidzQ8t RmCU6uygQOt925z/WueqG2bXkag909MDgaKqtTnw2gl1uNN8ryfDPojKqAnXhNNgIn7a brSj+4kcxYudJDtq1yLwEJPWUYXJxuWYu9SOUfPI0YAhtuFnpCQ+0DVfUPBo8Hjd/Nsy NbShT/ua9LRcxrIyv1G3mV6lzwjVtuHaOJaWil3WWBD138DXx68PGjeiNVlA2fA/DQHb DZwQ== X-Gm-Message-State: AOAM530JuHGIUIyI5UfpaZVZ7o6BcjzZkRO7kapVwll5T9wjOQSGHuwd O6a/PomRMlNWtJlUymafBtcEy1rRmxc7efux X-Google-Smtp-Source: ABdhPJyZT8C0YQ1JLrPztLsYh3rl3Krrc3LRyrfwuwcJqSdovQdS937t0951grpjl4iS52NXIxtzFA== X-Received: by 2002:a05:6870:4205:b0:e1:e110:3ad2 with SMTP id u5-20020a056870420500b000e1e1103ad2mr9068153oac.27.1649435721532; Fri, 08 Apr 2022 09:35:21 -0700 (PDT) Received: from mail-oo1-f51.google.com (mail-oo1-f51.google.com. [209.85.161.51]) by smtp.gmail.com with ESMTPSA id r129-20020acac187000000b002ef358c6e0esm8732458oif.49.2022.04.08.09.35.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Apr 2022 09:35:21 -0700 (PDT) Received: by mail-oo1-f51.google.com with SMTP id l24-20020a4a8558000000b00320d5a1f938so1564976ooh.8 for ; Fri, 08 Apr 2022 09:35:21 -0700 (PDT) X-Received: by 2002:a4a:dd15:0:b0:320:da3c:c342 with SMTP id m21-20020a4add15000000b00320da3cc342mr6435227oou.7.1649435720784; Fri, 08 Apr 2022 09:35:20 -0700 (PDT) List-Id: General discussion of FreeBSD hardware List-Archive: https://lists.freebsd.org/archives/freebsd-hardware List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hardware@freebsd.org MIME-Version: 1.0 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> <7CDFB049-241F-4C31-A7B1-A7D6BDE6A002@Chaos1.DE> In-Reply-To: From: Tomek CEDRO Date: Fri, 8 Apr 2022 18:35:09 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: timeouts on USB ISP programmer To: hardware@freebsd.org Cc: Axel Rau , Hans Petter Selasky Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KZkPr1DpSz3BxD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=fF1WaaEo; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2001:4860:4864:20::2b) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hardware@freebsd.org]; DMARC_NA(0.00)[cedro.info]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::2b:from,209.85.161.51:received]; MLMMJ_DEST(0.00)[hardware]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 8, 2022 at 6:04 PM Tomek CEDRO 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