ricardgb opened a new pull request, #3716:
URL: https://github.com/apache/nuttx-apps/pull/3716
## Summary
`examples/apa102` cannot be built as shipped. Two independent defects, both
hit
while bringing an APA102 strip up on an ESP32-S3:
**1. Wrong Kconfig dependency (`LCD_APA102` instead of `LEDS_APA102`).**
The example is written against the APA102 *LED-strip character driver*: it
opens
`/dev/leddrv0` and writes an array of `struct apa102_ledstrip_s` from
`<nuttx/leds/apa102.h>`. That node and that structure come from
`drivers/leds/apa102.c` (`CONFIG_LEDS_APA102`), whose `apa102_register()`
registers `/dev/leddrvN`.
`CONFIG_LCD_APA102` selects a completely different driver,
`drivers/lcd/apa102.c`, which drives an APA102 matrix as a framebuffer LCD
and
registers no `/dev/leddrvN` node at all.
The consequence is that the example is unusable either way:
- with the LED-strip driver enabled (`CONFIG_LEDS_APA102=y`) the dependency
is
unsatisfied, so the example is not selectable in `menuconfig` and is
silently
dropped from a configuration that requests it;
- with `CONFIG_LCD_APA102=y` the dependency is satisfied but the driver the
example needs is absent, so it fails at `open()`.
**2. Kernel-internal `_err()` macro used in application code.**
`apa102_main.c` reports a failed `write()` with `_err()`, a kernel-internal
debug macro from `<debug.h>`. An application cannot reference the kernel-only
`_err` symbol, so in a flat build the example fails to link:
```
xtensa-esp32s3-elf-ld: .../libapps.a(apa102_main.c...o): undefined reference
to `_err'
apps/examples/apa102/apa102_main.c:171: undefined reference to `_err'
```
This replaces it with `fprintf(stderr, ...)`, matching the `open()` error
path a
few lines above in the same function.
The two fixes are in separate commits.
## Impact
`examples/apa102` becomes selectable and linkable against the driver it was
actually written for. No behaviour change for any working configuration:
nothing
in-tree can currently build this example, and no in-tree defconfig sets
`CONFIG_EXAMPLES_APA102`.
Note for reviewers: `drivers/lcd/apa102.c` and `drivers/leds/apa102.c` share
a
basename, which causes an object-file collision when both `CONFIG_LCD_APA102`
and `CONFIG_LEDS_APA102` are enabled. That is a separate, driver-side
problem in
`apache/nuttx` and is being submitted as a companion change; it is not
needed for
this apps-side patch, which was verified with `CONFIG_LCD` off so that no
collision is possible.
## Testing
**Link verification** — `esp32s3-devkit:nsh` on current `master` of both
trees,
`xtensa-esp32s3-elf-gcc`, configured with `CONFIG_SPI=y`,
`CONFIG_ESP32S3_SPI3=y`,
`CONFIG_LEDS_APA102=y`, `CONFIG_EXAMPLES_APA102=y` and `CONFIG_LCD` left off:
*Defect 1, before* — with the original `depends on LCD_APA102`, requesting
the
example and then running `olddefconfig` drops it:
```
$ grep '^CONFIG_LEDS_APA102' .config
CONFIG_LEDS_APA102=y
$ grep EXAMPLES_APA102 .config
(nothing -- CONFIG_EXAMPLES_APA102 has been removed)
```
*Defect 2, before* — with the dependency corrected but `_err()` still in
place,
the build reaches the link stage and fails with the error quoted above.
*After both commits* — the same configuration builds and links clean, and the
example is present as a builtin:
```
LD: nuttx
ROM: 209872 B 4194272 B 5.00%
Generated: nuttx.bin
$ xtensa-esp32s3-elf-nm nuttx | grep apa102
420245d4 T apa102_main
```
**On hardware** — the same two changes (Kconfig dependency corrected,
`_err()`
replaced by a userspace print) were run on an ESP32-S3 with an APA102 on SPI3
(clock GPIO39, data GPIO40): the example opens `/dev/leddrv0` and cycles hue
continuously. Note the board carries a single onboard APA102 rather than a
chain, so this exercises the driver and the example's write path, not
multi-LED addressing.
`tools/checkpatch.sh` passes on the changed files and on the commit range.
## Disclosure
This analysis, patch, and hardware validation were performed by an AI agent
(Claude Code, operated and directed by the submitter), and the result was
reviewed by the submitter before posting.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
