zephyr-cp: add neopixel_write for nordic boards - #11475

Claude wrote most of the code, with @dhalbert steering and testing. @dhalbert revised this post extensively for clarity.

• Add neopixel_write for the zephyr-cp port on Nordic.
• Tries PWM with EasyDMA first. Interrupts stay enabled, so the on-core BLE controller is unaffected.
  • PWM nodes are enabled in the board overlay with disconnected outputs and zephyr,deferred-init. Zephyr's PWM driver is compiled but not currently initialized on them.
  • The PWM instance is allocated from iobroker for each write and then released, so pwmio can share the same instances later.
• The transmit code is a new Zephyr module, internal-modules/neopixel, with a CircuitPython-free API, so other Zephyr projects can share it. common-hal/neopixel_write keeps only the latch-period guard and the stack-or-heap pattern buffer choice.
• IOBroker changes:
  • Add iobroker_pwm_allocate() and a pwm pool in the generated board tables.
  • Add iobroker_pwm_allocate_unrouted(), for a caller that owns the pin and drives the instance's registers itself. It names the pin but claims only the instance.
  • Make iobroker_package_pin_soc_pad() public so the neopixel module can use it.
  • nRF54L requires peripherals to use pins in their own power domain, and iobroker now enforces that. An allocation whose pins no instance can reach fails with -ENXIO. busio then raises ValueError: Invalid pins, instead of silently producing no output.
• To support status NeoPixels:
  • Add STATUS_NEOPIXEL and STATUS_NEOPIXEL_POWER keys in circuitpython.toml. The keys name entries in the board's existing [pins] table.
  • Emit MICROPY_HW_NEOPIXEL and CIRCUITPY_STATUS_LED_POWER into the generated mpconfigboard.h.
• Enabled on:
  • Feather nRF52840 Express, Feather Bluefruit Sense, and CLUE.
  • nRF54LM20 DK and nRF54L15 DK, with PWM instances 21 and 22. Instance 20 stays the board's PWM LED.
  • nRF5340 DK, with PWM instances 1-3. Instance 0 stays the board's PWM LED.
• It requires CONFIG_PWM_NRFX=y, so other nRF boards are unchanged until their overlays add routable PWM instances.

Implementation notes

• The module's per-SoC implementations live in src/<vendor>/<soc>/, like iobroker's. src/nordic/nrf/neopixel_nrf.c is the only one so far.
• As in ports/nordic, the implementation will use a buffer on the stack for pixel strips up to 24 RGB pixels (18 RGBW). Longer strips allocate a heap buffer, which is freed in reset_port().
• Zephyr's led_strip drivers were not used. They fix the pin, chain length and byte order in devicetree and send zero for the W channel.

Bit-bang fallback

• If no PWM peripheral is available (all busy, or none can reach the pin), fall back to a DWT bit-bang implementation. Zephyr's proposed fast GPIO API (RFC: Fast GPIO API Extension zephyrproject-rtos/zephyr#106831) could replace this; we can switch to that API when it is available.
• During bit-bang, most interrupts are locked out, as ports/nordic does. But doing this carelessly messes up BLE. So set two port Kconfig defaults for nRF. They also protect the port's other critical sections (bitbangio, onewireio, microcontroller.disable_interrupts()).
  • Set ZERO_LATENCY_IRQS so the controller's radio ISR bypasses irq_lock().
  • Set BT_CTLR_ASSERT_OVERHEAD_START=n so a radio event delayed past the controller's 733 us prepare time budget is skipped. Without the latter, a 16-pixel bit-banged frame during advertising triggered a fatal assertion.
• Not on nRF54L P0 pins: that port's GPIO is in the low-power domain, and runs too slowly for NeoPixel bit-bang. P0 pins raise ValueError: Invalid pin.
• Every bit period is checked to see if the timing worked. A bit that ran more than twice its nominal length means an interrupt preempted the frame. The frame is then resent after the strip's reset period, up to 8 attempts. This is a little more robust than what was done in ports/nordic.

Testing

• Feather nRF52840 Express, Sense, and CLUE: status NeoPixel works.
• Feather nRF52840 Express, with a 16-pixel RGBW ring on A0: solid, rainbow, chase and breathe patterns. Also 500 consecutive 30-pixel writes, with BLE advertising running throughout.
• Bit-bang forced on in a test build on the Feather nRF52840: the RGBW ring animates correctly. With BLE advertising running, a 201-write burst saw 13 preempted frames. All were resent successfully (11 on the second attempt, 2 on the third), with no controller assertion. Before the Kconfig change, the same test halted the board.
• nRF54LM20 DK: Tested on these pins:
  • PORT1_10: P1, PWM, and forced bit-bang with BLE advertising happening simultaneously: 200 writes, 10 preempted frames, all resent
  • PORT3_00: P3, PWM, and forced bit-bang
  • PORT2_08: P2, bit-bang.
  • PORT0_01 and PORT0_02 raise ValueError: Invalid pin
  • (testing new code in iobroker) busio.SPI/busio.UART on pads that can't be used now raise ValueError: Invalid pins. The DK's only UART instance that busio can allocate, uart30, is in the P0 domain, so for UART it is the P1 request that is rejected.
• nRF54L15 DK, after configuring VDD from 1.8V to 3.3V: the ring works on P1_11 (P1, PWM) and P2_08 (P2, bit-bang). P0_02 raises ValueError: Invalid pin.
• nRF5340 DK: builds; untested.
• cptools/tests pass, including four new tests for the toml status-pin resolver.

Not in this PR

• The nRF PWM driver's lack of a deinit hook, which matters once pwmio is implemented.
• nRF54H20. Each PWM instance there can only use a few fixed pins, which must be named in the devicetree at build time. EasyDMA can also only reach a dedicated memory region. So it needs a different design: a NeoPixel pin chosen at build time, and a pattern buffer in that region.
• Two nRF54L datasheet pin rules that iobroker does not check yet:
  • All of a peripheral's pins must be on the same port. P1 and P3 share a domain on the nRF54LM20A, but cannot be mixed.
  • Nordic highly recommends that clock signals (SPI SCK, I2C SCL) should use the designated clock pins, due to timing and radio sensitivity, but it is not enforced in hardware.
• perfetto native_bsim tests for neopixel