TinyBling - CH32V003 NeoPixel Pendant

TinyBling is a decorative wearable device designed to provide a sparkly, eye-catching effect through a ring of 16 addressable LEDs. While seemingly simple, the project serves as a practical demonstration of the CH32V003 microcontroller’s capabilities, particularly in handling strict timing requirements with limited hardware resources.

Hardware Architecture

The pendant is built around the CH32V003 series, an industrial-grade 32-bit RISC-V microcontroller. This MCU utilizes the QingKe RISC-V2A core, supporting the RV32EC instruction set with a 48MHz system frequency. Despite its small footprint, it includes 16KB of flash and 2KB of SRAM, making it an efficient choice for low-power consumer electronics.

For the display, the project uses WS2812C-2020 addressable LEDs. These are specialized “NeoPixels” that integrate the control IC and LED chip into a tiny 2020 package. They operate on a single-line return-to-zero protocol, where each pixel consumes 24 bits of data before forwarding the rest to the next LED in the chain. This specific model is chosen for its low current consumption (5mA), which is critical for battery-powered operation.

Power is provided by a rechargeable LIR2032 coin cell battery. It is important to note that standard CR2032 batteries are insufficient for this project as they cannot provide the peak current necessary to power 16 LEDs simultaneously.

Software Implementation and NeoPixel Control

The primary technical challenge of using the 8-pin variant of the CH32V003 is the lack of available hardware SPI pins. Standard NeoPixel libraries often rely on SPI or DMA to meet the strict 800kHz timing requirements. To overcome this, the firmware implements a custom software bit-banging protocol.

While the WS2812 datasheet suggests very tight tolerances, practical implementation reveals more flexibility. The critical requirement is ensuring that a “0” bit high-time (T0H) does not exceed 500ns, and a “1” bit high-time (T1H) stays above 625ns. The project uses an optimized inline assembly function to handle this transmission, ensuring the CPU frequency (8MHz in this configuration) is sufficient to toggle the GPIO pins within these windows. To prevent timing jitter, interrupts are disabled during the data transmission cycle.

// Send one data byte to the pixels string (works at 8MHz CPU frequency)
void NEO_sendByte(uint8_t data) {
  asm volatile(
    " c.li a5, 8                \n"   // 8 bits to shift out
    " li a4, %[pin]             \n"   // neopixel pin bitmap
    " li a3, %[base]            \n"   // GPIO base address
    "1:                         \n"   // ... bit-banging logic ...
    // (Refer to source for full assembly implementation)
  );
}

Firmware Variations

The repository provides three distinct firmware versions to demonstrate different use cases for the pendant:

• neo_demo: Automatically cycles through various decorative light animations. If the user holds the button during power-up, they can manually switch animations with each press.
• neo_hunt: A simple one-button reaction game. A green “hunter” LED chases a red “deer” LED. The player must time their button press perfectly to catch the deer, with the speed increasing after each success.
• neo_wof: A digital “Wheel of Fortune” implementation where the LEDs spin and land on a random result after a button press.

Assembly and Deployment

Building the TinyBling involves manufacturing the PCB using the provided Gerber files and soldering the surface-mount components. Because of the high density of the 2020 LEDs, careful soldering is required.

Programming the CH32V003 is performed via the WCH-LinkE debugger using the single-wire serial debug interface (SDI). The project supports multiple build environments, including a standard Makefile-based GCC toolchain and PlatformIO. For developers on Linux, access permissions for the WCH-LinkE must be configured via udev rules to allow the rvprog utility to communicate with the hardware. The firmware also utilizes the MCU’s standby mode to conserve energy, which may occasionally require a “power cycle erase” or “unbrick” procedure during development if the debug interface becomes unresponsive.