Usermod settings SCL and SDA not showing platformio values

[ewoudwijma]

What happened?

Usermod settings do not show values for build flags HW_PIN_SCL and HW_PIN_SDA on new install. Show -1 instead:

To Reproduce Bug

erase flash: pio run --target erase

Set in platformio environment xyz -D HW_PIN_SCL=22 -D HW_PIN_SDA=21

build xyz

go to settings / usermod

Expected Behavior

Install Method

Self-Compiled

What version of WLED?

0.14.0 latest

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[ewoudwijma]

Same applies for

(HW_PIN_DATASPI, HW_PIN_MISOSPI, HW_PIN_CLOCKSPI)

[blazoncek]

They do, as a placeholder (remove -1 or any other input by deleting digits). This is intentional as to not allocate GPIO during boot. HWPIN... macros are just informational which GPIO is reserved (if used) for hardware accelerated IO.

Not a bug but intentional behaviour.

[ewoudwijma]

I saw the placeholder functionality. It's info only, not assigned to anything

I would say setting hw_pin_sda/scl (or not setting) determines if gpio should be allocated or not. Might be confusing for end users as build flags normally are shown as default in the ui.

We are currently reviewing the sda/scl functionality. After review will let you know our advice.

[blazoncek]

I would say setting hw_pin_sda/scl (or not setting) determines if gpio should be allocated or not. Might be confusing for end users as build flags normally are shown as default in the ui.

Well, it is not intended in the way you think. Confusing or not these setting are meant for advanced users who know how are they compiling and for what. If you want to pre-allocate I2C and/or SPI GPIO pins, do so by introducing new compile time options. These may have nothing in common with HWPIN...

We are currently reviewing the sda/scl functionality. After review will let you know our advice.

I wish you luck. I stumbled to a roadblock when trying to use 2 I2C devices on the same HW pins. Looks like a bug in Espressif/Arduino implementation. Since I2C is not used for LEDs and global SPI may conflict if using APS102 they are secondary in priority so I dropped any further development.

[ewoudwijma]

Well, it is not intended in the way you think. Confusing or not these setting are meant for advanced users who know how are they compiling and for what.

Is it documented anywhere? Discord links also okay. Any names of advanced users to check ?

Not to criticize your approach but get a general understanding how it is supposed to be used in different scenarios, improve documentation if needed and also test together multiple i2c devices

[ewoudwijma]

I2C SPI Scrapbook:

PART1:

highest level declarations are in pins_arduino.h:

If no HW_PIN values set in platformio and above variables commented out we see where these vars are used due to errors:

SCK and MOSI

NeoPixelBus/src/internal/*DotStarGenericMethod.h (T_TWOWIRE)

NeoPixelBus/src/internal/DotStarEsp32DmaSpiMethod.h

const.h

pinmanager.cpp

.platformio/packages/framework-arduinoespressif32@src-e9b1fbd6563a55e19ddae15e1fc09589/libraries/SPI/src/SPI.cpp

.platformio/packages/framework-arduinoespressif32@src-e9b1fbd6563a55e19ddae15e1fc09589/libraries/Wire/src/Wire.cpp

U8g2/src/U8x8lib.cpp

libraries/SD/src/SD.h

Conclusion from above:

• SCK, MOSI, MISO and SS is used in 'system' libraries and not in WLED code for SPI and have fixed values 18, 23, 19 and 5 respectively (in SPI.cpp 12,13,14,15 used...? only if -1...)
• SCL and SDA is used in Wire.cpp (therefore wire.cpp will only use pins 22 and 21 ?) and in const.h to set HW_PIN_SCL and HW_PIN_SDA if they do not get a value in platformio, not used anywhere else in code
• HW_PIN_SCL and HW_PIN_SDA is used in WLED code...

PART 2

wled.h defines global variables which are used to set and get persistent values

platformio has currently only one entry where standard values for an environment are defined (lolin_s2_mini):

SPI values (HW_PIN_CLOCKSPI, HW_PIN_DATASPI, HW_PIN_MISOSPI) used in usermod_v2_four_line_display_ALT.h in case the global variables are -1

setup()

addToConfig()

readFromConfig()

and used in pin_manager.cpp and xml.cpp for display purposes in set.cpp to overwrite in case of esp8266 (cannot change pins on 8266) but they are also undeffed in const.h for esp8266???

SPI values (HW_PIN_SCL, HW_PIN_SDA) used in above SPI cases in case the global variables are -1

• • more platformio entries (esp32_4MB_V4_max_base.build_flags, wemos_shield_esp32_4MB_max_base, esp32_pico_4MB_max)
• • USERMOD_BH1750 (redefined!!! and fixed to 21,22)
• • usermod_mpu6050_imu.h: in case global var is -1
• • also display purposes and unset 8266 as for spi

U8X8_PIN_I2C_DATA and U8X8_PIN_I2C_DATA

u8x8.h

U8x8lib.cpp

Conclusions:

• global variables are initialised with -1
• HW_PIN values are used in case global vars are initialised with -1 (only visible as placeholder text in ui)
• if HW_PIN values are not set in platformio, the values of pinsarduino.h are used
• u8x8 12 en 13?
• =>
• Wire and usermod_bh1750.h are always using 21,22 for i2c
• usermod_mpu6050_imu.h and usermod_v2_four_line_display_ALT.h use pinsarduino values unless redefined in platformio

Part 3

Use of FLDPIN* values in usermod_v2_four_line_display_ALT.h setup of ion array using FLDPIN and if -1 use global variables and if they are -1 use HW_PIN values

Conclusion:

• complicated
• Not sure if gpio is not allocated in case HW_PIN is not defined: global defaults are assumed... Therefore not sure if the -1 system is needed

Part 4

• u8x8 has its own pin values...
• Wire.begin() assume -1 and internally assign SDA (21) and SCL (22) in that case
• SPI.begin() assume -1 and internally assignSCK (14), MISO(12), MOSI(13) and SS(15) in that case

Proposal

• Find out if we can only use HW_PIN* and all usermods use the global vars (instead if the if <0 formula)
• The global vars are initialised by HW_PIN if defined, otherwise pinsarduino values are used
• Normal way of dealing with platformio values are used, not placemarkers
• Check if we can deviate anyway from pinsarduino values as wire and spi and Wire 'system' software is assuming these values

... to be continued ...

[blazoncek]

Search in #dev-general for the "I2C" keyword on Discord. There was no documentation but a lot of discussion. Happened somewhere in September.

The advanced users in question were @softhack007 and @Matoran ( #2740 )

As for documentation: If you want clarifications or complaint about missing information/documentation open different kind of issue. Or ask on Discord.

As noted above the implementation of shareable I2C and SPI failed and since it is not crucial for workings of WLED, further development stopped beyond the entry fields in usermod settings. Which work as intended. As shareable pins are exclusively used by usermods (except SPI which in case of APA102 cannot be shared ATM) it is up to usermods to implement proper use of I2C and SPI buses. They do get the information about which GPIO ports are intended as HW accelerated via global variables. HWPIN... constants are informational and only meant for intended override of platform default values. You do not need to define them to have HW accelerated I2C or SPI.

I do admit that this information (how & why) needs to be added somewhere. Perhaps in WLED-docs by someone that has time and will to do that and has played with usermods that use them.

In current implementation you have global variables i2c_sda, i2c_scl, spi_mosi, spi_miso and spi_sclk which are filled at boot with values entered in usermod settings page. Their intention is to represent HW accelerated GPIO pins. If they are set to anything other than -1 the appropriate interface is initialised (assuming no other code did that prior) with Wire.begin() and SPI.begin(). In such case pins are also pre-allocated to prevent unintended use in other patrs of WLED. They do not do anything beyond that. Usermods that use I2C or SPI and use the same GPIO as global pre-allocated ones do not need to call Wire.begin() or SPI.begin() as it has been done at the boot time.

[softhack007]

Hi, thanks @blazoncek and @ewoudwijma, this explains a lot how WLED behaves today.

Proposal: give me some time to digest & numbercrunch this in my head. I'll need liquid cooling (beer) for this, so can do it on the weekend. Then i'll make a proposal in discord (SR-to-WLED team), about how I2C sharing could/should behave (kind of one-line requirements) including user perspective. We discuss in discord, then I try to improve the current implementation. Agreed?

[softhack007]

SPI sharing seems to be a different beast:

• NeoPixelBus DotStar (and maybe other) use SPI pins
• SD_card used SPI
• There is vspi and hspi - sometimes need to use one but not the other
• SPI sharing works by using the same MISO/MOSI/CLK, but usually a dedicates "SS" (chip select) signal per device is needed.

So we could first try to improve I2C only, and then see what can be done for SPI.

[blazoncek]

resolved by #2955