Sorry to jump into this PR... I'm currently doing some API experiments and one of my ideas was to do some RTT console fetching in an example. Unfortunately the current RTT implementation is not very flexible (underestimation).
How about extending the RTT module so that it exposes some methods like: SearchSignature() (perhaps in smaller bunches) and FetchData()?
If you already have your hands on this code, how about refactoring it a "little" bit?

@rgrr, RTTControlBlock.from_target in pyocd.debug.rtt seems just like SearchSignature.

/azp run

@rgrr, RTTControlBlock.from_target in pyocd.debug.rtt seems just like SearchSignature.

@zjli-2019 : perhaps we have different sources, but I cannot find something like pyocd.debug.rtt or RTTControlBlock in pyocd. Do you have a link to a file?

@rgrr you can find it on the develop branch:

@rgrr you can find it on the develop branch:

pyOCD/pyocd/debug/rtt.py

Line 120 in 8ac1dba

def from_target(cls, target: SoCTarget, address: int = None,

Thanks for pointing me into that direction. That's exactly what I was looking for. Question is when this will be integrated.

Question is when this will be integrated.

I'm planning a release of everything on the develop branch as soon as the CMSIS-Pack debug sequence support (#1488) is merged in. The only thing remaining (I hope!) is a fix for an issue related to generation of memory regions for flash algorithms that don't have an explicit region definition, when there are certain alias regions present. Actively being worked on.

Just the minor file-related requests.

On a more functional level, do you think it would make sense to have logging be independent of viewing/input? So you could simultaneously view and log, or save a log from an interactive session.

It is nice to be able to simultaneously view and log, or save a log from an interactive session.
If so, file format has to be considered: how to store input/output separately, how to parse it later, etc.

In my case, an up channel is used to transfer binary trace data. Logging mode
is just like JLinkRTTLogger, and all data coming from the up channel is saved to a file that will be processed later.

/azp run