Addition of PICO_32BIT guard to `pico_add_hex_output`

[thytom]

Mentioned in #1829 previously.

efe2103 removes the function pico_add_extra_outputs from src/rp2_common.cmake and adds it to src/cmake/on_device.cmake. In the process, the call to pico_add_hex_output gained an if statement:

if (PICO_32BIT)
    pico_add_hex_output(${TARGET})
endif()

Removing the if still enables my projects to build, and hex file output works fine.

It's not really explained why this was done. PICO_32BIT appears to have little consequence other than enabling a static assertion in src/common/pico-sync/critical_section.c.

At the time of efe2103, this caused hex files to no longer be generated without an explicit set(PICO_32BIT 1) in the parent project. c08710c simply just sets PICO_32BIT to 1 in the chip-specific .cmake files to work around the if.

While the flag itself seems pretty benign, I'm still confused as to why the if is there in the first place. Why not remove it, generate hex files unconditionally?

[lurch]

As a pure guess, maybe this is to accommodate host builds of Pico applications, which are likely to be 64-bit? 🤷

[thytom]

I didn't even know you could do that - that's cool!

I did a grep for PICO_32BIT in the codebase, but as I say the only place where it actually changes anything meaningful is here.

I would guess that pico_add_extra_outputs wouldn't work at all on a native application anyway - not just the hex output.

[kilograham]

can you describe your use case of the SDK where PICO_32BIT is not getting defined?

[thytom]

@kilograham my project is not any particulatly special use case - just a standard, all-defaults project targeting RP2040.

Hex output works fine as PICO_32BIT is set 1 by default in the SDK, as of latest release. There is no problem as it stands.

The question I have is what exactly is PICO_32BIT for? It seemingly doesn't do anything consequential beyond enabling one static assertion and enabling hex output...