Refactor RTT and add RTT support to gdbserver

[samueldewan]

This PR moves the RTT implementation into a separate file so that it can be used by other modules and scripts. It also adds RTT support to the GDB server in a fashion modelled after openocd.

Testing done:

• Manual testing performed on an ST Nucleo-G071RB with its ST link reprogrammed as a J-Link and on an NXP LPCXpresso55S69. On the target side I used SEGGER's RTT implementation from the J-Link software and documentation package version 7.70.
• Unit tests pass.
• I am unable to run the automated test suite, I encounter the error Skipping board <serial> due to missing test binary.

Some concerns:

• I have significantly changed the behaviour of the RTT subcommand. Previously it would wait for a newline before sending any data to the target. If a line was too large to fit in the target buffer it would silently fail and stop sending data to the target entirely. In my opinion this behaviour is incorrect. I have modified the subcommand such that characters are sent to the target as they are received. This matches the behaviour of SEGGER's RTT viewer application and allows for much smaller down buffers to be used (like for example the default configuration for SEGGER's RTT implementation which uses a 16 byte down buffer for channel 0).
• My new gdbserver command implementation is very messy. Is there a better way to implement this?

Future directions:

• This PR does not make the RTT settings available as session options. The only way to configure RTT for use with the gdbserver is via monitor commands.
• This PR does not add support for using the native RTT capabilities of J-Link interfaces, but it does lay the groundwork to make it easy in the future. pylink supports the required functionality, but I have not yet looked in to how to expose it to the RTT code.
• This PR also lays the groundwork to do different things with the RTT data rather than just making it available via a TCP server. In the future the data could be written to/read from a file or pyOCD could connect as a client to an existing TCP server.

[flit]

Thanks very much for this work.

Some quick notes/replies:

• Session options for the RTT config are added in Add rtt control block into YAML config #1418, but that PR needs a few (small) changes before being merged.
• No worries about native J-Link RTT support; we'll get that added in time.
• For the automated test suite, if the target is not built-in (DFP) then you have to set the test_binary option to the path of a test firmware binary relative to the test/data/binaries directory. (I'm adding some docs about this to the automated test docs.)
  
  Even for DFP targets, if the board has a board ID (those in pyocd/board/board_ids.py, eg ST boards with on-board STLink and many NXP boards when using the default DAPLink-based CMSIS-DAP firmware), a test binary can be added to the pyocd repo and used automatically. It would be possible to do this for any target by matching on the target name, but that hasn't been set up yet (and there's the question of what boards/targets should have test binaries).
• Changing the rtt subcommand input behaviour seems like the right thing to do. I did think it a bit weird to wait for a newline. 😄
• I'll review the gdbserver changes and might be able to provide some suggestions. (And honestly, the gdbserver code is pretty messy to begin with… It has some of the oldest remaining sections of code in pyocd.)

[flit]

Hi @samueldewan, please accept my apologies for disappearing; I was sick for quite a while.

Very nice work! Well designed and written, including type annotations 😄. Integration with gdbserver is just fine. The gdbserver itself needs a lot of work (it's one of the oldest pieces of code), as does muxing and routing of the various target I/O streams (semihosting console, SWV, and now RTT). Adding a command line option to enable RTT would be nice. But it's more important to have this functionality—the rest can wait.

[flit]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).