search

majbthrd / pico-debug

virtual debug pod for RP2040 "Raspberry Pi Pico" with no added hardware
386 stars 50 forks source link

Question about the printf statements #3

Closed pradt2 closed 3 years ago

pradt2 commented 3 years ago

Hi,

Given that the debugger 'owns' the USB port, how can I see the printf statements?

majbthrd commented 3 years ago

Great question.

One option is to connect a USB TTL serial port to the UART that pico-sdk has been configured to send printf messages out of.

For at least the past 15+ years in professional debugging products, the SWD/JTAG connection can be used for printf statements directly. This is a much better way of doing things IMHO. The way it works is that the user code writes to a location in (RP2040 Pico) memory, and then the PC software can read that memory whilst the user code is running. However, that’s not a feature that open source solutions like OpenOCD, GDB, etc. support yet (to my knowledge). My hope is that pico-debug might spur these kinds of features to be added; they would benefit anyone doing debugging (not just RP2040 Pico).

majbthrd commented 3 years ago

P.S.: I should point out that when I say "SWD/JTAG", I mean the debugger connection (whether provided by pico-debug or something else).

majbthrd commented 3 years ago

Also, it is perhaps worth pointing out that a debugger (like gdb or Visual Studio Code) works with pico-debug to let the user see variable values and set breakpoints, etc.

So, you might find that printf statements are not as relevant when you can leverage more advanced debugger capabilities. Why printf a particular value when you can see its value (and every other variable’s value) in the debugger running on the PC? Why have a printf to show when code reaches a particular point when you can set a breakpoint? Etc., etc., etc.

pradt2 commented 3 years ago

Thanks very much for these answers, I think you can't always replace printf statements with variable inspection (e.g. in my case I use printf to see how sensor readouts change in real time), but you're completely right - if I had to pick one, I'd choose the debugger any time of day.

majbthrd commented 3 years ago

Cool. FYI: Rowley Crossworks for ARM and SEGGER Embedded Studio (white-label version of Rowley) have quite powerful functionality for writing data via the debugger link. The APIs are here:

https://studio.segger.com/debugio_h.htm https://www.rowleydownload.co.uk/arm/documentation/debugio_h.htm

The notion that a user can fopen and fwrite a file on the host PC from the embedded target is pretty cool to me.

I use Rowley Crossworks for ARM almost daily, and there is example RP2040 code here. I haven't yet tried SES with the RP2040, but in theory they do now support CMSIS-DAP/DAP-Link (originally, SEGGER Embedded Studio only worked with J-Link).