Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PIC16F1454-based BiblioPixel protocol controller
#1
For giggles, over a couple of evenings I wrote open-source firmware for a PIC16F1454 ($1 USB microcontroller) that follows the BiblioPixel serial protocol.

This cheap chip does the USB serial port and the LED controlling. Think of it as a cheaper, lighter AllPixel.

I call it the "somepixel": https://github.com/majbthrd/somepixel Big Grin

It controls up to around 200 (it was around 220 when I last tried absolutely max-ing out the RAM usage) WS2812s.

Earlier in the week, I also wrote "blink0" (also on github), which is firmware that emulates a Blink(1). In that case, it max-ed out at 47 LEDs because the Blink(1) protocol forces the microcontroller to do all the fading, and that chews up a lot of RAM. Still, I came up with a more efficient way of doing fade than the Blink(1)'s algorithm, and I think my blink0 firmware is a LOT easier to read than the Blink(1) source code.

I'm loading the re-programmable firmware into the PIC16F1454 over the USB port using my bootloader:

https://code.google.com/p/pic16f1454-bootloader/

Personally, if I were targeting the capabilities of the AllPixel, I would use something like the STM32F042. It is targeting a similar market to the PIC16F1454. It costs a bit more than the PIC in quantity; in small quantity, it is more 'pricey' (a whopping $3... ha!), but certainly less than the $5-$7 ATMEGA32U4 on the AllPixel. The STM32F042 is a proper ARM with 6kBytes of RAM. It would seriously outclass the AVR and do more for a lot less money.

I'd then use some of the money saved to put some electrical isolation between the microcontroller and the LED connector. Perhaps a Si8420 or similar would do the trick. It would be desirable to keep the PC USB power supply isolated from whatever is used to drive the LEDs; as a bonus, it would allow more flexibility in I/O voltages.
#2
VERY nice work! Thanks so much for sharing! Smile I like the name.

What kind of data throughput are you getting over USB on that chip? One of the biggest hurdles with the 32u4 was the USB stack. I used a modified version of what the teensy uses because the Arduino USB stack is insanely slow (~60KBps max). But the teensy stack will hit a full 12Mbps througput Smile

I'll certainly check into the STM32F042 for any future products (or AllPixel versions). Part of the reason we went with AVR is that the core of the AllPixel firmware is the FastLED library, which provides our ability to handle so many LED protocols. At the time of early development they didn't support anything other than AVR. But looks like their dev branch will do STM32 now Smile And I imagine with the right USB stack we could get the required speed. So, thanks for the suggestion!
#3
(05-08-2015, 09:30 PM)Adam Wrote: What kind of data throughput are you getting over USB on that chip?

Sorry about the delay.  I must have forgotten to enable an notification email.

Using the PIC16F1454 design, I just tried:

dd if=megabyte.bin of=/dev/ttyACM0

and got 165kB/s (1.3Mbits/s).

At the moment, I'm not using double-buffered USB transfers so as to maximize RAM, so performance could be better.

Are you assessing this "12Mbps/s" via a similar test procedure?

I wound up using the PIC16F1454 (cheaper, and much easier for me to solder) and used the described electrical isolation.   I just built the OSH Park PCBs yesterday evening (image attached).  The schematic is on the Github page.

Since when I posted, I have a much improved USB bootloader for the PIC16F1454 that only takes 512 words:

https://github.com/majbthrd/PIC16F1-USB-DFU-Bootloader

I wasn't using nearly all the flash memory in my original post, but I'm sure I'll find something to do with it. Smile

Your question about USB throughput for a CDC class device piqued my interest. I just did an experimental build of the same code with ping-pong buffers enabled.

The test procedure was to write a megabyte (1024*1024) file to the virtual serial port using dd:

dd if=megabyte.bin of=/dev/ttyACM0

That tests not only the USB stack, but the code that is parsing the BiblioPixel protocol.

I got 165kB/s (1.3Mbits/s) without double-buffering, and 179kB/s (1.4Mbits/s) with.


Attached Files Thumbnail(s)
   
#4
Very nice! That's some seriously awesome work!
So, right now it's specific to the WS281X series of chips, right?
You mind if we post details for this on the Maniacal Labs website? I'm sure our followers would love to see this Smile
#5
(05-30-2015, 06:12 PM)Adam Wrote: Very nice! That's some seriously awesome work!
So, right now it's specific to the WS281X series of chips, right?
You mind if we post details for this on the Maniacal Labs website? I'm sure our followers would love to see this Smile

Thanks.  I bought a couple of WS281X variants off eBay, and it seems like a super-simple protocol, so yes, that is what I implemented.

Sure, I don't mind.

Attached are photos of BiblioPixel driving somepixel driving an LED string and of the blink0 PCB (which could just as easily load the somepixel firmware via the bootloader).


Attached Files Thumbnail(s)
       


Forum Jump:


Users browsing this thread: 1 Guest(s)