René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"cmsis-dap: add SWO extension support","articleBody":"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.\r\n\r\nHowever, I move that while this setup is completely _functional_ it doesn't mean it's the best, or only way.\r\n\r\nRight 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.\r\n\r\nI 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.\r\n\r\nHere'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 ","author":{"url":"https://github.com/karlp","@type":"Person","name":"karlp"},"datePublished":"2024-02-03T13:38:10.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/24/orbtrace/issues/24"}