Hello, On Sun, 20 Oct 2013 20:41:26 +0200 Michael Schwingen <[email protected]> wrote:
> On 10/20/2013 07:44 PM, Paul Sokolovsky wrote: > > Hello, > > > > On Sun, 20 Oct 2013 16:28:59 +0200 > > Michael Schwingen <[email protected]> wrote: > > > >> On 10/20/2013 02:57 PM, Paul Fertser wrote: > >>> Doesn't remote_bitbang that's already mainline fit all your > >>> requirements? Just use socat to redirect a unix or tcp socket to > >>> your serial port and you should be good to go. See > >>> tools/remote_bitbang/ for an example client. HTH > >> If this really takes off (ie. when there are embedded boards that > >> make use of this), an option to directly access a serial port in > >> the bitbang code without using socat might be useful. > >> > >> Apart from the ease-of-implementation, I am not very fond of serial > >> ports for JTAG or SWD - it is slow, and basing a new protocol or > >> implementation on an outdated interface does not seem smart to me. > > I love that "outdated". How about "oxygen is outdated, because we > > have plutonium now"? ;-) Isn't UART is just basic, popular > > interface, with more fast and advanced available, but that's all? > > I really like RS232 for configuration and debug messages. > The problem is that no modern PC has serial ports. Adding a > USB-to-serial adapter makes it worse than running native USB on the > microcontroller. > > If you start a new project, why waste time on designing it around a > RS-232 interface, with the added problem that you need to tell people > to buy an additional adapter? > > Microcontrollers with native USB support are available, USB stacks are > available for free, so why bother with RS-232 when it provides no > benefits, but has serious drawbacks *for this application*? Not all MCUs have USB. Not all have even UART. But UART is a simple protocol, and can be easily bitbanged. 1Mhz is enough to do 9600 on RISCish CPU. That means that just almost *any* CPU can support that, and do JTAG in our context. People usually optimize for speed. I want to go in completely orthogonal direction - optimize for accessibility. As for "additional adapter", almost every such board comes with USB/UART converter, and folks who work with board having raw UART, certainly have USB-UART adapter already. Now what you say tactically makes sense, but strategically - not that much. It doesn't bring magic of "supports everything". Then it tries to optimize for speed, but there're already adapters optimized for speed. If you need just speed, you can get one of the existing supported adapters. Again, I'm trying to solve orthogonal issue - "how to make sure you can always get JTAG with any handy device". These orthogonal axes allow to cover JTAG area completely, and that's what I'd like to achieve too - to make sure that everyone doesn't have any difficulties to use JTAG, or any excuses not to use it. > > > 2) Generally, slowness depends on how smart firmware is. Again, that > > was just "level 0" protocol. I just want to start from start, and > > let other people easy start up too, then scratch their further itch > > as needed. For example, one of usecase I have in mind is just kind > > of "virtual terminal" to receive Linux boot messages via ARM > > semihosting. "Run and wait for debug event" command would be good > > "level 2" one. > Not really. > > I regularly use a parallel-port adapter (yes, I still have one of > those on my PCs) to flash parallel flash roms on IXP425 CPUs. With all > acceleration (ie. maximum JTAG clock, and the flash algorithm running > on the target), this gets to about 10KiB/s. That doesn't contradict what I said. Any bulk transfer will be slow (gosh, transfer of 2Gb is slow with USB either! USB3 JTAG anyone? ;-) ). Flashing is not the only usecase for JTAG though. [] > > That's optimistic outlook, but I don't know on what it's based. To > > reiterate, there's no even a basic bitbanging protocol which > > is implemented across the boards. How many are there open-source USB > > stacks at all, and how consistent their APIs are? All in all, > > writing such protocol is big detour from "I just finally want to > > try that board with JTAG". > It is the same with a serial port: no such implementation exists now. > The detour may be a bit shorter, but not by much. Well, I have that covered, I really didn't want to start completely theoretical discussion. But I just didn't want to overload initial mail with pointing to specific prototype, because I first wanted to make sure that overall approach is OK. So, I have a prototype which works and written in (completely) MCU-independent manner: https://github.com/pfalcon/simplejtag/blob/master/simplejtag_l0.cpp As soon as support for GPIO of new MCU is added, it can just work. To achieve that (efficiently), C++ metaprogramming techniques are used. Now you see why I started with talking about defining protocol first - that's all what's needed on OpenOCD side. But on firmware side, I actually strive for the same generality, and single source (but multiple configs of course) covers MSP430, AVR, STM32, EFM32, LM4 so far - with the price of C++. Of course, that's just one possible implementation of protocol, someone can write Arduino-specific "sketch" for that, use TI's CCS bloat for MSP430, churn STM32 Peripheral Library etc., etc. > > cu > Michael > -- Best regards, Paul mailto:[email protected] ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
