Yes. I'm tempted to hack that or the official picoprobe (which I've already hacked a bit) to give an image that turns a picoprobe into something just like an ordinary UART-to-USB cable that I might otherwise use.You can use RTT with yapicoprobe (now working also with RP2340 as target).RTT_SpeedComparison.png
I never found things like DDT to be of much practical use, though later in the Z80 era we attained the luxury of a logic analyser which could clip onto the CPU and give instant disassembly; at an earlier and less wealthy period when tracing a particularly pernicious bug we built the "bug snaffler" which was a bunch of TTL and LEDs that watched for writes to a particular location (set on DIP switches) and captured the address of the instruction doing the write.BTW I used debuggers on Z80, as well, although rudimentary, NMI proved to be helpful.
But in all of this I'm not saying "I'll never touch Picoprobe+GDB", which would be foolish, and certainly not "nobody should use Picoprobe+GDB" which would be ridiculous. In actual fact, I do have some picoprobes lying around (actually a custom one built for in-system programming of a product in an awkward case that you can't get fingers in to attach a cable but can poke in a long, thin PCB with a picoprobe on it).
Bottom line with all of this is that setting up a debugging configuration is an investment of time - both for each one-off instance of a problem to be solved, and overall building skill with a particular tool. Out of the range of all possible problems, some are most easily solved with a GDB-style debugger, many can be solved equally easily by multiple methods, and some can't be solved by debuggers at all.
So for the type of work I do, with the type of hardware I work with, the variety (meaning I can't afford to invest much time in a one-purpose tool) and my past experience, I usually pick printf-debugging as the tool most likely to solve my problem with the least investment of effort. I can well respect that the equation is different for other people, and indeed I'm open to using different tools myself if they appear to offer a lower-effort solution to a particular problem. The RTT looks like it might help me sufficiently often that I intend to invest some effort bringing it into my environment; the trace buffer stuff you've been doing in other threads looks like it can solve some problems that other tools cannot reach, but needs enough effort that I think I'll need to wait until I'm desperate to justify the investment.
Statistics: Posted by arg001 — Wed Mar 05, 2025 5:21 pm