export both pico hardware UARTs via picoprobe?

[milipropasm]

Is this impossible, something I could easily add, or a major feature request?
I'm working with poll-based USB and LWIP and it would be really useful to see separate console windows for several 'concurrent' activities...
Andy

[lurch]

#52 talks about "sends debug output to a secondary CDC" which perhaps points you in the right direction? 🤷‍♂️

[milipropasm]

Excellent thanks, will have a better look at that 2moro and see if I can kludge something, and if I might be able to produce a commit-worthy form.

[milipropasm]

Hmm, below definitely wrong, pls ignore.

"OK, so this is decidedly non-trivial:
I was hoping that the CMSIS_5 debug part of picoprobe used bit-banging or custom PIO code on non-UART GP pins, however the probe's hardware UART1 is already used for this, being connected to target pico's SWCK/SWIO ports.
This means that the picoprobe can only bridge UART0 via USB-CDC, which it already does.
The only way I can see to meet my requirement is to create additional software UART(s) using PIO which could then be bridged by replacing tud_cdc_* calls with their tud_cdc_n_* variants.
As I have two projects on the go ATM and zero experience of pico PIOs, I have to stop here.
Thanks to lurch for the initial pointer tho,
Andy"

[lurch]

the probe's hardware UART1 is already used for this, being connected to target pico's SWCK/SWIO ports.

You do realise that UART1 can be muxed to multiple different GPIO pins? 🙂
https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html#pinout-and-design-files

[milipropasm]

Yep, but always worth checking... my problem was going cross-eyed comparing GPn "pin" numbers with hardware pin numbers whilst comparing against pin 'offsets' in the code, so I totally missed that debug/SWD/CMIS was using already SPI0 not UART1. So yes, this actually is possible after all, simply by enabling uart mode on GP0 and GP1 and then using the tud_cdc_n_* variants in cdc_uart.c
will give it all a try 2moro...

[milipropasm]

Right, that's done and working (with THREADED 1)

Tested openocd .elf upload and UART (cmake ..)
Tested openocd .elf upload and UARTs (cmake -DEXTRA_UART=1 ..)
Couldn't test at all with THREADED 0: openocd timed-out and uart took an age to initialise.

I currently have the unstaged changes in the working directory created 13:11 28th sept by:

git clone https://github.com/raspberrypi/picoprobe.git
cd picoprobe
git submodule update --init

I have zero experience contributing with git/github but found this (gulp):
https://github.com/MarcDiethelm/contributing/blob/master/README.md
if you have a simpler guide I would be v happy...

[lurch]

https://docs.github.com/en might be a good starting-point?

[milipropasm]

So am I creating a branch from master or develop?

[milipropasm]

Anticipating your 'Doh!', I'm looking for a confirmation before I begin work on something I really don't want to have to do twice...

[lurch]

So am I creating a branch from master or develop?

I dunno, that's probably a question for @P33M

[milipropasm]

OK, thanks anyway. Have created a develop pull request #102 - should have done it from here, but live and learn...

[lurch]

should have done it from here

Nope, in GitHub issues and Pull Requests are two separate things; so you've done the right thing 🙂

[lurch]

(It's entirely up to you how you want to manage this issue, since you created it; but FYI the usual convention is that the issue stays open until the associated PR gets merged)