orbcode / orbtrace

Debug and parallel trace hardware for CORTEX-M (FPGA + support code)
Other
139 stars 20 forks source link

cmsis-dap: add SWO extension support #24

Open karlp opened 10 months ago

karlp commented 10 months ago

First up, I realise that this is not "required" as you can always use orbuculum to capture the SWO data, and orbtrace to configure the dongle, and https://github.com/orbcode/orbuculum/blob/main/Support/gdbtrace.init to configure it.

However, I move that while this setup is completely functional it doesn't mean it's the best, or only way.

Right now, if I want to use SWO on a target, I can use the same openocd target config files, with jlink, stlink, other cmsis-dap+swo dongles. However, to use an orbtrace, I need to remove all trace config lines from my openocd config, and use the gdbtrace.init files. And, extend those files with every new cpu supported, even though openocd already fully supports the gpio and trace config already. This is just extra cognitive load for no real gain. Supporting the CMSIS-DAP+SWO interface also doesn't preclude using it separately with orbuculum, but it gives you support built in to all the existing tooling that already supports cmsis-dap+swo.

I do also realise that orbtrace isn't meant to be "just a good quality community/open cmsis-dap debugger dongle" but surely it can be that as a base, as 1) far more boards have SWO connected than parallel trace, and 2) SWO is the gateway drug to ETM, so let's make it as painless as possible.

Here's someone doing a bunch of work to letthem keep using the same work flows they use for other dongles, which would be simply not needed if orbtrace just used the cmsisdap+swo standards... https://github.com/probe-rs/probe-rs/pull/2110

mubes commented 9 months ago
This is a valid argument. The only reason support is _not_ in
  there is laziness, although the stream itself will not come over
  the CMSIS-DAP connection, it will still be streamed separately,
  because it costs too much performance to do it that way.
DAVE