[OpenOCD-devel] Improving cmsis-dap performance

[Angus G. <gu...@pr...>]

I'd like to put some time into boosting CMSIS-DAP performance, I
wanted to run some of my ideas past you all (and also check if
anyone's already working on this.)

Motivation: At the moment my CMSIS-DAP based nrf51822 mKIT board can
dump RAM via openocd at 0.9KiB/s (using change 2116 as submitted by
Andrey, thanks!) If I use pyOCD on the same board, 12KiB/sec. If I
use an stlink-v2 with openocd on the same MCU, ~50KiB/sec.

One difference is that pyOCD uses DAP_TransferBlock CMSIS-DAP commands
for these kinds of operations, whereas openocd currently uses
individual DAP_Transfers where each register read/write has its own
USB HID request/response.

I think it should be possible to boost performance inside
jtag/drivers/cmsis_dap_usb.c while keeping the current swd_driver
interface:

- Add a command queue (as per ftdi swd driver, etc.) CMSIS-DAP
  includes a provision for multiple commands in a single USB
  request/response (PACKET_SIZE/PACKET_COUNT in DAP_INFO) so this
  should be a performance win already.

- When building the queue, look for queued reads/writes to the same
  register and transfer them into Transfer_BLOCKs rather than
  individual register transfers.

I also looked at the dap_ops driver in target/adi_v5_cmsis_dap.c,
which I'm guessing is the higher layer intended to eventually support
both SWD and JTAG? This layer also has the (unused) notion of a
queue. However I couldn't think of a useful way to use this layer for
a performance boost, at least without replacing the lower level
swd_driver interface with a hardware-specific interface that just
takes cmsis-dap transfer requests. This seemed like a bad idea to me,
as the push seems to be towards unifying internal APIs rather than
creating more HLA-style special cases.

That all said, I'm new to the openocd codebase and I'm not entirely
sure what direction development is trying to take in terms of
standardisation or CMSIS-DAP.  So please feel free to point me in a
different direction, or at previous discussions that I've missed. :)


- Angus