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 ------------------------------------------------------------------------------ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
