@deshipu you stuck to this UART, and the problem is that the SCK, MISO, MOSI lines are defined, but there is no board.i2c().

Problem:

As everyone knows, there are only numbers on the Lolin s2 mini board.

The problem is what you get when you type “Lolin s2 mini pinout” into Google. This is either an official pinout from Wemos, without I2C/SPI, or an “independent” work, not as defined in Circuitpython.

The current situation looks like a job half done:

• There is SCL, SDA, SPI(), where SCL, SDA are defined only in the schema.
• There is SCK, MISO, MOSI, there is no I2C(), with SCK, MISO, MOSI being defined only in the schema.
• There are defined A0, D0-D7, which I don’t know where they came from. (OK, I know, they are on D1 mini Lite, and in the D1 mini v3.1 documentation. D1 mini v4 no longer mentions them. And they are added because: “Micropython has it”)

BTW:

The SCL, SDA, SCK, MISO, MOSI positions are what Wemos “invented”. According to the datasheet they should be here:

Solution(s)

I see two paths:

• remove all non-standard things (A0, D0-D7, according to rpi situation) and lose backwards compatibility, or:
• take it upon yourself to fix the world and publish “Circuitpython Lolin S2 mini pinout”, with an indication of what has been “improved” and why.

And what with board.i2c()?

There are going to be confused and frustrated users no matter how this matter goes.

Yes, it’s about reducing the support burden, and often there’s no good choice. As another example, we didn’t provide board.I2C(), etc. on the Pi Pico. This was not so much because there weren’t silkscreen markings, but because there were different “default” I2C pins defined by different language implementations and also different educational material. See #4121. “That’s the great thing about standards: there are so many.”

So we avoided the support burden of “sorry, the default pins aren’t what you thought”, but added a new support burden “how come board.I2C() doesn’t work?”.

I would like to cool this down. I think different people have different definitions of the word “default”.

On Adafruit CircuitPython Espressif boards, we are generally careful not to assign TXD0 and RDX0 to board.TX and board.RX, because they are special and can send data during boot, etc. We are also careful not to label those pins as just “TX” and “RX” on the silkscreen: we use “TX0” or “TXD0” and “RX0” or “RXD0”.

However, we have many third-party boards (see the list below) that have assigned board.TX and board.RX to GPIO43 and GPIO44, and maybe it’s too late to undo that. We should have asked them not to do that during the review process and to use board.TX0 or board.TXD0, etc.

If these third parties label these pins as TX/RX on the silkscreen, that further complicates things. And now with Lolin not being consistent, I’m not sure what to do. We could change the names for board.TX and board.RX on the Lolin S3 Mini, but removing pins will break existing code.

Or, we can just say it’s not that important, but in the future, try to encourage people not to do this, and maybe start adding TXD0 etc. as aliases on the boards that do this.

adafruit_qualia_s3_rgb666  # this is a mistake and we remove those definitions from this board
ai_thinker_esp_12k_nodemcu
atmegazero_esp32s2
bpi_bit_s2
bpi_leaf_s3
bpi_picow_s3
brainboardz_neuron
crumpspace_crumps2
deneyap_mini
deneyap_mini_v2
electroniccats_bastwifi
es3ink
espressif_esp32s2_devkitc_1_n4
espressif_esp32s2_devkitc_1_n4r2
espressif_esp32s2_devkitc_1_n8r2
espressif_esp32s3_devkitc_1_n32r8
espressif_esp32s3_devkitc_1_n8
espressif_esp32s3_devkitc_1_n8r2
espressif_esp32s3_devkitc_1_n8r8
espressif_esp32s3_devkitc_1_n8r8_hacktablet
espressif_esp32s3_devkitm_1_n8
espressif_esp32s3_lcd_ev
espressif_esp32s3_usb_otg_n8
espressif_hmi_devkit_1
espressif_kaluga_1
espressif_kaluga_1.3
espressif_saola_1_wroom
espressif_saola_1_wrover
franzininho_wifi_wroom
franzininho_wifi_wrover
gravitech_cucumber_m
gravitech_cucumber_ms
gravitech_cucumber_r
gravitech_cucumber_rs
hexky_s2
hiibot_iots2
lilygo_tembed_esp32s3
lilygo_ttgo_t8_esp32_s2_wroom
lilygo_ttgo_t8_s2_st7789
lolin_s2_mini
lolin_s3
lolin_s3_mini
magiclick_s3_n4r2
makerfabs_tft7
microdev_micro_s2
mixgo_ce_serial
mixgo_ce_udisk
muselab_nanoesp32_s2_wroom
muselab_nanoesp32_s2_wrover
smartbeedesigns_bee_data_logger
smartbeedesigns_bee_motion_s3
smartbeedesigns_bee_s3
targett_module_clip_wroom
targett_module_clip_wrover
unexpectedmaker_blizzard_s3
unexpectedmaker_feathers2
unexpectedmaker_feathers2_neo
unexpectedmaker_feathers2_prerelease
unexpectedmaker_feathers3
unexpectedmaker_nanos3
unexpectedmaker_pros3
unexpectedmaker_tinys2
unexpectedmaker_tinys3
waveshare_esp32_s2_pico_lcd
waveshare_esp32_s3_zero
yd_esp32_s3_n16r8
yd_esp32_s3_n8r8

To be clear here, it sounds like GPIO43 and GPIO44 are not exposed at all on the Lolin S3 S2 Mini, and would not be available except via bodge wiring to the chip pins. In that case, there should not be board.RX and board.TX pins

@deshipu I don’t understand if the pins are not accessible why they would be listed. Maybe you meant something else?

There’s nothing on the silk or in the docs indicating default RX and TX pins. Some D1-form-factor boards have default (silk + docs) RX and TX in the upper right (USB-connector side, connector at the bottom), but not all.