probe-rs
probe-rs copied to clipboard
probe-rs
make core interface accessible from outside
This patch would enable us to integrate probe-rs into our own solution that has to manage low-level and high-level access differently that is currently possible with a Session.
Closes #1713
I think the idea is okay, but please clean up the CI failures (changelog, formatting, docs) and also remove the re-exports from the crate root that became redundant.
Can you share more info on what your use case is and why the existing public API is not solving it? I'd feel more comfortable trying to extend the public API to work for more use cases, instead of publically exposing private inner guts.
(I'm a coworker of @maxd-nordic)
We're currently using the J-Link SDK in our tools, so we need to integrate probe-rs in a way which is compatible with that. We need to use functionality from the Core interface, such as halt or reading registers, but we can't use the Session struct.
The Session tries to do too much for our use case, we need more control over the different steps. Ideally we would be able to first connect to the debug port, so we get an ArmCommunicationInterface<_>, and then we could connect to a core separately.
I think the idea is okay, but please clean up the CI failures (changelog, formatting, docs) and also remove the re-exports from the crate root that became redundant.
Could one of you maybe help me with this? I'm not sure if I understand probe-rs well enough to add the missing docs. Would removing the re-exports mean changing all over probe-rs to replace things like crate::MemoryMappedRegister with crate::core::MemoryMappedRegister? @Tiwalun @bugadani
Can you share more info on what your use case is and why the existing public API is not solving it? I'd feel more comfortable trying to extend the public API to work for more use cases, instead of publically exposing private inner guts.
I would like to intervene in the discussion, even though I am not part of the author team of this PR. I believe it is not possible to generalize programming techniques for ARM controllers since they are specific to specific vendor families and require vendor specific kernel and register methods. The current approach is using the Attach etc. methods and adding a debug sequence for the Attach etc specialization. family will not always work. Therefore, we need public access, ideally to everything, so that we can build a combined one (ARM core + specified vendor) at the middle-upper level.
