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*? > 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. Now if you tune that down even by a factor 10 (which I think is reasonable for the slower speed on the RS-232, plus the overhead of the serial protocol), you get to 1Kib/s - even flashing a 128KiB bootloader takes more than 2 Minutes, not even talking about a rootfs or linux kernel. Single-stepping in a source-level debugger (which is the main purpose for which OpenOCD was written) will be too slow to be useful even for rare useage (my colleagues think it is already too slow using the parallel port adapter - however, they are used to BDI2000 interfaces which are a lot faster). > 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. cu Michael ------------------------------------------------------------------------------ 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
