You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
First up, I realise that this is not "required" as you can always use
orbuculum
to capture the SWO data, andorbtrace
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
The text was updated successfully, but these errors were encountered: