-
Notifications
You must be signed in to change notification settings - Fork 24
Description
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... probe-rs/probe-rs#2110