There are a raft of tricks than can be employed
to improve performance. The ZY1000 does 400kBytes/s
w/arm7/9 @ 16MHz btw, using OpenOCD. The advantage of ZY1000
is low latency, but it has a feeble host CPU. The history of optimizing
the ZY1000 showed significant improvement benefits for
USB dongles as well.

Profiling is the right place to start... always... Code inspection
should come only after profiling. There is plenty of inefficient code
that is hardly ever run and has no impact on observable performance.

That said, there are high level tricks that can be employed. E.g.
caching of target memory. This can be done both by GDB
(and I wonder if it can be done automatically), by e.g. caching
read only memory on the GDB end or secondarily on the
OpenOCD end.

Caching code memory would be a *HUGE* improvement for
single stepping...

Ideally we could exploit the GDB protocol better w.r.t. such
caching or add some scheme to tell OpenOCD what memory
that is to be considered as read-only by the OpenOCD GDB
server...

This may be possible *without* any change to OpenOCD. Perhaps
a tool that reads out the read-only sections from elf file and generate
a list of GDB commands to be issued in .gdbinit?

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to