Feature Request: Disable debug UART and make pins available

[ereisch]

If this code is relatively stable, it would be nice (if it's even possible; I'm not a RPi engineer) if the 4 GPIO ports allocated for the debug UART were able to be allocated as additional digital inputs. Putting the device at or over the 24-channel barrier would greatly increase its utility, as you could then fully analyze embedded controllers with a 16-bit address and 8-bit data bus. A 25th input would be even better, since that could be tied to either a clock signal, a R/!W signal, or something similar.

I also wonder if you'll save CPU cycles and be able to successfully have a sample-on-rising-edge feature if the ADCs and debug printf()s were omitted (since printf() is a very expensive operation). Not having time to look into the code at the moment, are interrupts being set on trigger pins? This could save the overhead of having to software poll by just having the hardware interrupt logic watch a pin for either rising or falling edge, and then the ISR samples all the GPIO channels.

Just a thought.

[pico-coder]

All of the printfs in the code are only called during initial device configuration, but once a capture is in progress none of them will be called, so they don't impact performance.
There should only be 2 pins, not 4, tied up by the UART, so that would get from 21 to 23. With a special build mode we could force the ADC pins to be digital only and get to 26.
For substantially more bits (i.e. with the RP2350B) we reach the point were the number of signal pins is greater than the PIO width, which means we need to use two PIO and ensure they are kept in perfect sync with each other as they gather samples, and the tx send would need to read from both buffers as samples were sent. That's probably not as bad as it sounds.