Prevent arduino core from assigning default MISO pin

[DedeHai]

Adds invalid dummy pin if miso is undefined to prevent default fallback

fixes #5670

copy of comment from #5670:

I have found a fix that works around this arduino core quirk, to not say bug. In beginDotStar() adding this line fixes it:
if (miso == -1) miso = 127;
For reference:
in IDF passing a "-1" as a pin means unused
in arduino core a "-1" as apin means "use default"
the solution is to pass an invalid pin to the arduino function, it will then try to assign it, the underlaying IDF API rejects the pin, arduino core does not even check if it fails and just move on.
The default assignment by arduino may actually have some other side-effects when using clocked LEDs in combination with default MISO pins, all ESP32 flavours are affected.

Summary by CodeRabbit

• Bug Fixes
  • Resolved an issue on non-ESP8266 boards where DotStar LED initialization could pick an incorrect default SPI pin, causing erratic or non-working LED output. This update ensures the SPI setup respects caller intent and prevents unintended pin reassignment during DotStar startup, improving LED reliability on affected platforms.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: ef5866f8-2f5b-4250-bb20-189219b85cc7

📥 Commits

Reviewing files that changed from the base of the PR and between 95f9588 and 7443f16.

📒 Files selected for processing (1)

• wled00/bus_wrapper.h

🚧 Files skipped from review as they are similar to previous changes (1)

• wled00/bus_wrapper.h

---

Walkthrough

In PolyBus::beginDotStar, when configuring DotStar LEDs via SPI on non-ESP8266 platforms, the code now overrides an invalid MISO pin value of -1 to 127, documented as an Arduino-core workaround to prevent unintended default MISO pin assignment.

Changes

DotStar SPI MISO Configuration Fix

Layer / File(s)	Summary
MISO pin default override wled00/bus_wrapper.h	PolyBus::beginDotStar now treats miso == -1 as "use default" by overriding it to 127, with a comment documenting this as an Arduino SPI workaround to prevent SPI.begin() from assigning the default MISO pin on non-ESP8266 platforms.

---

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and clearly describes the main change: preventing the Arduino core from assigning a default MISO pin.
Linked Issues check	✅ Passed	The PR directly addresses issue #5670 by implementing a workaround to prevent default MISO pin assignment when MISO is intended to be unused, restoring clocked LED functionality.
Out of Scope Changes check	✅ Passed	The single line change is narrowly scoped to the DotStar SPI setup in PolyBus::beginDotStar, directly addressing the MISO pin assignment issue without introducing unrelated modifications.

_{✏️ 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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

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

📥 Commits

Reviewing files that changed from the base of the PR and between 5f79107 and 95f9588.

📒 Files selected for processing (1)

• wled00/bus_wrapper.h

[softhack007]

@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.

[DedeHai]

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

[willmmiles]

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.

[DedeHai]

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?