openocd-devel

[Openocd-development] OpenOCD libftdi and ftd2xx benchmark

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

On Wed, Jul 13, 2011 at 10:55 PM, Xiaofan Chen <xia...@gm...> wrote:
> Under Linux, ftd2xx 1.04 (based on libusb-1.0.8) does not seem to offer
> any advantage than libftdi (tested with 0.19)

This is the same as reported last time.

> mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd-d2xx -f
> board/ek-lm3s1968.cfg
> Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:28)
> Licensed under GNU GPL v2
> For bug reports, read
>        http://openocd.berlios.de/doc/doxygen/bugs.html
> Info : only one transport option; autoselect 'jtag'
> 500 kHz
> Error: unable to get latency timer: 0
> Error: ftd2xx 1.04 detected - this has known issues with
> FT_GetLatencyTimer, upgrade to a newer version
> Info : device: 4 "2232C"
> Info : deviceID: 67353817
> Info : SerialNumber: 070200A1A
> Info : Description: Stellaris Evaluation Board A
> Info : clock speed 500 kHz
> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
> Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
> Info : accepting 'telnet' connection from 4444
> 500 kHz
> cortex_m3 reset_config sysresetreq
> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
> flash 'stellaris' found at 0x00000000
> auto erase enabled
> wrote 262144 bytes from file ./demo.bin in 50.572987s (5.062 KiB/s)
> 500 kHz
> cortex_m3 reset_config sysresetreq
> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
> 1200 kHz
> flash 'stellaris' found at 0x00000000
> auto erase enabled
> wrote 262144 bytes from file ./demo.bin in 42.674957s (5.999 KiB/s)
> ^C
>
> mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd -f board/ek-lm3s1968.cfg
> Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:21)
> Licensed under GNU GPL v2
> For bug reports, read
>        http://openocd.berlios.de/doc/doxygen/bugs.html
> Info : only one transport option; autoselect 'jtag'
> 500 kHz
> Info : clock speed 500 kHz
> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
> Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
> Info : accepting 'telnet' connection from 4444
> 500 kHz
> cortex_m3 reset_config sysresetreq
> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
> 1200 kHz
> flash 'stellaris' found at 0x00000000
> auto erase enabled
> wrote 262144 bytes from file ./demo.bin in 42.677986s (5.998 KiB/s)
> ^C

Then I did similar test under Windows with libftdi-0.19 (with
Liminary's FTDI driver
and libusb-win32 filter driver). The speed is faster than under Linux. Kind of
interesting. I will try the ftd2xx Windows build later.

D:\work\openocd\build_cxf\openocd_14Jul2011_mingw32\bin>openocd.exe -f
board\ek-lm3s1968.cfg
Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc-dirty (2011-07-14-21:37)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file ./demo.bin in 11.093000s (10.908 KiB/s)

-- 
Xiaofan

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

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

On Thu, Jul 14, 2011 at 10:47 PM, Xiaofan Chen <xia...@gm...> wrote:
> Then I did similar test under Windows with libftdi-0.19 (with
> Liminary's FTDI driver
> and libusb-win32 filter driver). The speed is faster than under Linux. Kind of
> interesting. I will try the ftd2xx Windows build later.
>
> D:\work\openocd\build_cxf\openocd_14Jul2011_mingw32\bin>openocd.exe -f
> board\ek-lm3s1968.cfg
> Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc-dirty (2011-07-14-21:37)
> Licensed under GNU GPL v2
> For bug reports, read
>        http://openocd.berlios.de/doc/doxygen/bugs.html
> Info : only one transport option; autoselect 'jtag'
> 500 kHz
> Info : clock speed 500 kHz
> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
> Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
> Info : accepting 'telnet' connection from 4444
> 500 kHz
> cortex_m3 reset_config sysresetreq
> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
> 1200 kHz
> flash 'stellaris' found at 0x00000000
> auto erase enabled
> wrote 123904 bytes from file ./demo.bin in 11.093000s (10.908 KiB/s)
>

Interestingly increasing the jtag_khz value does not help too much.
This is with a different PC and with Freddie Chopin's binary but the
result is similar.

C:\cygwin\home\xfchen\openocd\openocd-0.5.0-rc1\tcl\bin>openocd-0.5.0-rc1.exe
-f board\ek-lm3s1968.cfg
Open On-Chip Debugger 0.5.0-dev (2011-07-11-21:12)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0x
ba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001df0c msp: 0x20000300
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.984515s (11.016 KiB/s)
6000 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.499905s (11.524 KiB/s)

-- 
Xiaofan

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

[Freddie C. <fre...@op...>]

On 2011-07-15 10:29, Xiaofan Chen wrote:
> Interestingly increasing the jtag_khz value does not help too much.
> This is with a different PC and with Freddie Chopin's binary but the
> result is similar.

Most probably you reached the limit with flash programming. To test just 
the throughput you could try uploads to RAM.

4\/3!!

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

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

On Fri, Jul 15, 2011 at 4:32 PM, Freddie Chopin <fre...@op...> wrote:
> On 2011-07-15 10:29, Xiaofan Chen wrote:
>>
>> Interestingly increasing the jtag_khz value does not help too much.
>> This is with a different PC and with Freddie Chopin's binary but the
>> result is similar.
>
> Most probably you reached the limit with flash programming. To test just the
> throughput you could try uploads to RAM.

You are probably right.

I have not built the latest binary with ftd2xx. So I used your 0.4.0 binary
and the d2xx 0.4.0 binary I built last time.

The speed is basically the same for libftdi and d2xx in this case
(10.760KB/sec versus 10.900 KB/sec at jtag_khz=1200 KHz)

D:\work\openocd\binary_chopin\OpenOCD\0.4.0\bin>openocd.exe -f
board/ek-lm3s1968.cfg
Open On-Chip Debugger 0.4.0 (2010-02-22-19:05)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
3000 kHz
jtag_nsrst_delay: 100
srst_only separate srst_gates_jtag srst_open_drain
Info : clock speed 3000 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 0
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001df88 msp: 0x20000200
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
Warn : not enough working area available(requested 8192, free 8152)
wrote 123904 bytes from file demo.bin in 11.245000s (10.760 kb/s)
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)

D:\work\openocd\binary_chopin\OpenOCD\0.4.0\bin>openocd_d2xx -f
board/ek-lm3s1968.cfg
Open On-Chip Debugger 0.4.0 (2010-09-13-20:47)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
3000 kHz
jtag_nsrst_delay: 100
srst_only separate srst_gates_jtag srst_open_drain
Info : device: 4 "2232C"
Info : deviceID: 67353817
Info : SerialNumber: 070200A1A
Info : Description: Stellaris Evaluation Board A
Info : clock speed 3000 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 0
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001df0c msp: 0x20000300
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
Warn : not enough working area available(requested 8192, free 8152)
wrote 123904 bytes from file demo.bin in 11.101000s (10.900 kb/s)
6000 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
Warn : not enough working area available(requested 8192, free 8152)
wrote 123904 bytes from file demo.bin in 10.358000s (11.682 kb/s)



-- 
Xiaofan

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

[Laurent G. <lau...@am...>]

>
> On Wed, Jul 13, 2011 at 10:55 PM, Xiaofan Chen <xiaofanc at gmail.com <https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote:
> >/ Under Linux, ftd2xx 1.04 (based on libusb-1.0.8) does not seem to offer
> />/ any advantage than libftdi (tested with 0.19)
> /
> This is the same as reported last time.
>
> >/ mcuee at Ubuntu <https://lists.berlios.de/mailman/listinfo/openocd-development>:~/Desktop/build/openocd/lm3s1968$ openocd-d2xx -f
> />/ board/ek-lm3s1968.cfg
> />/ Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:28)
> />/ Licensed under GNU GPL v2
> />/ For bug reports, read
> />/        http://openocd.berlios.de/doc/doxygen/bugs.html
> />/ Info : only one transport option; autoselect 'jtag'
> />/ 500 kHz
> />/ Error: unable to get latency timer: 0
> />/ Error: ftd2xx 1.04 detected - this has known issues with
> />/ FT_GetLatencyTimer, upgrade to a newer version
> />/ Info : device: 4 "2232C"
> />/ Info : deviceID: 67353817
> />/ Info : SerialNumber: 070200A1A
> />/ Info : Description: Stellaris Evaluation Board A
> />/ Info : clock speed 500 kHz
> />/ Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> />/ 0x23b, part: 0xba00, ver: 0x3)
> />/ Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
> />/ Info : accepting 'telnet' connection from 4444
> />/ 500 kHz
> />/ cortex_m3 reset_config sysresetreq
> />/ Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> />/ 0x23b, part: 0xba00, ver: 0x3)
> />/ target state: halted
> />/ target halted due to debug-request, current mode: Thread
> />/ xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
> />/ flash 'stellaris' found at 0x00000000
> />/ auto erase enabled
> />/ wrote 262144 bytes from file ./demo.bin in 50.572987s (5.062 KiB/s)
> />/ 500 kHz
> />/ cortex_m3 reset_config sysresetreq
> />/ Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> />/ 0x23b, part: 0xba00, ver: 0x3)
> />/ target state: halted
> />/ target halted due to debug-request, current mode: Thread
> />/ xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
> />/ 1200 kHz
> />/ flash 'stellaris' found at 0x00000000
> />/ auto erase enabled
> />/ wrote 262144 bytes from file ./demo.bin in 42.674957s (5.999 KiB/s)
> />/ ^C
> />/
> />/ mcuee at Ubuntu <https://lists.berlios.de/mailman/listinfo/openocd-development>:~/Desktop/build/openocd/lm3s1968$ openocd -f board/ek-lm3s1968.cfg
> />/ Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:21)
> />/ Licensed under GNU GPL v2
> />/ For bug reports, read
> />/        http://openocd.berlios.de/doc/doxygen/bugs.html
> />/ Info : only one transport option; autoselect 'jtag'
> />/ 500 kHz
> />/ Info : clock speed 500 kHz
> />/ Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> />/ 0x23b, part: 0xba00, ver: 0x3)
> />/ Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
> />/ Info : accepting 'telnet' connection from 4444
> />/ 500 kHz
> />/ cortex_m3 reset_config sysresetreq
> />/ Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> />/ 0x23b, part: 0xba00, ver: 0x3)
> />/ target state: halted
> />/ target halted due to debug-request, current mode: Thread
> />/ xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
> />/ 1200 kHz
> />/ flash 'stellaris' found at 0x00000000
> />/ auto erase enabled
> />/ wrote 262144 bytes from file ./demo.bin in 42.677986s (5.998 KiB/s)
> />/ ^C
> /
> Then I did similar test under Windows with libftdi-0.19 (with
> Liminary's FTDI driver
> and libusb-win32 filter driver). The speed is faster than under Linux. Kind of
> interesting. I will try the ftd2xx Windows build later.
>
> D:\work\openocd\build_cxf\openocd_14Jul2011_mingw32\bin>openocd.exe -f
> board\ek-lm3s1968.cfg
> Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc-dirty (2011-07-14-21:37)
> Licensed under GNU GPL v2
> For bug reports, read
>         http://openocd.berlios.de/doc/doxygen/bugs.html
> Info : only one transport option; autoselect 'jtag'
> 500 kHz
> Info : clock speed 500 kHz
> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
> Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
> Info : accepting 'telnet' connection from 4444
> 500 kHz
> cortex_m3 reset_config sysresetreq
> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
> 1200 kHz
> flash 'stellaris' found at 0x00000000
> auto erase enabled
> wrote 123904 bytes from file ./demo.bin in 11.093000s (10.908 KiB/s)
>
> -- 
> Xiaofan
>   
Do you have a Amontec JTAGkey-2 (High-speed USB 2.0) ?

If yes, please do the same comparaison with libusb and d2xx on Linux and 
windows, and with the Amontec JTAGkey D2XX device driver package WHQL 
certified .

Regards,
Laurent
 http://www.amontec.com/jtagkey.shtml

> ------------------------------------------------------------------------

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

[Yegor Y. <yeg...@go...>]

Hi Laurent,

> Do you have a Amontec JTAGkey-2 (High-speed USB 2.0) ?
>
> If yes, please do the same comparaison with libusb and d2xx on Linux and
> windows, and with the Amontec JTAGkey D2XX device driver package WHQL
> certified .

I would also like to have Amontec JTAGkey-2 and test the speed
compared to my LM3S811 solution. I already ordered one and already
payed for it in advance as you know (order nr: 110606008, cust.-nr.
6823), but still I don't have the device and your company doesn't
answer on my e-mails or phone calls. I try to contact since mid of
June. Could you please shed light on this matter? It is my first
experience, that the company behaves in such a way. I hope it is just
misunderstanding.

Sorry for using mailings list for this matter, but I see no other way.

Best regards,
Yegor

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

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

On Fri, Jul 15, 2011 at 5:36 PM, Laurent Gauch
<lau...@am...> wrote:
> Do you have a Amontec JTAGkey-2 (High-speed USB 2.0) ?

Yes.

> If yes, please do the same comparaison with libusb and d2xx on Linux and
> windows, and with the Amontec JTAGkey D2XX device driver package WHQL
> certified .

No problem. I will do it after I build the d2xx binary for Windows.

-- 
Xiaofan

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

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

On Fri, Jul 15, 2011 at 6:02 PM, Xiaofan Chen <xia...@gm...> wrote:
> On Fri, Jul 15, 2011 at 5:36 PM, Laurent Gauch
> <lau...@am...> wrote:
>> Do you have a Amontec JTAGkey-2 (High-speed USB 2.0) ?
>
> Yes.
>
>> If yes, please do the same comparaison with libusb and d2xx on Linux and
>> windows, and with the Amontec JTAGkey D2XX device driver package WHQL
>> certified .
>
> No problem. I will do it after I build the d2xx binary for Windows.
>

Anyway here is the test with libftdi driver first.

I think Freddie is probably right. There is still a bit of bump compared to the
on-board ftdi2232C based Luminary-ICDI interface.

jtag_khz = 1200 KHz, 11.820 KiB/s versus 11.016 KiB/s
jtag_khz = max supported, 12.729 KiB/s versus 11.524 KiB/s

D:\work\openocd\binary_chopin\openocd-0.5.0-rc1\tcl\bin>openocd-0.5.0-rc1.exe
-f ek-lm3s1968_jtagkey2.cfg
Open On-Chip Debugger 0.5.0-dev (2011-07-11-21:12)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001df0c msp: 0x20000300
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.237000s (11.820 KiB/s)
3000 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 9.506000s (12.729 KiB/s)


-- 
Xiaofan

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

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

On Fri, Jul 15, 2011 at 6:29 PM, Xiaofan Chen <xia...@gm...> wrote:
> On Fri, Jul 15, 2011 at 6:02 PM, Xiaofan Chen <xia...@gm...> wrote:
>> On Fri, Jul 15, 2011 at 5:36 PM, Laurent Gauch
>> <lau...@am...> wrote:
>>> Do you have a Amontec JTAGkey-2 (High-speed USB 2.0) ?
>>
>> Yes.
>>
>>> If yes, please do the same comparaison with libusb and d2xx on Linux and
>>> windows, and with the Amontec JTAGkey D2XX device driver package WHQL
>>> certified .
>>
>> No problem. I will do it after I build the d2xx binary for Windows.
>>
>
> Anyway here is the test with libftdi driver first.
>
> I think Freddie is probably right. There is still a bit of speed bump compared to the
> on-board ftdi2232C based Luminary-ICDI interface.
>
> jtag_khz = 1200 KHz, 11.820 KiB/s versus 11.016 KiB/s
> jtag_khz = max supported, 12.729 KiB/s versus 11.524 KiB/s (10% faster)

For the USB 2.0 Jtagkey2, using the WHQL driver and ftd2xx is
only about 5% faster than using libftdi and libusb-win32 filter driver
on top of the WHQL driver.

jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s
(libftdi), (4.7% faster)
jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.096 KiB/s
(libftdi), (5.2% faster)

Probably I will try another target to see the flash download difference.

D:\work\openocd\build_cxf\openocd_15Jul2011\bin>openocd_libftdi_mingw.exe
-f ek-lm3s1968_jtagkey2.cfg
Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-22:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001df0c msp: 0x20000300
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.712000s (11.296 KiB/s)
3000 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.003000s (12.096 KiB/s)

D:\work\openocd\build_cxf\openocd_15Jul2011\bin>openocd_mingw_d2xx.exe
-f ek-lm3s1968_jtagkey2.cfg
Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-21:46)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 53T9XDR4A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001df0c msp: 0x20000300
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.232000s (11.826 KiB/s)
3000 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 9.506000s (12.729 KiB/s)



-- 
Xiaofan

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

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

On Fri, Jul 15, 2011 at 10:28 PM, Laurent Gauch
<lau...@am...> wrote:
> Xiaofan Chen wrote:

>>> I think Freddie is probably right. There is still a bit of speed bump
>>> compared to the
>>> on-board ftdi2232C based Luminary-ICDI interface.
>>>
>>> jtag_khz = 1200 KHz, 11.820 KiB/s versus 11.016 KiB/s
>>> jtag_khz = max supported, 12.729 KiB/s versus 11.524 KiB/s (10% faster)
>>>
>>
>> For the USB 2.0 Jtagkey2, using the WHQL driver and ftd2xx is
>> only about 5% faster than using libftdi and libusb-win32 filter driver
>> on top of the WHQL driver.
>>
>> jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s
>> (libftdi), (4.7% faster)
>> jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.096 KiB/s
>> (libftdi), (5.2% faster)
>>
>> Probably I will try another target to see the flash download speed difference.

I think Freddie is right that the speed is rather limited by the Flash.

> On a USB 2.0 High-Speed port or under USB HUB full-speed ?

On a USB 2.0 High-Speed port. This is with a 3-year old PC running
Windows 7 Ultimate 32bit (Core 2 Duo E4700, 2GB RAM).

Output from USBView.
http://www.ftdichip.com/Support/Utilities.htm
Take note of the "Device Bus Speed:     High" and the
fact that bulk endpoint size is 512B.

Device Descriptor:
bcdUSB:             0x0200
bDeviceClass:         0x00
bDeviceSubClass:      0x00
bDeviceProtocol:      0x00
bMaxPacketSize0:      0x40 (64)
idVendor:           0x0403 (Future Technology Devices International Limited)
idProduct:          0xCFF8
bcdDevice:          0x0700
iManufacturer:        0x01
iProduct:             0x02
iSerialNumber:        0x03
bNumConfigurations:   0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed:     High
Device Address:       0x01
Open Pipes:              4

Endpoint Descriptor:
bEndpointAddress:     0x81  IN
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00

Endpoint Descriptor:
bEndpointAddress:     0x02  OUT
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00

Endpoint Descriptor:
bEndpointAddress:     0x83  IN
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00

Endpoint Descriptor:
bEndpointAddress:     0x04  OUT
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00


-- 
Xiaofan

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

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

Historical reference back in June 2009.

Under Linux, Dominic found no much difference between libftdi and ftd2xx.
https://lists.berlios.de/pipermail/openocd-development/2009-June/008846.html

My test results support this conclusion under Linux.

Under Windows, Freddie found that ftd2xx is significantly faster
than libftdi. I will try to use LPC-P2148 to see if that is still
the case now.

https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html
++++++++++++++++++++
Tested with a ~29kB image on LPC2103 (upload to flash):
libftdi:
 > Start address 0x3c, load size 29640
 > Transfer rate: 6 KB/sec, 14820 bytes/write.
ftd2xx:
 > Start address 0x3c, load size 29640
 > Transfer rate: 15 KB/sec, 14820 bytes/write.

So: libftdi is 2.5x slower
Tested with ~114kB image on STM32 (upload to flash):
libftdi:
 > Start address 0x8000134, load size 114432
 > Transfer rate: 8 KB/sec, 16347 bytes/write.
ftd2xx:
 > Start address 0x8000134, load size 114432
 > Transfer rate: 11 KB/sec, 16347 bytes/write.
Again slower, this time only about 30%, but still, that's nowhere to
"comparable"
++++++++++++

-- 
Xiaofan

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

[Spencer O. <sp...@sp...>]

On Jul 15, 2011 3:39 PM, "Xiaofan Chen" <xia...@gm...> wrote:
>
> Historical reference back in June 2009.
>
> Under Linux, Dominic found no much difference between libftdi and ftd2xx.
>
https://lists.berlios.de/pipermail/openocd-development/2009-June/008846.html
>
> My test results support this conclusion under Linux.
>
> Under Windows, Freddie found that ftd2xx is significantly faster
> than libftdi. I will try to use LPC-P2148 to see if that is still
> the case now.
>
>
https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html
> ++++++++++++++++++++
> Tested with a ~29kB image on LPC2103 (upload to flash):
> libftdi:
>  > Start address 0x3c, load size 29640
>  > Transfer rate: 6 KB/sec, 14820 bytes/write.
> ftd2xx:
>  > Start address 0x3c, load size 29640
>  > Transfer rate: 15 KB/sec, 14820 bytes/write.
>
> So: libftdi is 2.5x slower
> Tested with ~114kB image on STM32 (upload to flash):
> libftdi:
>  > Start address 0x8000134, load size 114432
>  > Transfer rate: 8 KB/sec, 16347 bytes/write.
> ftd2xx:
>  > Start address 0x8000134, load size 114432
>  > Transfer rate: 11 KB/sec, 16347 bytes/write.
> Again slower, this time only about 30%, but still, that's nowhere to
> "comparable"
> ++++++++++++
>

On some PC's I even found speed increase when running the jtag dongle
through an external powered USB hub.

Cheers
Spen

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

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

On Fri, Jul 15, 2011 at 10:24 PM, Xiaofan Chen <xia...@gm...> wrote:
>> I think Freddie is probably right. There is still a bit of speed bump compared to the
>> on-board ftdi2232C based Luminary-ICDI interface.
>>
>> jtag_khz = 1200 KHz, 11.820 KiB/s versus 11.016 KiB/s
>> jtag_khz = max supported, 12.729 KiB/s versus 11.524 KiB/s (10% faster)
>
> For the USB 2.0 Jtagkey2, using the WHQL driver and ftd2xx is
> only about 5% faster than using libftdi and libusb-win32 filter driver
> on top of the WHQL driver.
>
> jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s
> (libftdi), (4.7% faster)
> jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.096 KiB/s
> (libftdi), (5.2% faster)
>
> Probably I will try another target to see the flash download difference.
>

But I will finish the test under Linux first. Since I got not good result
under Ubuntu Linux (which still uses libusb-0.1), I switched to
Arch Linux which is usually a bit faster than Ubuntu (but Gnome
3 is in the same league as Unity, both are worse than Gnome 2).
I will probably go back to Ubuntu to see whether I might have
done something differently.

Then I get similar result as Windos under Linux. Interestingly
the speed is almost the same in Arch Linux as compared
to Windows 7. ftd2xx-1.04 is faster than libftdi-0.19 by
about 5%. That is what I expected since ftd2xx-1.04 uses
libusb-1.0.8's async API feature under Linux.

jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s
(libftdi), (4.7% faster)
jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.093 KiB/s
(libftdi), (5.2% faster)

[mcuee@myhost lm3s1968]$ openocd -f ek-lm3s1968_jtagkey2.cfg
Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3 (2011-07-16-08:25)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001df0c msp: 0x20000300
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.711820s (11.296 KiB/s)
3000 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.005830s (12.093 KiB/s)


[mcuee@myhost lm3s1968]$ openocd-d2xx -f ek-lm3s1968_jtagkey2.cfg
Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3 (2011-07-16-08:28)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Error: unable to get latency timer: 0
Error: ftd2xx 1.04 detected - this has known issues with
FT_GetLatencyTimer, upgrade to a newer version
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 53T9XDR4A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001df0c msp: 0x20000300
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.231838s (11.826 KiB/s)
3000 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 9.505806s (12.729 KiB/s)
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)


--
Xiaofan

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

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

On Sat, Jul 16, 2011 at 8:58 AM, Xiaofan Chen <xia...@gm...> wrote:
>> For the USB 2.0 Jtagkey2, using the WHQL driver and ftd2xx is
>> only about 5% faster than using libftdi and libusb-win32 filter driver
>> on top of the WHQL driver.
>>
>> jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s
>> (libftdi), (4.7% faster)
>> jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.096 KiB/s
>> (libftdi), (5.2% faster)
>>
> But I will finish the test under Linux first. Since I got not good result
> under Ubuntu Linux, ...,  I will probably go back to Ubuntu to see
> whether I might have done something differently.

I rebuilt everything (libusb-stuge, libftdi-1.0 and OpenOCD) under
Ubuntu 11.04 (to try out libftdi-1.0) and now the result under Ubuntu
is more in line with other test results. The test shows that
ftd2xx does not offer any advantages compared to libftdi
under this test.

On the other hand, after the higher level codes are sorted out,
then probably the lower level codes can be more important
in the future.

The test also shows OpenOCD's speed get better with bigger
binary size.

For smaller binary of 123904 Bytes.
jtag_khz = 1200 KHz, 11.294 KiB/s (ftd2xx) versus 11.296 KiB/s (libftdi)
jtag_khz = 3000 KHz, 12.080 KiB/s (ftd2xx) versus 12.086 KiB/s (libftdi)

For bigger binary of 262144 Bytes.
jtag_khz=3000 KHz, 17.518 KiB/s (ftd2xx) versus 17.520 KiB/s (libftdi)

mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd -f
luminary_jtagkey2.cfgOpen On-Chip Debugger
0.5.0-dev-00956-ge7269e3-dirty (2011-07-17-07:47)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001e340 msp: 0x20000200
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.711829s (11.296 KiB/s)
3000 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.011832s (12.086 KiB/s)
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 262144 bytes from file demobig.bin in 14.611854s (17.520 KiB/s)
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
shutdown command invoked

mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd-d2xx -f
luminary_jtagkey2.cfg
Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-17-07:48)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Error: unable to get latency timer: 0
Error: ftd2xx 1.04 detected - this has known issues with
FT_GetLatencyTimer, upgrade to a newer version
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 53T9XDR4A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0001df0c msp: 0x20000300
1200 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.713832s (11.294 KiB/s)
3000 kHz
flash 'stellaris' found at 0x00000000
auto erase enabled
wrote 123904 bytes from file demo.bin in 10.016835s (12.080 KiB/s)
auto erase enabled
wrote 262144 bytes from file demobig.bin in 14.613848s (17.518 KiB/s)
500 kHz
cortex_m3 reset_config sysresetreq
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
shutdown command invoked


-- 
Xiaofan

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

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

On Fri, Jul 15, 2011 at 10:38 PM, Xiaofan Chen <xia...@gm...> wrote:
> Historical reference back in June 2009.
> Under Windows, Freddie found that ftd2xx is significantly faster
> than libftdi. I will try to use LPC-P2148 to see if that is still
> the case now.
>
> https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html
> ++++++++++++++++++++
> Tested with a ~29kB image on LPC2103 (upload to flash):
> libftdi:
>  > Start address 0x3c, load size 29640
>  > Transfer rate: 6 KB/sec, 14820 bytes/write.
> ftd2xx:
>  > Start address 0x3c, load size 29640
>  > Transfer rate: 15 KB/sec, 14820 bytes/write.
>
> So: libftdi is 2.5x slower
> Tested with ~114kB image on STM32 (upload to flash):
> libftdi:
>  > Start address 0x8000134, load size 114432
>  > Transfer rate: 8 KB/sec, 16347 bytes/write.
> ftd2xx:
>  > Start address 0x8000134, load size 114432
>  > Transfer rate: 11 KB/sec, 16347 bytes/write.
> Again slower, this time only about 30%, but still, that's nowhere to
> "comparable"
> ++++++++++++

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.

D:\work\openocd\build_cxf\openocd_15Jul2011\bin>openocd_mingw_d2xx.exe
-f olimex_lpc_p2148_jtagkey2.cfg
Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-21:46)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
Warning - assuming default core clock 12MHz! Flashing may fail if
actual core clock is different.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
1500 kHz
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 53T9XDR4A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 1500 kHz
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787,
part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 4
Info : lpc2148.cpu: hardware has 2 breakpoint/watchpoint units
Info : accepting 'telnet' connection from 4444
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787,
part: 0xf1f0, ver: 0x4)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
Warn : NOTE! DCC downloads have not been enabled, defaulting to slow
memory writes. Type 'help dcc
Warn : NOTE! Severe performance degradation without fast memory access
enabled. Type 'help fast'.
fast memory access is enabled
dcc downloads are enabled
erased sectors 0 through 26 on flash bank 0 in 0.446000s
wrote 232748 bytes from file lpc2148.hex in 5.839000s (38.927 KiB/s)

D:\work\openocd\build_cxf\openocd_15Jul2011\bin>openocd_libftdi_mingw.exe
-f olimex_lpc_p2148_jtagkey2.cfg
Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-22:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
Warning - assuming default core clock 12MHz! Flashing may fail if
actual core clock is different.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
1500 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 1500 kHz
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787,
part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 4
Info : lpc2148.cpu: hardware has 2 breakpoint/watchpoint units
Info : accepting 'telnet' connection from 4444
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787,
part: 0xf1f0, ver: 0x4)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
Warn : NOTE! DCC downloads have not been enabled, defaulting to slow
memory writes. Type 'help dcc'
Warn : NOTE! Severe performance degradation without fast memory access
enabled. Type 'help fast'.
fast memory access is enabled
dcc downloads are enabled
erased sectors 0 through 26 on flash bank 0 in 0.446000s
wrote 232748 bytes from file lpc2148.hex in 5.865000s (38.754 KiB/s)

-- 
Xiaofan

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

[Peter S. <pe...@st...>]

Many thanks for making these tests! Awesome!

Xiaofan Chen 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.

So in conclusion there is almost no difference in performance between
OpenOCD using libftdi-0.19 and ftd2xx, or did I overlook something?

If not, I would suggest to only use libftdi in OpenOCD.

Uwe, do you see a possibility to port libftdi-0 over to use the
libusb-1 API? If only synchronous is used it should be straight
forward. I'm not saying that *you* must do it, but am rather asking
how much effort it might be.

The benefit for OpenOCD would be that it can use libusb-1 on Windows
without first having to rewrite the ft2232 driver. That rewrite is
absolutely desirable, but it seems that everyone agrees that the
driver deserves and needs a thorough job, so would be nice to be able
to punt on that and still be able to start using WinUSB and libusb-1.


//Peter

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

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

On Sat, Jul 16, 2011 at 10:49 AM, Peter Stuge <pe...@st...> wrote:
> Many thanks for making these tests! Awesome!
>
> Xiaofan Chen 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.
>
> So in conclusion there is almost no difference in performance between
> OpenOCD using libftdi-0.19 and ftd2xx, or did I overlook something?

Yes ftd2xx is only slightly faster based on my limited tests.
Freddie, Laurant and others may have more inputs

> If not, I would suggest to only use libftdi in OpenOCD.

I think it is still good to have both options.

> Uwe, do you see a possibility to port libftdi-0 over to use the
> libusb-1 API? If only synchronous is used it should be straight
> forward. I'm not saying that *you* must do it, but am rather asking
> how much effort it might be.

libftdi-1.0 is based on libusb-1.0 and uses both sync API
and a bit of async API. It is right now API compatible with libftdi-0.19.
http://developer.intra2net.com/git/?p=libftdi-1.0

> The benefit for OpenOCD would be that it can use libusb-1 on Windows
> without first having to rewrite the ft2232 driver.

That is right. It is actually not difficult to switch to libftdi-1.0 since
the current 1.0 API is compatible with libftdi-0.1x.

> That rewrite is
> absolutely desirable, but it seems that everyone agrees that the
> driver deserves and needs a thorough job, so would be nice to be able
> to punt on that and still be able to start using WinUSB and libusb-1.
>

I did some tests for libftdi-1.0 last time and it did not
offer any speed improvement for OpenOCD since OpenOCD
has not taken the advantage of the libftdi-1.0 async API.

http://lists.berlios.de/pipermail/openocd-development/2010-February/014895.html
http://lists.berlios.de/pipermail/openocd-development/2010-February/014896.html

-- 
Xiaofan

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

[Peter S. <pe...@st...>]

Xiaofan Chen 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).

I'll test the Versaloon with an LPC-P2148 tomorrow.


Xiaofan Chen wrote:
> > So in conclusion there is almost no difference in performance between
> > OpenOCD using libftdi-0.19 and ftd2xx, or did I overlook something?
> 
> Yes ftd2xx is only slightly faster based on my limited tests.

Please don't be shy. You did rather extensive testing in an excellent
structured fashion which makes the results clear and easy to
understand for anyone. That is incredibly valuable. :)


> Freddie, Laurant and others may have more inputs

Even more test results are of course interesting!


> > If not, I would suggest to only use libftdi in OpenOCD.
> 
> I think it is still good to have both options.

No doubt a convenience for users, but will it be big enough to
warrant the extra work (and really ugly code) needed while rewriting
the ft2232 driver? I tend to say no.

I think the majority of ftd2xx users were on Windows, and I think
they are equally if not more happy with an OpenOCD binary package
that is easily downloaded and has kernel drivers (WinUSB) that are
even installed automatically (go libwdi!) just by running openocd.

That is the open source one-click embedded debug (well ok gdb too)
that NXP has accomplished for some of their targets, but which we can
actually do for *every* target. :) Just like Pete this is exactly
what I would like OpenOCD to do, and it seems not so far away.


> > The benefit for OpenOCD would be that it can use libusb-1 on Windows
> > without first having to rewrite the ft2232 driver.
> 
> That is right. It is actually not difficult to switch to libftdi-1.0
> since the current 1.0 API is compatible with libftdi-0.1x.

Awesome.


> > That rewrite is
> > absolutely desirable, but it seems that everyone agrees that the
> > driver deserves and needs a thorough job, so would be nice to be able
> > to punt on that and still be able to start using WinUSB and libusb-1.
> 
> I did some tests for libftdi-1.0 last time and it did not
> offer any speed improvement for OpenOCD since OpenOCD
> has not taken the advantage of the libftdi-1.0 async API.

Yes, I also don't expect speed advantages without rewrite, but rather
usability advantages basically thanks to libwdi and libusb-1/WinUSB.


//Peter

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

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

On Sat, Jul 16, 2011 at 1:21 PM, Peter Stuge <pe...@st...> wrote:
>> I did some tests for libftdi-1.0 last time and it did not
>> offer any speed improvement for OpenOCD since OpenOCD
>> has not taken the advantage of the libftdi-1.0 async API.
>
> Yes, I also don't expect speed advantages without rewrite, but rather
> usability advantages basically thanks to libwdi and libusb-1/WinUSB.

That is arguable. Yes libwdi/Zadig makes it easier to replace FTD2xx
driver with WinUSB so as to use libusb-1.0/libftdi-1.0.

On the other hand, libusb-win32's GUI Inf-Wizard is also easy to
use so that user can replace ftd2xx driver with libusb0.sys so as
to use libusb-win32/libftdi-0.1x under Windows.

Moreover, libusb-win32's GUI Filter Wizard makes it very easy to add filter
driver on top of the existing ftd2xx driver in order to use libftdi-0.1x. The
user does not even need to repace the ftd2xx driver so they can continue
to use other tools relying on the ftd2xx driver.

The libusb-win32 filter driver is also perfect for use with other Jtag
device like J-Link. You can keep using Segger's driver so that you
can continue using IAR/Keil/etc. And you can add the filter driver
in order to use OpenOCD.

-- 
Xiaofan

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

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

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

D:\work\openocd\build_cxf\openocd_15Jul2011\bin>openocd_libftdi_mingw.exe
-f olimex_lpc_p2148_jlink.cfg
Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-22:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it
allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
Warning - assuming default core clock 12MHz! Flashing may fail if
actual core clock is different.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
1500 kHz
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V6 compiled Feb  1 2011 14:28:14
Info : J-Link caps 0x99ff7bbf
Info : J-Link hw version 60000
Info : J-Link hw type J-Link
Info : J-Link max mem block 8864
Info : J-Link configuration
Info : USB-Address: 0xff
Info : Kickstart power on JTAG-pin 19: 0xffffff01
Info : Vref = 3.280 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 0 TRST = 0
Info : J-Link JTAG Interface ready
Info : clock speed 1500 kHz
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787,
part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 4
Info : lpc2148.cpu: hardware has 2 breakpoint/watchpoint units
Info : accepting 'telnet' connection from 4444
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787,
part: 0xf1f0, ver: 0x4)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
fast memory access is enabled
dcc downloads are enabled
wrote 232748 bytes from file lpc2148.hex in 12.082000s (18.813 KiB/s)


-- 
Xiaofan

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