On Tue, Oct 19, 2010 at 8:38 AM, Peter Stuge <pe...@stuge.se> wrote: > Laurent Gauch wrote: >> That's a real good point for Rowley Crossworks >> http://www.rowley.co.uk/arm/index.htm and Amontec JTAGkey Series >> http://www.amontec.com . Note, with the use of Amontec JTAGkey-2 based >> on high-speed USB, Rowley Crossworks becomes still a lot faster since >> the USB latency go form 1ms to 125us. > > Any real solution just has to give up trying to run this from the PC. > It's stupid. I think some dongles do more or less of it already. > FT2232 obviously does not do it at all, whether full or high speed. > The USB-Blaster CPLD seems to be slightly more clever, but is not > quite fully utilized. > > A PC is USELESS for any kind of bitbanging or the like (MPSSE in crap > FTDI chips counts just the same!) - there are *at least* THREE bus > masters between CPU and IO pin, and you want it to be fast? Come on.. > > Anything sensible will just use a higher level protocol and a more > intelligent hardware. Life will be good. The Versaloon is the only > sensible dongle at reasonable cost I have seen so far. Simple > no-nonsense design and great support from Simon. I recommend it to > everyone. A bit of integration with OpenOCD may still be missing but > that can not be too difficult. > > Best of all - even the firmware for the adapter itself is open source!
Actually I'd like to put in a word for the original OpenOCD design insight. What OpenOCD does is to queue up lots of reads and writes. The solution to handling post-processing of data read in are callbacks. As long as the C code does not have to take conditional action on the returned result, this can mean long read/write sequences without a turnaround. I didn't look too carefully at the #'s that were posted, but I believe that the there were some >100kBytes/s for ST and an FTDI dongle in there somewhere, i.e. long latency interface and good throughput. Somebody just has to step up and do the work to profile the Cortex-M3 flash programming case and rewrite the higher level codes and performance should be dramatically improved. There are USB dongles out there that has a CPU sitting on the JTAG adapter, e.g. Segger but that requires work on the firmware as you point out. From a maintenance point of view, I believe it would be *MUCH* more economical to simply fix the higher level OpenOCD code to be more robust towards longer latencies. That code can be tested on *all* interfaces. If OpenOCD can get maintainable code that runs at > 50% maximum theoretical throughput, then I think we should be very pleased. More performance is better, but at >50% throughput, I wouldn't trade much for reduced maintainability. ZY1000 does it slightly differently: simply put it runs OpenOCD & Linux on the unit and has direct access to the hardware accelerated FPGA registers, very, very low latency. That said, I'm sure it would benefit from the higher level performance bottlenecks being sorted out. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
