`#define PICO_RP2350A 0` to mean RP2350B is confusing

[dhalbert]

Re #2286, #2290, #2359.

While submitting a new board def, I also at first mistakenly put

#define PICO_RP2350B 1   // (wrong)

in the board def, only to stumble upon the issues mentioned above, and that I should have done

#define PICO_RP2350A 0  // means RP2350B

I appreciate that you added a validation check for this.

I did find it non-affordant. If there is ever an RP2350C, then what would happen? (Kind of like RED=0 means BLUE, but then GREEN comes along.) Is it something to clean up in the long run, by allowing PICO_RP2350B, or using some kind of enumeration?

#define PICO_TYPE_RP2040 0x2040  // or just 1, 2, 3, ...
#define PICO_TYPE_RP2350A 0x2350A
#define PICO_TYPE_RP2350B 0x2350B
// #define PICO_TYPE_RP2350C 0x2350C

Then, in a board def:

#define PICO_TYPE PICO_TYPE_RP2350B

[d-c-d]

One of the challenges when reading 'other peoples code' :-) is trying to understand what was intended.
The reader is sometimes left to guess what was meant.

In pico-sdk - we have some clues about the configuration by scanning for PICO_CONFIG
but other clues can be deduced digging through $PICO_SDK_PATH/cmake to observe how
other side effects from comments that use like 'pico_cmake_set' and 'pico_cmake_set_default'

Eventually one finds python code that shows that these conventions are important ( e.g. tools/check_board_header.py )
that apply to a portion of the code (the board files)
One is left to search the pico-sdk datasheet and issues to find key documetation after the fact.

sorry for the above cry for improved pico-sdk design documentation above.

It is not clear from the one comment in src/rp2350/pico_platform/include/pico/platform.h and the pico-sdk datasheet that this convention that PICO_RP2350A being 0 means PICO_RP2350B package, but it is left to each user of pico-sdk to discover this on their own by diving deep into the source code.

PICO_RP2350A - Whether the current board has an RP2350 in an A (30 GPIO) package

[lurch]

Yes, there's very little documentation about how to create a board-header file. OTOH, over 99% of people will just be using an already-made board-header, and any board-headers that do get added to pico-sdk will get reviewed by Graham, Peter or myself (and get tun through tools/check_board_header.py) before merging 😉

[d-c-d]

I also noticed that the use of the PICO_RP2350A in the board files is inconsistent in another way

of the 53 board files that have
// pico_cmake_set PICO_PLATFORM=rp2350

only 48 specify a value for PICO_RP2350A, I guess the default not defining PICO_RP2350A
also implies that it is a rp2350B in src/rp2350/hardware_regs/include/hardware/platform_defs.h
while 16 #define PICO_RP2350A 0, and the
other 32 #define PICO_RP2350A 1

FYI: the files that do not specify a value for PICO_RP2350A are:

amethyst_fpga.h
pimoroni_pga2350.h
pimoroni_pico_plus2_rp2350.h
pimoroni_pico_plus2_w_rp2350.h
seeed_xiao_rp2350.h

[lurch]

of the 53 board files that have // pico_cmake_set PICO_PLATFORM=rp2350
only 48 specify a value for PICO_RP2350A

Oooh, well spotted! I probably ought to add a check for that to tools/check_board_header.py...
EDIT: Added in #2370

FYI: the files that do not specify a value for PICO_RP2350A are:
amethyst_fpga.h

FPGA platform, so it's neither RP2350A nor RP2350B 😉 (but this file is only for internal use).

pimoroni_pga2350.h
pimoroni_pico_plus2_rp2350.h
pimoroni_pico_plus2_w_rp2350.h

The product pages at https://shop.pimoroni.com/products/pga2350 https://shop.pimoroni.com/products/pimoroni-pico-plus-2 & https://shop.pimoroni.com/products/pimoroni-pico-plus-2-w show that these boards are all using RP2350B.

seeed_xiao_rp2350.h

The product page at https://www.seeedstudio.com/Seeed-XIAO-RP2350-p-5944.html doesn't clarify whether it's using RP2350A or RP2350B, but page 3 of the schematics shows that it's using RP2350A.