Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark

[Xiaofan C. <xia...@gm...>]

On Sat, Jul 16, 2011 at 10:55 AM, Xiaofan Chen <xia...@gm...> wrote:
> On Sat, Jul 16, 2011 at 10:31 AM, Xiaofan Chen <xia...@gm...> wrote:
>
>> Actually the result is pretty close for the LPC-P2148 based test.
>> jtag_khz = 1500 KHz, 38.927 KiB/s (ftd2xx) versus 38.754 KiB/s.
>>
>
> The above is for Amontec JtagKey2 which is high speed USB.
>
> The J-Link under OpenOCD (full speed USB but with intelligence
> in it) seems much slower than Amontec JtagKey2. The speed
> is 18.813 KiB/s at the same 1500KHz jtag_khz for J-Link (V6, IAR OEM).
>

On the other hand, J-Link can be much faster when not using
OpenOCD but Segger's own gdb server. So OpenOCD has a
long way to go to match that one.
Reference:
http://www.yagarto.de/projects/jtagspeed/index.html

Other historical reference, it seems OpenOCD is getting
faster and faster with each release. So it is good.
http://comments.gmane.org/gmane.comp.debugging.openocd.devel/7425

Overall, I think Øyvind Harboe's thoughts are good.
https://lists.berlios.de/pipermail/openocd-development/2010-October/016724.html

"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.

>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."


-- 
Xiaofan