This has been on my TODO list for a long long time and most frequently requested feature. I finally got something. Here is some info about this implementation.

Update: Jun 14, 2023. It is now officially released in v1.12.0. Thanks to everyone who helped and gave feedback.

In the following video, we are sampling at a fairly high rate (every 100ms). But VSCode is unable to refresh the screen that frequently. I found out that it needs a minimum refresh rate of 200ms on my laptop., Less than that, it will NEVER refresh and the view looks frozen. We will have two rates -- sample rate and a refresh rate. The refresh rate will be a user/workspace setting because it is machine dependent whereas the sample rate will be part of your launch.json and is less machine-dependent (default is 250ms). If you have a lot of variables you have to sample slower. The max sample rate is 20 times a second. Higher sample rates are useful for plotting and logging

In the video above the variable tmp updates far more frequently than the big data structure. Any field that starts with a u is a union member. Unions are much harder to deal with and are ambiguous, especially when they are un-named.

• Only global scalars are supported. We now have support for structs, unions, bit fields, and arrays besides scalar variables.
• Only works with OpenOCD, JLink, and STLink, currently. How it works internally for OpenOCD
  • Configure OpenOCD to accept multiple GDB connections. This part is very fragile and must be done before init. This part is customizable, and if the default mechanism doesn't work, you need to be comfortable with configuring the target CPU to allow multiple connections.
  • Launch a second instance of gdb that does not react/receive any events. This is also fragile because I have no guarantees on how this works. GDB should not get events like stopped/breakpoint/other from OpenOCD. If it does, then it is ruined. So far, so good
• Issues with multi-core setup
  • You can have live watch enabled for only one session max. Others are ignored
  • With OpenOCD, we try to guess which CPU you are using to configure it properly. Our guess could be wrong
• It will probably work with JLink but I have no clue based on their docs. It worked with JLink without changing anything or any additional configuration
  • The second gdb solution may not work at all.
  • We can probably do raw memory reads and writes and hopefully all gdb servers support this. We have to do the complex work gdb does for us and I am not up to that. That complex work is decoding/translating types, structs, struct layouts, unions, and the list goes on and on. Super error-prone and I dread this.
• Maybe STLink has the same story as JLink. Zero docs, proprietary Yes it works just like JLink and is very simple.
• While I tested with OpenOCD, JLink and STLink, you are welcome to try with other gdb-servers. It may work or your gdb-server may not support it or it needs additional configuration. Report back to us
• I don't know what the minimum version of GDB this would require.
• You can specify a format just like in the regular Watch window. However, how it applies to children of non-scalars is unclear.
• Of course, the first request I will get is to plot. Again, I can create an interface/API but need help creating the HTML/CSS views to plot the stream. We can probably reuse the SWO/RTT plotting we got but I am not comfortable with that. Actually, I am ignorant too. I didn't write that and I am the wrong person.
• Logging to file or a TCP port for offline plotting?

HELP Needed: Testing of course and help with plotting, logging

I have a feeling I am creating a HUGE support nightmare for myself.

@PhilippHaefele care to comment?