Added support for LSC Smart connect led strips #5177
+54
−4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Support is added for LSC Smart Connect led strips which are sold at ACTION stores around Europe. These strips are special because they use dual SM16703 chips, the first is used for controlling a RGB LED, the second is used for WW and CW. For controlling the strip this gives 6 channels in a row: G,R,B,WW,CW,N/C which means the 3th channel of the second SM16703 chip is not used. Firmware was built using these files and tested on Wemo D1 mini.
In this commit,support is added for LSC Smart Connect led strips which are sold at ACTION stores around Europe. These strips are special because they use dual SM16703 chips, the first is used for controlling a RGB LED, the second is used for WW and CW. For controlling the strip this gives 6 channels in a row: G,R,B,WW,CW,N/C which means the 3th channel of the second SM16703 chip is not used. Recommitted because CodeRabbit found that the skipping LED function calculation was not yet up to date with the usage of 2 IC`s - Firmware was built using these files and tested on Wemo D1 mini. - In the UI the strip is called “SM16703 RGB+CCT (2x)” - Product: https://www.action.com/nl-nl/p/3218153/lsc-smart-connect-ledstrip/
Contributor
WalkthroughIntroduces support for TYPE_SM16703_DUAL, a new LED type representing dual SM16703 chips per logical pixel. Updates initialization, pixel setting logic, and type checks across multiple files to handle dual-chip configuration including CCT color temperature support. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
wled00/bus_manager.cpp (2)
375-396: MissingTYPE_SM16703_DUALhandling ingetPixelColor().While
setPixelColor()has special dual-chip handling,getPixelColor()doesn't account for the 2x hardware pixel mapping. This will cause incorrect color reads forTYPE_SM16703_DUAL:// Current code reads from hardware index `pix`, but should read from `pix * 2` uint32_t c = restoreColorLossy(PolyBus::getPixelColor(_busPtr, _iType, ... pix ...), _NPBbri);Consider adding dual-chip handling similar to
setPixelColor():if (_type == TYPE_SM16703_DUAL) { if (_reversed) pix = _len - pix - 1; pix += _skip; unsigned firstIdx = pix * 2; // Read RGB from first chip, ignore second chip's WW/CW const uint8_t co = _colorOrderMap.getPixelColorOrder(pix + _start, _colorOrder); return restoreColorLossy(PolyBus::getPixelColor(_busPtr, _iType, firstIdx, co), _NPBbri); }This affects features like reading back pixel state for effects or transitions.
261-270: MissingTYPE_SM16703_DUALhandling inapplyBriLimit().The hardware length calculation on line 263 doesn't account for dual-chip mode, causing brightness limiting to only process half the physical pixels:
unsigned hwLen = _len; if (_type == TYPE_WS2812_1CH_X3) hwLen = NUM_ICS_WS2812_1CH_3X(_len); // Missing: if (_type == TYPE_SM16703_DUAL) hwLen = (_len + _skip) * 2;This will result in incomplete brightness correction for dual-chip strips. Add the dual-chip case:
unsigned hwLen = _len; if (_type == TYPE_WS2812_1CH_X3) hwLen = NUM_ICS_WS2812_1CH_3X(_len); + if (_type == TYPE_SM16703_DUAL) hwLen = (_len + _skip) * 2;Additionally, the loop logic would need adjustment since it currently calls
getPixelColor/setPixelColoron PolyBus directly with a single index, but dual-chip needs paired indices and separate RGB/WW-CW handling.
🧹 Nitpick comments (1)
wled00/bus_manager.cpp (1)
308-316: Consider including WW/CW in the wacky ABL model fallback.The wacky WS2815 power model (when
_milliAmpsPerLed == 255) ignores the WW/CW channels and only uses max RGB. SinceTYPE_SM16703_DUALhas two separate chips, you might want to include WW/CW contribution in the power estimation even for the wacky model:} else { // wacky model not expected; fall back to max RGB uint8_t maxRgb = (r > g) ? ((r > b) ? r : b) : ((g > b) ? g : b); - _colorSum += maxRgb; + _colorSum += maxRgb + ww + cw; // include WW/CW from second chip }This is a minor enhancement since the wacky model is WS2815-specific and unlikely to be used with SM16703 strips.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
wled00/bus_manager.cpp(3 hunks)wled00/bus_manager.h(1 hunks)wled00/bus_wrapper.h(2 hunks)wled00/const.h(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
wled00/**/!(html_*)*.h
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use 2-space indentation for non-generated C++ header files (.h)
Files:
wled00/bus_manager.hwled00/bus_wrapper.hwled00/const.h
wled00/**/*.cpp
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use 2-space indentation for C++ source files (.cpp)
Files:
wled00/bus_manager.cpp
🧠 Learnings (25)
📓 Common learnings
Learnt from: DedeHai
Repo: wled/WLED PR: 4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.
Learnt from: DedeHai
Repo: wled/WLED PR: 4997
File: wled00/e131.cpp:33-44
Timestamp: 2025-10-10T18:34:06.550Z
Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.
📚 Learning: 2025-09-18T03:17:30.107Z
Learnt from: willmmiles
Repo: wled/WLED PR: 4939
File: wled00/FX_fcn.cpp:1183-1194
Timestamp: 2025-09-18T03:17:30.107Z
Learning: In WLED BusManager (wled00/FX_fcn.cpp), direct access to BusManager::busses is part of the intended public API design, not an encapsulation violation. The wrapper accessor methods are considered unnecessary obfuscation that should be removed in future refactoring.
Applied to files:
wled00/bus_manager.hwled00/bus_wrapper.hwled00/bus_manager.cpp
📚 Learning: 2025-09-18T03:17:30.107Z
Learnt from: willmmiles
Repo: wled/WLED PR: 4939
File: wled00/FX_fcn.cpp:1183-1194
Timestamp: 2025-09-18T03:17:30.107Z
Learning: In WLED bus management code, dead code branches in error handling (like unreachable else breaks) are intentionally preserved to accommodate potential future API changes, even when currently unreachable.
Applied to files:
wled00/bus_manager.hwled00/bus_wrapper.hwled00/bus_manager.cpp
📚 Learning: 2025-09-16T18:08:42.848Z
Learnt from: DedeHai
Repo: wled/WLED PR: 4939
File: wled00/FX_fcn.cpp:1176-1187
Timestamp: 2025-09-16T18:08:42.848Z
Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), intentionally allowing memory overruns when bus configurations exceed MAX_LED_MEMORY is a deliberate design choice. The trade-off prioritizes creating buses with reduced LED counts over completely failing to create buses, which would cause no LED output and UI failures. This approach forces users to update configurations after migrating to version 0.16 while maintaining basic functionality.
Applied to files:
wled00/bus_manager.hwled00/bus_wrapper.hwled00/bus_manager.cpp
📚 Learning: 2025-09-21T20:44:09.502Z
Learnt from: DedeHai
Repo: wled/WLED PR: 4928
File: wled00/bus_wrapper.h:1248-1275
Timestamp: 2025-09-21T20:44:09.502Z
Learning: In WLED bus_wrapper.h, the _useParallelI2S flag is used for selecting the correct function pointer (between parallel I2S and non-parallel I2S bus types) rather than for changing memory calculations. Both parallel and non-parallel I2S configurations have the same memory requirements, so memUsage() correctly doesn't differentiate based on this flag.
Applied to files:
wled00/bus_wrapper.hwled00/bus_manager.cpp
📚 Learning: 2025-09-18T03:17:30.107Z
Learnt from: willmmiles
Repo: wled/WLED PR: 4939
File: wled00/FX_fcn.cpp:1183-1194
Timestamp: 2025-09-18T03:17:30.107Z
Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), digitalCount is intentionally incremented even for placeholder buses to maintain consistent resource mapping across all bus configurations.
Applied to files:
wled00/bus_wrapper.hwled00/bus_manager.cpp
📚 Learning: 2025-09-02T01:45:58.047Z
Learnt from: willmmiles
Repo: wled/WLED PR: 4890
File: lib/NeoESP32RmtHI/include/NeoEsp32RmtHIMethod.h:31-36
Timestamp: 2025-09-02T01:45:58.047Z
Learning: For the NeoEsp32RmtHI driver, RISC-V ESP32-C3 support is currently disabled via bus_wrapper.h rather than compile-time guards, as the maintainer willmmiles is working on resolving underlying nested interrupt issues and prefers to centralize the workaround in one location.
Applied to files:
wled00/bus_wrapper.h
📚 Learning: 2025-11-14T13:37:30.955Z
Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:30.955Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with defined constants when meaningful constants exist in the codebase. For example, suggest replacing hardcoded "32" with WLED_MAX_SEGNAME_LEN if the context relates to segment name length limits.
Applied to files:
wled00/const.hwled00/bus_manager.cpp
📚 Learning: 2025-11-14T13:37:11.994Z
Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:11.994Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.
Applied to files:
wled00/const.hwled00/bus_manager.cpp
📚 Learning: 2025-10-05T15:24:05.545Z
Learnt from: CR
Repo: wled/WLED PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-10-05T15:24:05.545Z
Learning: Applies to wled00/html_*.h : DO NOT edit generated embedded web header files (wled00/html_*.h)
Applied to files:
wled00/const.h
📚 Learning: 2025-04-26T19:19:07.600Z
Learnt from: blazoncek
Repo: wled/WLED PR: 4658
File: wled00/const.h:140-141
Timestamp: 2025-04-26T19:19:07.600Z
Learning: In WLED, the WLED_MAX_PANELS macro is intentionally defined as a fixed constant value (18) with no redefinition mechanism, making it "unoverridable" - there's no need for a static assertion to check its maximum value.
Applied to files:
wled00/const.h
📚 Learning: 2025-08-28T08:09:20.630Z
Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/xml.cpp:0-0
Timestamp: 2025-08-28T08:09:20.630Z
Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.
Applied to files:
wled00/const.h
📚 Learning: 2025-09-01T10:26:17.959Z
Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/wled_eeprom.cpp:0-0
Timestamp: 2025-09-01T10:26:17.959Z
Learning: In WLED PR #4876, the DMXStartLED EEPROM backward compatibility issue was partially addressed by keeping it at address 2550 and reading it as a 16-bit value, with DMXChannelsValue array moved to addresses 2552-2566. This maintains compatibility with pre-0.11 EEPROM layouts for DMXStartLED, though legacy "Set to 255" (code 6) configurations may still need migration logic.
Applied to files:
wled00/const.hwled00/bus_manager.cpp
📚 Learning: 2025-08-31T03:38:14.114Z
Learnt from: BobLoeffler68
Repo: wled/WLED PR: 4891
File: wled00/FX.cpp:3333-3349
Timestamp: 2025-08-31T03:38:14.114Z
Learning: WLED PacMan effect (wled00/FX.cpp): Keep pacmancharacters_t position fields as signed int (not int16_t). Maintainer preference (blazoncek) prioritizes avoiding potential overhead/regressions over minor RAM savings. Avoid type shrinking here unless memory pressure is demonstrated.
Applied to files:
wled00/const.h
📚 Learning: 2025-11-16T19:40:46.260Z
Learnt from: DedeHai
Repo: wled/WLED PR: 4926
File: wled00/FX.cpp:4727-4730
Timestamp: 2025-11-16T19:40:46.260Z
Learning: WLED AuroraWave (wled00/FX.cpp): wave_start and wave_end intentionally use int16_t; segments longer than 32k LEDs are not supported (bounded by MAX_LEDS), so widening to 32-bit is unnecessary.
Applied to files:
wled00/const.h
📚 Learning: 2025-08-26T11:51:21.817Z
Learnt from: DedeHai
Repo: wled/WLED PR: 4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.
Applied to files:
wled00/const.hwled00/bus_manager.cpp
📚 Learning: 2025-12-01T07:01:16.949Z
Learnt from: blazoncek
Repo: wled/WLED PR: 5140
File: wled00/data/settings_time.htm:66-76
Timestamp: 2025-12-01T07:01:16.949Z
Learning: In WLED PR #5134, the fix for macros being initialized with the enable bit set only handles new configurations, not existing ones. If there is a bug in timer/macro handling code (e.g., in settings_time.htm), it must be fixed to work correctly for existing configurations as well.
Applied to files:
wled00/const.h
📚 Learning: 2025-06-15T09:59:52.720Z
Learnt from: netmindz
Repo: wled/WLED PR: 4728
File: wled00/FX.h:378-378
Timestamp: 2025-06-15T09:59:52.720Z
Learning: In WLED's FX.h, MODE_COUNT represents the highest FX_MODE_ ID + 1, not the total count of FX_MODE_ definitions. This is because some effects may have been removed but their IDs are not reused, creating gaps in the numbering sequence. MODE_COUNT is used for array bounds and range checking.
Applied to files:
wled00/const.h
📚 Learning: 2025-10-10T18:34:06.550Z
Learnt from: DedeHai
Repo: wled/WLED PR: 4997
File: wled00/e131.cpp:33-44
Timestamp: 2025-10-10T18:34:06.550Z
Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.
Applied to files:
wled00/bus_manager.cpp
📚 Learning: 2025-09-28T09:53:42.670Z
Learnt from: DedeHai
Repo: wled/WLED PR: 4939
File: wled00/data/index.js:2406-2413
Timestamp: 2025-09-28T09:53:42.670Z
Learning: In WLED bus management, bus objects can exist with valid configuration data even when isOK() returns false. The getPins() method can be safely called on buses that are not OK, as the bus object and its configuration exist independently of the isOK() status, which specifically indicates whether the NeoPixel bus was successfully created.
Applied to files:
wled00/bus_manager.cpp
📚 Learning: 2025-09-02T01:56:43.841Z
Learnt from: willmmiles
Repo: wled/WLED PR: 4890
File: lib/NeoESP32RmtHI/include/NeoEsp32RmtHIMethod.h:173-180
Timestamp: 2025-09-02T01:56:43.841Z
Learning: willmmiles prefers to maintain consistency with upstream NeoPixelBus patterns (like unchecked malloc in construct() methods) rather than diverging until improvements are made upstream first, to minimize maintenance burden and keep the codebase aligned.
Applied to files:
wled00/bus_manager.cpp
📚 Learning: 2025-09-13T13:13:36.092Z
Learnt from: netmindz
Repo: wled/WLED PR: 3777
File: wled00/bus_manager.cpp:982-989
Timestamp: 2025-09-13T13:13:36.092Z
Learning: In the WLED HUB75 implementation, when HUB75 matrix initialization fails after pin allocation, pins are intentionally not deallocated because they're physically connected to the HUB75 panel and cannot be reused for other purposes. This design choice prioritizes simplicity over strict software resource management consistency.
Applied to files:
wled00/bus_manager.cpp
📚 Learning: 2025-11-22T12:12:53.486Z
Learnt from: DedeHai
Repo: wled/WLED PR: 5105
File: wled00/FX.h:968-968
Timestamp: 2025-11-22T12:12:53.486Z
Learning: In WLED's WS2812FX class (wled00/FX.h), the _pixels array stores LED colors indexed by unmapped (logical) LED positions, not physical positions. The getPixelColor(n) function intentionally checks if the logical LED at index n maps to a valid physical position via getMappedPixelIndex(n), then accesses _pixels[n] with the unmapped index. If the mapping is invalid (e.g., -1 for gaps in LED maps, or out of bounds), it returns 0 (black). This allows peek preview to correctly show gaps in LED mappings as black pixels. The mapping from logical to physical positions is only applied when writing to the hardware bus, not when reading from the pixel buffer.
<!-- [add_learning]
Applied to files:
wled00/bus_manager.cpp
📚 Learning: 2025-11-14T05:48:44.673Z
Learnt from: DedeHai
Repo: wled/WLED PR: 5040
File: wled00/image_loader.cpp:84-96
Timestamp: 2025-11-14T05:48:44.673Z
Learning: In WLED (wled00/FX_2Dfcn.cpp), the Segment::setPixelColorXY() function performs internal bounds checking against vWidth() and vHeight(), returning early if coordinates are out of bounds. No additional guards are needed when calling this function, even in upscaling loops where coordinates might exceed segment dimensions.
Applied to files:
wled00/bus_manager.cpp
📚 Learning: 2025-06-07T15:58:42.579Z
Learnt from: willmmiles
Repo: wled/WLED PR: 4712
File: wled00/FX_fcn.cpp:992-993
Timestamp: 2025-06-07T15:58:42.579Z
Learning: In WLED segments, the backing pixel buffer is always allocated to the full physical segment size, but effect rendering only uses a subset when mirror or grouping are enabled. For 2D segments, this subset is vWidth() * vHeight(), and for 1D segments it's vLength(). Color processing operations like fade_out should iterate over this rendering subset, not the full allocated buffer.
Applied to files:
wled00/bus_manager.cpp
🔇 Additional comments (9)
wled00/const.h (1)
308-308: LGTM!The new constant
TYPE_SM16703_DUALis correctly defined with value 35, fitting within the digital type range (16-39). The descriptive comment accurately documents the dual-chip configuration (RGB chip + WW/CW chip with unused B channel).wled00/bus_manager.h (2)
177-178: LGTM!
TYPE_SM16703_DUALis correctly added tohasWhite()with a clear comment. Since the second SM16703 chip controls WW/CW channels, this type rightfully has white capability.
186-186: LGTM!
TYPE_SM16703_DUALis correctly included inhasCCT()alongside other CCT-capable types likeTYPE_WS2805andTYPE_SM16825.wled00/bus_wrapper.h (2)
1318-1319: LGTM!
TYPE_SM16703_DUALcorrectly maps to the standard NeoPixel 3-channel bus type on ESP8266. This is appropriate since SM16703 uses the same protocol as WS2812, and the dual-chip pixel handling is managed at a higher level inBusDigital::setPixelColor().
1382-1383: LGTM!ESP32 path mirrors the ESP8266 mapping, correctly routing
TYPE_SM16703_DUALtoI_32_RN_NEO_3 + offset.wled00/bus_manager.cpp (4)
189-195: LGTM on initialization logic.The length calculation
(bc.count + _skip) * 2correctly allocates two hardware pixels per logical pixel (including skip pixels). The conditionalPolyBus::create()call appropriately handles the already-computed length for dual-chip mode versus adding skip separately for other types.
198-201: LGTM!Sacrificial pixel handling correctly doubles the skip count for the dual-chip configuration, ensuring both physical chips per logical skip pixel are initialized to black.
324-326: LGTM!Bounds checking correctly validates against the hardware buffer length and uses
secondIdx(the larger index of the two chips) to ensure both writes are safe.
418-418: LGTM!The new LED type is properly exposed in the public API with a clear, descriptive name "SM16703 RGB+CCT (2x)" that communicates the dual-chip configuration.
Comment on lines
+331
to
+338
| // Second chip: R=WW, G=CW by default; respect WW/CW swap flag (upper nibble of color order) | ||
| const uint8_t coSecond = _colorOrderMap.getPixelColorOrder(logicalPix + _start, _colorOrder); | ||
| bool swapWhites = true; // hardware wiring has WW/CW reversed relative to CCT | ||
| if ((coSecond >> 4) & 0x01) swapWhites = !swapWhites; // UI swap toggles | ||
| if (swapWhites) { uint8_t tmp = ww; ww = cw; cw = tmp; } | ||
| uint32_t wwCwColor = RGBW32(ww, cw, 0, 0); | ||
| PolyBus::setPixelColor(_busPtr, _iType, secondIdx, wwCwColor, COL_ORDER_GRB, 0); | ||
| return; |
Contributor
There was a problem hiding this comment.
Potential issue with WW/CW swap detection.
The swap logic on line 334 checks (coSecond >> 4) & 0x01, but the WW/CW swap flag in the color order upper nibble is value 4 (as seen in bus_wrapper.h line 809: case 4: std::swap(cctWW, cctCW);). Checking bit 0 won't detect value 4:
| Upper nibble | Binary | & 0x01 result |
|---|---|---|
| 0 (no swap) | 0000 | false |
| 1 (W&B) | 0001 | true |
| 4 (WW&CW) | 0100 | false |
If the intent is to respect the WW/CW swap setting from the UI, the condition should check for value 4 specifically:
- bool swapWhites = true; // hardware wiring has WW/CW reversed relative to CCT
- if ((coSecond >> 4) & 0x01) swapWhites = !swapWhites; // UI swap toggles
+ bool swapWhites = true; // hardware wiring has WW/CW reversed relative to CCT
+ if ((coSecond >> 4) == 4) swapWhites = !swapWhites; // UI WW/CW swap togglesPlease verify this matches the intended behavior for the LSC Smart Connect strips.
🤖 Prompt for AI Agents
In wled00/bus_manager.cpp around lines 331 to 338, the WW/CW swap check shifts
the upper nibble then tests bit 0 which misses the UI swap value 4; change the
condition to extract the upper nibble (coSecond >> 4) and compare it to 4 (or
test ( (coSecond >> 4) & 0x07 ) == 4 if you want to be explicit about possible
values) so the WW/CW swap is honored; keep the rest of the swap logic and pixel
write unchanged.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Support is added for LSC Smart Connect led strips which are sold at ACTION stores around Europe. These strips are special because they use dual SM16703 chips, the first is used for controlling a RGB LED, the second is used for WW and CW. For controlling the strip this gives 6 channels in a row: G,R,B,WW,CW,N/C which means the 3th channel of the second SM16703 chip is not used.
Recommitted because CodeRabbit found that the skipping LED function calculation was not yet up to date with the usage of 2 IC`s
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.