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? > While this may be useful for a "i only need this once"-occasion to > unbrick some hardware, it will be annoyingly slow even for "JTAG > beginners" to really use. Well, with me knowing too little about JTAG just 3-4 days ago, and knowing much more now, I understand why UART-based adapters are few. But for outsider, that looks like a suspicious gap, and with "far-fetched mode on" (please don't take anything personally of course ;-) ), "patronizing" and "conspiracy" thoughts come to mind ;-). It definitely won't do to flash 2Gb chip via it, but slow access has its usecases too: 1) Learning, which can't be underestimated. And as I wrote in another mail, I came to conclusion I'd really wish OpenOCD could be used for that too, instead of spawning gazillion tools which just fragment community (Example? Easy: https://github.com/mchck/mchck/pull/73 How'd you imagine that nRF51 support is buried deep inside crappy ruby programmer written for yet another random board?) 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. > > There are enough MCUs and cheap starter boards out here that support > direct USB (STM32 discovery, newer Arduino using Atmega32U4 etc.), so > a good, high-performance USB protocol (which means queueing data and > block transfer, not remote bitbang) would be the way to go IMHO. As > soon as there is an open-source implementation for this, porting to > different CPUs should not be difficult. 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". > > I wonder if one of the existing HLA protocols might be useable. > > Now I do not want to stop anyone from providing patches that > implement a serial protocol, but in my opinion, the spent time would > yield a much better result if it went into a real USB implementation, > with enough abstraction that it can be used on STM32, ATMega etc.. > with different USB stacks used. Efficient USB abstraction is on my todo list, hope to get to it in 2-3 years. So far, even (efficient, always efficient) GPIO abstraction is not complete. > > 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
