Source:
PinList.h
CorePinList¶
One text control such as 18,17,16 turned into the pins a driver claims.
Functions¶
| Return | Name | Description |
|---|---|---|
const char * |
appendPin inline |
Append one pin, enforcing the chip ceiling, the duplicate check and the lane cap. |
const char * |
parsePinList inline |
Parse s into out, nOut receiving the count, returning null or an error literal. |
appendPin¶
inline
Append one pin, enforcing the chip ceiling, the duplicate check and the lane cap.
parsePinList¶
inline
Parse s into out, nOut receiving the count, returning null or an error literal.
More info¶
Why this lives in core¶
Both a light driver's pins control and the core [PinsModule] pin-ownership map read the same CSV. The parser therefore sits in core, and the dependency runs from the domain into core rather than the other way. It is strtol-based like parseDottedQuad in Control.h, and returns null on success or a static error literal the caller hands straight to setStatus. unit_RmtLedDriver_pins.cpp and unit_PinsModule.cpp pin it on the host.
What a token may be¶
A token is a single pin such as 17 or an inclusive range such as 20-23, and the two mix freely as in 20-22,35,38-40. That is the same range idiom the IP destination list uses, so a human types consecutive entries once, and spaces around tokens are fine because strtol skips them.
What gets rejected, and why the ceiling matters¶
The parser refuses empty input, bad tokens, trailing commas, duplicates, ranges that run backwards, pins above the chip's MM_MAX_GPIO ceiling, and more entries than the caller's lane cap allows.
The ceiling check is the crash guard. A pin like 999 parses as a valid integer but is not a GPIO, and handing it to IDF's gpio_func_sel faults with a GPIO number error and resets the board. Rejecting it at the one parse boundary every driver shares, RMT, Parlio and i80 alike, keeps a garbage pin from reaching hardware, so no driver re-guards it.