SDK driver for Print toggling Pin 0 (Uart0_TX) when pin is NOT assigned to Uart0

[jhinklejr]

CMakeLists.txt has the following Set:

# Modify the below lines to enable/disable output over UART/USB
#pico_enable_stdio_uart(HR_CPU 0)
pico_enable_stdio_usb(HR_CPU 1)

which should allow Print to go to USB and NOT pin 0/1 Uart0

I use pin 0 as a display reset line and have it configured as an output state = 1

When code issues a Print statement - pin 0 is toggled via a low level output driver (tracked using debugger - but only so far) .

Toggling pin 0 when Uart0 is NOT being used identifies a SDK driver issue.

commenting out "pico_enable_stdio_usb(HR_CPU 1)" makes pin 0 behave as expected - my only issue is I loose debugging info coming in from USB Print statements.

Hope that explanation helps to identify sdk bug.

[jhinklejr]

Did more debugging and found it my my issue in not fully understanding how the two stdio statements in the CMakelists.txt file worked. Sdk performs as it should. Please close.

[lurch]

Sdk performs as it should.

That's good to hear 👍
For the benefit of anybody else who might run into this issue, would you like to clarify the issue and/or the problem in more detail? Is there anything we could do to improve the documentation about pico_enable_stdio_uart and pico_enable_stdio_usb?

[jhinklejr]

lurch - thanks for the comment. I did reopen the issue because IMO, the sdk is using hardware that the user NEVER enabled.

ISSUE - if pico_enable_stdio_uart is set true in the CMakelists.txt file (either intent or by unknowing default) IMO - the sdk should IGNORE the statement and NOT enable the Uart low-level driver for stdio purposes if the user DID NOT assign the uart xmit to pin 0. Only engage low level driver if the user (based on how they are using the hardware) directly assigns pin 0 to the uart.

How this issue bit me:

I do NOT use print statement for debugging and until this experience - never use a sdk (I usually write my own drivers and do things bare metal. I found using the pico and multicore - there was a lot of low level registers being manipulated that I found difficult to figure out just using the register documentation (and your header files are not designed for people to do direct register configuration) - you kind of FORCE users to use the sdk -- so that's what I did.

My application uses a TFT display and I have pin0 assigned to the display's reset pin.

As the design progressed, I added logging capabilities (sd card and Ethernet based) and I thought it might be nice to have the debugger present the logging messages to VScode. (I have a usb debugger attached to the pico SWD pins and a usb connected to the pico's usb for debugging power -- but I thought I could use the sdio USB - NOT UART capabilities to present logging info real time.

I put debugging redirection in my logging function and sent the string to puts() - thinking I would get it on the VSCode monitor (via usb connection). Suddenly - my tft display went black.

I started to trace the puts() statement into the sdk code and found it was going to the raw UART driver - but WHY - I did not have any UARTs enabled in my config - so WHY should a sdk UART driver be active.

THAT is what I suggest is the issue. If the user has NOT assigned a UART to hardware pins - then the low level sdk uart drive should NOT be enabled.

I hope my long explanation helps highlight what I consider an issue.

[lurch]

Which board-header are you using? Perhaps you're (unknowingly) setting #define PICO_DEFAULT_UART_TX_PIN 0? (which is what e.g. pico.h does)

I found using the pico and multicore - there was a lot of low level registers being manipulated that I found difficult to figure out just using the register documentation (and your header files are not designed for people to do direct register configuration) - you kind of FORCE users to use the sdk -- so that's what I did.

We certainly encourage users to use our SDK, but we don't force it. I'm not sure what you mean about the header files not allowing "direct register configuration", but note that the headers in https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2040/hardware_regs/include/hardware/regs are the "low-level defines" (perhaps these are what you're looking for?) and contain the same info as the SVD file. The headers in https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2040/hardware_structs/include/hardware/structs add a more C-like layer over the top of hardware_regs, and then finally the headers in https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2_common are where the rest of the "SDK API" is implemented.

[jhinklejr]

I'm sorry if I came across a little strong. I've got 30 years of embedded MCU behind and am kind set in the way I like to do things and my pico experience was a deviation from that.

I did not use a board header.

I searched my whole solution for "#define PICO_DEFAULT_UART_TX_PIN 0" - not found. Issue is as stated in next line.

My issue as stated in the original post was the two statements in the cmake file:

Modify the below lines to enable/disable output over UART/USB

#pico_enable_stdio_uart(HR_CPU 0)
pico_enable_stdio_usb(HR_CPU 1)

This is how I had them with the issue. I thought that commenting out the uart line made it disabled - which in my case did not do that. I have since uncommented the uart line which now disabled the uart. It was an understanding issue on my part.

My header comment was associated with the pico headers and header from a company like ST.

The ST header provide direct access to all registers, structures associated with each register, and a list of multiple defines for each bit in the structure. Example If I want a specific bit - there's a define that give me direct access to the bit.

I could not find that level of detain in the pico headers (it my also be I just could not find the correct file to reference). To do register bit manipulations in my code I ended up looking the in manual at the register and finding the position of the bit and then making my own bit access via (1 << bit_position).

I'm just old age cranky in the comparison - as I said - kind of fixed in how I like to do things.

Beyond my comments that you replied to - I really think you folks should consider enabling the low level uart driver ONLY if the user as configured it as being used.

I was lucky - pin0 (uart tx) was attached to a display reset that went black when a puts() was used.

Consider having that pin drive a device and random behavior occurs that they have not associated with a uart that they never enabled. Could be difficult to uncover depending on your skill level.

Just my 2 cents.

Now that I have more time with the pico sdk - I'm fine.

Sorry if I upset you.

[peterharperuk]

If you have the line "pico_enable_stdio_uart(HR_CPU 0)" (the zero being false) in your cmake (i.e. do not comment the line out) then the gpio function will NOT be set to uart. If you comment the line out then the gpio function WILL be set to uart. This is thanks to the following cmake config and is intended behaviour.

# PICO_CMAKE_CONFIG: PICO_STDIO_UART, Option to globally enable stdio UART for all targets by default, type=bool, default=1, group=pico_stdlib
option(PICO_STDIO_UART "Globally enable stdio UART" 1)

You can configure this yourself or change the default uart pin with PICO_DEFAULT_UART_TX_PIN

[lurch]

The ST header provide direct access to all registers, structures associated with each register, and a list of multiple defines for each bit in the structure. Example If I want a specific bit - there's a define that give me direct access to the bit.

Yes - that's exactly what the hardware_regs headers that I pointed out earlier allow you to do? See e.g. https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/include/hardware/regs/io_bank0.h#L3153-L3179

To do register bit manipulations in my code I ended up looking the in manual at the register and finding the position of the bit

The register-tables in the RP2040 datasheet and the headers in the hardware_regs directory are all generated from the same internal meta-data, so any information available in one ought to also be in the other 🙂 (But if you find any discrepancies, please do let us know!)

Sorry if I upset you.

No upset caused 🙂 I'm just trying to make sure that the SDK is able to do everything you expect from it.