Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions platformio.ini

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please revert all changes in platformio.ini.

Original file line number Diff line number Diff line change
Expand Up @@ -11,11 +11,10 @@

# CI binaries
;; default_envs = nodemcuv2, esp8266_2m, esp01_1m_full, esp32dev, esp32_eth # ESP32 variant builds are temporarily excluded from CI due to toolchain issues on the GitHub Actions Linux environment
; default_envs = nodemcuv2, esp8266_2m, esp01_1m_full, esp32dev, esp32_eth, esp32dev_audioreactive, lolin_s2_mini, esp32c3dev, esp32s3dev_8MB, esp32s3dev_8MB_PSRAM_opi
; default_envs = nodemcuv2, esp8266_2m, esp01_1m_full, esp32dev, esp32_eth, esp32dev_audioreactive, lolin_s2_mini, esp32c3dev, esp32s3dev_8MB, esp32s3dev_8MB_PSRAM_opi, esp32s3dev_16MB_PSRAM_opi

# Release binaries
; default_envs = nodemcuv2, esp8266_2m, esp01_1m_full, esp32dev, esp32_eth, lolin_s2_mini, esp32c3dev, esp32s3dev_8MB

; default_envs = nodemcuv2, esp8266_2m, esp01_1m_full, esp32dev, esp32_eth, lolin_s2_mini, esp32c3dev, esp32s3dev_8M, esp32s3dev_16MB
# Build everything
; default_envs = esp32dev, esp8285_4CH_MagicHome, codm-controller-0_6-rev2, codm-controller-0_6, esp32s2_saola, d1_mini_5CH_Shojo_PCB, d1_mini, sp501e, nodemcuv2, esp32_eth, anavi_miracle_controller, esp07, esp01_1m_full, m5atom, h803wf, d1_mini_ota, heltec_wifi_kit_8, esp8285_H801, d1_mini_debug, wemos_shield_esp32, elekstube_ips

Expand Down Expand Up @@ -43,6 +42,7 @@
; default_envs = esp32c3dev
; default_envs = lolin_s2_mini
; default_envs = esp32s3dev_16MB_PSRAM_opi
; default_envs = esp32s3_16MB_OPI

; MoonModules entries
; ===================
Expand Down Expand Up @@ -105,6 +105,7 @@ default_envs =
esp32S3_8MB_PSRAM_M_qspi ;; for S3 with 8MB flash, 2 or 4MB PSRAM, HUB75 supported
esp32S3_8MB_PSRAM_M_opi ;; for S3 with 8MB flash, 8 or 16MB PSRAM, HUB75 supported
;; === esp32-S3 === with 16MB flash
esp32s3_16MB_OPI

@coderabbitai coderabbitai Bot Jun 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify the esp32s3_16MB_OPI environment is defined in platformio.ini
grep -n "^\[env:esp32s3_16MB_OPI\]" platformio.ini

Repository: MoonModules/WLED-MM

Length of output: 45


🏁 Script executed:

# Check exact content at line 108 and surrounding lines
sed -n '105,115p' platformio.ini

# Search for any environment containing "OPI" or similar variations
grep -n "env:esp32.*OPI\|env:esp32s3.*16MB" platformio.ini | head -20

Repository: MoonModules/WLED-MM

Length of output: 686


🏁 Script executed:

# Search for environment definition with case-insensitive matching
grep -in "^\[env:esp32s3.*16MB.*OPI\]" platformio.ini

# Also search for all env sections containing "16MB" and "OPI"
grep -n "^\[env:" platformio.ini | grep -i "s3.*16MB\|16MB.*OPI"

# Count total environment definitions to understand the pattern
grep -c "^\[env:" platformio.ini

Repository: MoonModules/WLED-MM

Length of output: 105


🏁 Script executed:

# Search for any environment that might be the definition, including case variations
grep -in "^\[env:.*esp32s3.*OPI\|^\[env:.*16MB.*OPI" platformio.ini

# Check lines around where similar environments are defined
grep -n "^\[env:esp32S3_8MB\|^\[env:esp32s3_16MB" platformio.ini

# Look at the actual environment definitions for the nearby environments to understand the pattern
sed -n '2497,2510p' platformio.ini

Repository: MoonModules/WLED-MM

Length of output: 767


🏁 Script executed:

# Final verification - search for the exact name added to default_envs anywhere in the file
grep -n "esp32s3_16MB_OPI" platformio.ini

# Check if there's any commented out version that might be relevant
grep -in "esp32s3_16MB_OPI\|esp32S3_16MB_OPI" platformio.ini

Repository: MoonModules/WLED-MM

Length of output: 183


🏁 Script executed:

# Confirm the exact line 109 content in context
sed -n '105,115p' platformio.ini

# Double-check: search for any definition starting with [env: and containing any variant
grep -n "^\[env:esp32s3_16MB\|^\[env:esp32S3_16MB" platformio.ini

Repository: MoonModules/WLED-MM

Length of output: 685


Missing environment definition for esp32s3_16MB_OPI in platformio.ini.

Line 109 adds esp32s3_16MB_OPI to the default_envs build list, but no corresponding [env:esp32s3_16MB_OPI] section exists anywhere in platformio.ini. This will cause PlatformIO build failures when this environment is selected.

Either add the environment definition or remove the environment name from default_envs.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@platformio.ini` at line 108, The environment name esp32s3_16MB_OPI is
referenced in the default_envs list but lacks a corresponding environment
section definition in platformio.ini. To fix this, you must either add a new
[env:esp32s3_16MB_OPI] section with the appropriate board configuration and
build settings to match the other environment definitions in the file, or remove
esp32s3_16MB_OPI from the default_envs list if this environment is not needed.
Choose the appropriate action based on whether you intend to support building
for this ESP32-S3 variant.

Source: Coding guidelines

✅ Addressed in commit ee2fd0f

esp32S3_16MB_PSRAM_M_HUB75 ;; for S3 with 16MB flash, HUB75 supported (MOONHUB HUB75 adapter board)
esp32S3_WROOM-2_M ;; for S3 WROOM-2; HUB75 supported
;;
Expand Down
17 changes: 17 additions & 0 deletions wled00/wled.h
Original file line number Diff line number Diff line change
@@ -1,3 +1,20 @@
#ifndef WLED_MY_PINS
#define WLED_MY_PINS
#define R1_PIN 4
#define G1_PIN 5
#define B1_PIN 6
#define R2_PIN 7
#define G2_PIN 15
#define B2_PIN 16
#define A_PIN 8
#define B_PIN 9
#define C_PIN 10
#define D_PIN 11
#define E_PIN 12
#define LAT_PIN 13
#define OE_PIN 14
#define CLK_PIN 17
#endif
Comment on lines +1 to +17

@coderabbitai coderabbitai Bot Jun 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Align this pinout with the Matrixboard wiring contract.

These values don’t match the HUB75 pin order documented in bus_manager.cpp, so the matrix driver will be wired incorrectly on the target board. Please verify the mapping against the actual board schematic, and scope this block to the Matrixboard build only if this header is shared by other targets.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@wled00/wled.h` around lines 1 - 17, The pin definitions (R1_PIN, G1_PIN,
B1_PIN, R2_PIN, G2_PIN, B2_PIN, A_PIN, B_PIN, C_PIN, D_PIN, E_PIN, LAT_PIN,
OE_PIN, CLK_PIN) in the WLED_MY_PINS block do not match the HUB75 pin order
documented in bus_manager.cpp. Verify the correct pin mapping against the board
schematic and update each pin definition to match the proper HUB75 wiring order.
Additionally, if this header file is used by multiple build targets, scope the
WLED_MY_PINS block with a conditional preprocessor directive to apply these pin
definitions only to the Matrixboard build.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@coderabbitai it's even worse - the pins defined here seem to be HUB75 pins, but the HUB75 driver will not use these values.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check if the HUB75 driver or related code references R1_PIN, G1_PIN etc.
rg -n 'R1_PIN|G1_PIN|B1_PIN|R2_PIN|G2_PIN|B2_PIN|A_PIN|LAT_PIN|OE_PIN|CLK_PIN' --type=cpp --type=h -C2

echo "=== HUB75 usermod/driver pin config ==="
rg -n 'HUB75|hub75|ESP32-HUB75' -l

echo "=== Look for pin config structs in HUB75 driver ==="
rg -n 'mxconfig|MatrixConfig|HUB75_I2S_CFG|pinConfig|PIN_' --type=cpp --type=h -C2 | head -80

Length of output: 22584



@softhack007 — confirmed. The smoking gun is in bus_manager.cpp lines 803–804:

// HUB75_I2S_CFG::i2s_pins _pins={R1_PIN, G1_PIN, B1_PIN, R2_PIN, G2_PIN, B2_PIN, A_PIN, B_PIN, C_PIN, D_PIN, E_PIN, LAT_PIN, OE_PIN, CLK_PIN};
mxconfig.gpio = { 1, 5, 6, 7, 13, 9, 16, 48, 47, 21, 38, 8, 4, 18 };

The R1_PIN/G1_PIN/… form was once the intended interface (hence the commented-out line), but the driver now hard-codes its GPIO assignment directly and never reads these macros. A grep across the entire repo shows zero live uses of those defines outside of wled.h itself — they are completely dead code. The whole WLED_MY_PINS block as written has no effect on any hardware configuration.

The PR should either:

  1. Remove the block entirely if it's left-over scaffolding, or
  2. Wire the defines into bus_manager.cpp by replacing the hardcoded mxconfig.gpio initialiser with the _pins struct that was already sketched out in the comment, and guard both sides with the board-specific build target.

(́◉◞౪◟◉‵)


✏️ Learnings added
Learnt from: softhack007
Repo: MoonModules/WLED-MM PR: 370
File: wled00/wled.h:1-17
Timestamp: 2026-06-20T22:10:37.043Z
Learning: In WLED-MM (MoonModules/WLED-MM), the HUB75 matrix driver pin configuration in `wled00/bus_manager.cpp` is hardcoded directly in `mxconfig.gpio = { ... }` and does NOT read from preprocessor defines such as R1_PIN, G1_PIN, B1_PIN, R2_PIN, G2_PIN, B2_PIN, A_PIN, B_PIN, C_PIN, D_PIN, E_PIN, LAT_PIN, OE_PIN, CLK_PIN. A commented-out line at bus_manager.cpp line 803 shows the former intended interface using those defines, but the live code ignores them. Any WLED_MY_PINS block defining these macros in wled.h is therefore dead code with no effect on the matrix hardware.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

#ifndef WLED_H
#define WLED_H
/*
Expand Down
Loading