Prevent arduino core from assigning default MISO pin#5672
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughIn ChangesDotStar SPI MISO Configuration Fix
🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with 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.
Inline comments:
In `@wled00/bus_wrapper.h`:
- Line 361: The inline comment next to the miso default workaround in
bus_wrapper.h contains a typo ("meaans"); update that comment to read "means" so
it correctly documents that in the Arduino core -1 means "default" and passing
127 prevents SPI.begin() from assigning the default pin (refer to the miso
variable and the SPI.begin() mention in the same line).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: cf6716cc-4df1-4e57-89b7-ad50d608a1e1
📒 Files selected for processing (1)
wled00/bus_wrapper.h
| #ifdef ESP8266 | ||
| dotStar_strip->Begin(); | ||
| #else | ||
| if (miso == -1) miso = 127; // note: in arduino core, -1 means "default" not "none", passing 127 as the MISO pin is a workaround to prevent SPI.begin() assign the default pin, see #5670 |
There was a problem hiding this comment.
@DedeHai is this workaround also working / needed for esp-idf V5 (arduino-esp32 3.5.x)?
If not, then we could wrap the line in #if ESP_IDF_VERSION_MAJOR == 4 .. #endif for future compatibility.
There was a problem hiding this comment.
from what I see, yes. the arduino.core code looks the same in the V5 branch
edit:
if it works the same I can't say - depends on what the IDF core does if you assign an out of scope pin but I would assume it wont tear down the SPI - just as it is in V4
There was a problem hiding this comment.
@coderabbitai please check if this workaround will still solve the problem in arduino-esp32 v3.5.x / esp-idf v5.x (see V5 branch). Review the related framework source code, don't rely solely on official espressif documentation.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Fetch arduino-esp32 SPI.cpp from the V5 branch (arduino-esp32 3.x / esp-idf v5)
curl -s "https://raw.githubusercontent.com/espressif/arduino-esp32/idf-release/v5.1/libraries/SPI/src/SPI.cpp" | head -200
echo "---SEPARATOR---"
# Also check the master/3.x branch
curl -s "https://raw.githubusercontent.com/espressif/arduino-esp32/master/libraries/SPI/src/SPI.cpp" | head -200Length of output: 5310
🏁 Script executed:
#!/bin/bash
# Check available branches for arduino-esp32 that correspond to 3.x/v5
curl -s "https://api.github.com/repos/espressif/arduino-esp32/branches?per_page=50" | python3 -c "
import json, sys
data = json.load(sys.stdin)
for b in data:
name = b['name']
if '3.' in name or 'v5' in name or 'idf5' in name or 'release' in name:
print(name)
"Length of output: 515
🏁 Script executed:
#!/bin/bash
# Fetch esp32-hal-spi.c from master (arduino-esp32 3.x) to check spiAttachMISO behavior
curl -s "https://raw.githubusercontent.com/espressif/arduino-esp32/master/cores/esp32/esp32-hal-spi.c" | grep -A 20 "spiAttachMISO"
echo "---SEPARATOR---"
# Also check the SPI.cpp begin() more fully (lines 60-160) to confirm the -1 guard
curl -s "https://raw.githubusercontent.com/espressif/arduino-esp32/master/libraries/SPI/src/SPI.cpp" | sed -n '60,160p'
echo "---SEPARATOR---"
# Check release/v3.1.x branch SPI.cpp as well (most likely what WLED targets)
curl -s "https://raw.githubusercontent.com/espressif/arduino-esp32/release/v3.1.x/libraries/SPI/src/SPI.cpp" | sed -n '60,160p'Length of output: 5856
@softhack007 Here are the findings from reviewing the actual arduino-esp32 source code on both branches.
arduino-esp32 v2.x / esp-idf v4 (current situation — workaround needed ✅)
In v2.x, when any non--1 pin is supplied alongside miso=-1, the Arduino core fills in a default MISO pin. The miso=127 workaround forces the underlying ESP-IDF to reject that assignment, preserving the "unused" state.
arduino-esp32 v3.x / esp-idf v5 (the problematic case ⚠️ )
SPIClass::begin() now has two important changes:
// 1. Default pins only assigned when ALL FOUR are -1
if (sck == -1 && miso == -1 && mosi == -1 && ss == -1) {
_miso = MISO; // default
} else {
_miso = miso; // stores -1 directly
}
// 2. MISO attachment explicitly guarded by >= 0
if (_miso >= 0 && !spiAttachMISO(_spi, _miso)) {
goto err;
}With miso=-1 (no workaround) in v3.x: Since sck/mosi are real pins, the else-branch stores _miso=-1. The guard -1 >= 0 is false, so spiAttachMISO is skipped entirely — correct behavior, no default pin assigned. ✅
With miso=127 (workaround) in v3.x: _miso=127, the guard 127 >= 0 is true, so it calls spiAttachMISO(spi, 127). Looking at the HAL:
bool spiAttachMISO(spi_t *spi, int8_t miso) {
if (!spi || miso < 0) { return false; } // 127 is positive, passes this check
// ...
pinMode(127, INPUT); // invalid GPIO on all ESP32 variants
pinMatrixInAttach(127, ...); // invalid pin
perimanSetPinBus(127, ...); // likely fails → returns falseThis means:
- In v3.1.x (
void begin):goto erris hit, logging"Attaching pins to SPI failed."on every boot — confusing but the SPI bus may still function without MISO. - In master (
bool begin):begin()returnsfalse— if NeoPixelBus checks this, the strip initialization fails silently.
Recommendation
Wrap the workaround in an IDF version guard so it only applies where it's needed:
`#if` ESP_IDF_VERSION_MAJOR < 5
if (miso == -1) miso = 127; // note: in arduino core v2.x, -1 means "default" not "none", passing 127 as the MISO pin is a workaround to prevent SPI.begin() assigning the default pin, see `#5670`
`#endif`In esp-idf v5.x the original -1 is handled correctly by the _miso >= 0 guard in SPIClass::begin(), and the workaround actively causes harm there (error log at minimum, possible begin() failure).
✏️ Learnings added
Learnt from: softhack007
Repo: wled/WLED PR: 5672
File: wled00/bus_wrapper.h:361-361
Timestamp: 2026-06-09T17:25:51.318Z
Learning: In arduino-esp32 v3.x (esp-idf v5.x), `SPIClass::begin()` in `libraries/SPI/src/SPI.cpp` correctly handles `miso=-1` via the guard `if (_miso >= 0 && !spiAttachMISO(_spi, _miso))` — meaning no workaround is needed. The `miso=127` workaround used in `PolyBus::beginDotStar()` (wled00/bus_wrapper.h) for arduino-esp32 v2.x/esp-idf v4.x is harmful in v3.x/v5.x because `int8_t(127)` is positive, passes the `< 0` guard in `spiAttachMISO`, and causes `begin()` to attempt attaching an invalid GPIO (127), resulting in an error log or `begin()` returning false. The correct fix is to guard the workaround with `#if ESP_IDF_VERSION_MAJOR < 5`.
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.
🧠 Learnings used
Learnt from: softhack007
Repo: wled/WLED PR: 5355
File: wled00/util.cpp:635-638
Timestamp: 2026-02-07T16:06:08.677Z
Learning: PSRAM-related compilation guards should enable PSRAM code only for ESP32 variants that actually include PSRAM: ESP32-C61, ESP32-C5, and ESP32-P4. Exclude ESP32-C3, ESP32-C6, and ESP8266 from these guards. Apply this rule across the codebase (not just wled00/util.cpp) by reviewing and updating PSRAM guards/macros in all relevant files (C/C++ headers and sources).
Learnt from: softhack007
Repo: wled/WLED PR: 4838
File: lib/NeoESP32RmtHI/src/NeoEsp32RmtHIMethod.cpp:30-35
Timestamp: 2026-03-27T12:33:48.499Z
Learning: In C/C++ preprocessor conditionals (`#if`, `#elif`) GCC/Clang treat `&&` as short-circuit evaluated during preprocessing. This means guards like `#if defined(ARDUINO_ARCH_ESP32) && ESP_IDF_VERSION < ESP_IDF_VERSION_VAL(5, 0, 0)` are safe even if the macro/function-like macro on the RHS (e.g., `ESP_IDF_VERSION_VAL`) is not defined on some targets, because the RHS will not be expanded when the LHS is false (e.g., `defined(...)` evaluates to 0). During code review, avoid flagging such cases as “undefined function-like macro invocation” if they are protected by short-circuiting `defined(...) && ...`/`||` logic; some tools like cppcheck may not model this and can produce false positives. Also, don’t suggest refactoring that moves ESP32-specific includes/headers (e.g., `esp_idf_version.h`) outside of these guarded preprocessor blocks, since that will break targets (e.g., ESP8266) where the headers don’t exist.
Learnt from: softhack007
Repo: wled/WLED PR: 4843
File: usermods/elastic_collisions/Elastic_Collisions.cpp:1-1
Timestamp: 2026-05-06T22:10:27.517Z
Learning: In C/C++, do not flag precedence issues for expressions that mix additive operators (`+`, `-`) with shift operators (`<<`, `>>`) based on the assumption that shifts bind tighter. Per C/C++ operator precedence, `+`/`-` have higher precedence than `<<`/`>>` (e.g., `x - edge0 << 8` parses as `(x - edge0) << 8`). When reviewing WLED (and other) fixed-point/bit-manipulation code, confirm the intended parse using cppreference before reporting a precedence bug for mixed `-`/`+` and `<<`/`>>` expressions.
There was a problem hiding this comment.
@softhack007 don't trust the rabbit on this one. he skipped the HAL call a few lines below its quote. what it wrote is also true for V4 but its incomplete.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
willmmiles
left a comment
willmmiles
left a comment
There was a problem hiding this comment.
Translating between our convention (-1 == unassigned) and whatever the arduino core does is the right way.
That said: this will break the setup of people who didn't think to set the pin because it turned out that they'd wired it on the default, and it just worked. I don't know if we want to think about some kind of upgrade handoff here. At the very least we'll need a "possibly breaking change" note on this one.
I do not follow (on both counts). This is only about the MISO i.e. input pin which is unused for LED purposes. Is there any dual-use of the SPI and is that even allowed? The scenario I imagine is that the busmanager claims the SPI via NPB and after that a UM also uses that same SPI - which would initialize it anew. Or what is the scenario? |
3 participants
Adds invalid dummy pin if miso is undefined to prevent default fallback
fixes #5670
copy of comment from #5670:
Summary by CodeRabbit