When even the co-author of the FastLED library, Mark Kriegsmann, says it’s can’t be done, you know it’s not going to be easy. “The CPU would need to be at least 20X faster to support them[WS2811 based LED’s], and it isn’t.  For that you want an Arduino or Teensy[…]”, as he puts it.

The WS2812B protocol is very simple. Basically it’s a binary PWM signal. Said another way: A long high pulse followed by a short low period for a 1 and a short high pulse followed by a long low period for a 0, and just a long period of nothing to latch the data and turn on the LED.

That looks easy right? Just toggle a pin at the right interval and it works, right? Well – it is, if you’ve got a fast enough processor. Looking at the numbers though, there isn’t enough time to do much toggling when running at 1 or 2Mhz – let alone varying the periods.

At the very “slowest” the high+low period must be 1.825 microseconds, or just about 500khz minimum. Maybe it’s possible to toggle a 6502 pin at 500khz, but it certainly isn’t possible to squeeze NOP’s in there to vary the period or do any kind of processing to change colors. So maybe Mark is right and you actually do need a faster processor?

Luckily it turns out, this isn’t the case. The 6502 is perfectly capable of controlling a string of WS2812B’s, a.k.a. Neopixels. Just like everything else you might want to interface the 6502 to though — the RGB LED’s need a little bit of help.

In this case all we need is a 6522 VIA, which is part of most 6502 computers anyway, a 74hc14 inverter, and a 74hc165 parallel-in serial-out shift register, along with an 8 Mhz clock and some passives.

To be fair, this does mean running the 6502 at 2Mhz(Note: Not 8 Mhz), which would be slightly problematic for the Apple II, but perfectly doable for many or most other 6502 based computers.

As luck would have it, my own 6502 single board computer has an 8 Mhz clock output available and is already running happily at 2 Mhz, which takes the hard work out interfacing with the LED’s – only two extra IC’s needed.

The schematic

The circuit takes a shift clock and serial data from the 6522 shift register. CB1 is the clock and CB2 is the shifted data. CB1 is normally high until it starts clocking out data, which keeps the ~CE(chip enable, active low) pin high through R2. When CB1 goes low the first time, C2 immediately discharges through D1 (I used a 4148) and ~CE is activated. This arrangement keeps the shift register active while data is shifted.

At the same time the signal from CB1 is also fed through the U1A inverter, a simple RC filter, and another inverter, giving the ~PL(load register pin) the short negative pulse needed to latch the data being clocked out from the 6522 shift register. If the pulse is too long, we miss the first bit.

Now we get to where the magic happens – the serial binary data is converted to WS2812-style PWM data. Since D7 is always high and D0-D4 is always low, this varies the high period of the signal by putting the data on pins D5 and D6.

The latched data is then clocked out to Q7 at the rate of 8 Mhz, fed to the CP pin and this is then fed directly to the WS2812B data pin. This means the 6522 supplies data at a comfortable rate of 1 Mhz and the 74HC165 shifts out the converted data at 8 Mhz, which means the bit rate is right around 1bit per microsecond. As you can see this is well within the 1.25us+-600ns in the datasheet.

We’re actually closer to going too fast than too slow, but halving the clocks to 500KHz and 4 Mhz would make it 2 microseconds pr bit – out of spec that says max 1.825 microseconds.
Maybe – just maybe – this could actually work on an Apple II since it has a slightly higher clock than 1Mhz @ 1.023Mhz, but you would then need to make a 4x frequency multiplier for the shift register CP to match input and output.

But wait… 3/8 is only 375ns, right? That would be a 0 signal, right? And 1/8 is only 125ns? Well – in my case I seem to have either stray capacitance on Q7 or something else messing with the timing – somehow using more than two pins for the data gives me a T1H period way longer than what we’re aiming for here – essentially making every bit a 1. Maybe a pulldown resistor on Q7 would make things more consistent – either way I chose to leave things the way they are simply because they work.

The code

The code below is a simplified modification to the current state of my 6502 firmware – my favorite compiler for the 6502 is cc65. Since I’m not sure I’ll merge the change, I’m leaving it here for now – untested, but contains everything needed to get it working. Assume a CC BY-NC license for now.

Sending a color to an LED on the string is as simple as just sending them in the right order with a delay that’s long enough to make sure the 6522 shift register finished shifting before sending another byte – the WS2812B expects colors in GRB order. 24 bits in total per LED.

When we’re done putting colors on the LED string, all that’s left to do is just to wait 50 microseconds, so the string latches the data (updates).

Essentially this means we have 100 clock cycles (at 2 Mhz) available to manipulate LED data even while we’re sending pixels. As long as we’re sending the next 24 bit LED data before the 50 microseconds have passed, we can keep using time between LED’s for as many LED’s as we need.

100 clock cycles is more than enough to rainbow the LED’s and most other simple processing.

;Variables used besides 6522 registers, ACR & SR affected here
; WS2812B variables
GREEN = $20
RED = $21
BLUE = $22
PIXELS = $27

main:
          LDA #%01011000
          STA ACR             ; 6522 ACR register T1 continuous, PB7 disabled, Shift Out Ø2
          lda #40 ; This is how many pixels I'm using.
          sta PIXELS
          jsr sendpixels ; This should clear LEDs on reset if RAM has been 0'd out - random color otherwise. 

    sendpixels:
      ldx PIXELS
    sending:
      sei ; Getting interrupted breaks the timing
      jsr sendpixel
      cli
      dex
      bne sending
      jmp halt ; Done

    sendpixel:
      lda GREEN
      sta SR1
      jsr eznop
      lda RED
      sta SR1
      jsr eznop
      lda BLUE
      sta SR1
      jsr eznop
       rts

      eznop:
         rts

      halt:
      jmp halt ; Loop forever here

Conclusion

As you can see, the 6502 is perfectly capable of rainbowing a string of individually addressable RGB LED’s – it even has time to spare. Previously I’ve managed to run one of these LED strips at 4 Mhz(out of spec though), but I’m happy to report it’s possible to go even lower with this approach.
In a pinch you could use the same trick with an Arduino at lower clock speeds – all you would need is a second ‘165 shift register to have the Arduino output a whole port at the same time ( PORTA = RED; NOP x 7 etc.)

What do you think? Cool experiment or waste of time? I’d appreciate a comment here or on Youtube.

Hint: Gallery the bottom of this post!

So.. What can it do? Blink lights? Well yes.. and so much more.

Even though it has it’s limitations, there’s actually a lot you can do just by bitbanging with an 8Mhz microcontroller. As you can see in the screenshot from the IDE below, it’s actually meant to work with a bunch of peripherals – even though there is no hardware support for any of it.

Of course there’s a couple of very smart people over on the EEVBlog forum working hard at making an open toolchain for these chips, but I decided I couldn’t wait to get started and stuck with the manufacturer IDE, ICE and programmer.

To get the most out of the tools at hand, the IDE seems to expect you to use a mix of plain C, macros and assembly instructions, all mushed together in some pretty interestingly looking code. I’m probably not going to be popular for saying this but it actually feels very intuitive when you get used to it. It’s weird, but it’s “fun”.

After my initial mandatory “blinky tests” I decided to try something slightly more useful – controlling a WS2812B LED. Since the protocol itself relies on bitbanging with pretty tight timings, I figured this was a good test.

Before we move on, here’s the spoiler! Success:

But how? Adafruit’s Arduino-library uses 3 bytes of RAM for every LED so how do you run 300 with just 64 bytes of RAM?

Turns out there’s a simple solution to this problem: Don’t put every LED in RAM.
Since the timings of the WS2812B’s aren’t that tight, there’s actually room for a lot of spare cycles between sending the 24bit value for each LED. Basically just do the logic on the fly, instead of storing each LED in RAM. The only downside is you can’t just change a single LED value and leave the rest.

The logic for controlling the LED’s is pretty simple once you wrap your head around it. Send 24 bits for each LED and end with a delay long enough to make the data latch. In this case, keep each bit around 1.25uS, a “0” is a short high, followed by a “long” low and a “1” is a long high followed by a short low. So simply: High->Low 24 times. Long high for 1, short high for 0.
Here’s a snippet from the datasheet:

The +/- 150ns was plenty of headroom in my case, with the PMS150C running at 8mhz. Same is the case with the +/- 600ns for each bit. I expect I could’ve easily run 3000 LED’s instead of 300 – but I didn’t have the power supply for that much heat lying around

Tim “cpldcpu” wrote a detailed post about it back in 2014 but either things changed since or he got the details wrong, because in my tests a RES signal needed to be at least 50uS and when experiencing glitches, the longer the reset signal, the better.
I have a feeling I would’ve never done this project if I hadn’t seen Big Josh’s post about how simple the protocol actually is but sadly his code needed some serious manipulation to port to the Padauk IDE, so I ended up rewriting it completely from scratch with the WorldSemi datasheet in hand and a vague memory of what BigJosh did with it.
A big thank you for the inspiration to both Tim and BigJosh!

So.. What about the code?

Below is the minimum code I use to talk to the string of LED’s. There’s room for optimisation and I’m sure a bunch of it looks funny, if you’re used to seeing a plain C project on an AVR. First of all, the Padauk IDE is a little bit fuzzy when it comes to data types. There’s no such thing as a “long” and it seems to me all types are unsigned by default – though I haven’t researched this thoroughly.
The only data types available in the Padauk IDE are:

• Bit (1 bit)
• Byte (8 bit)
• Int (8 bit(!))
• Word (16 bit)
• EWORD (24 bit)
• DWORD (32 bit)

The handy thing about the types though, is that the individual bits and bytes can be accessed by macros, without any fuzzing about with shifting them around.

For instance:
mybyte.4 = 0; //Clears bit 4 of mybyte
myEWORD$1 = mybyte; //Sets the middle byte of the 24 bit EWORD

Also, the builtin macros come very handy. See the below code. All the code needed to control the WS2812B’s are contained in the macros “send1”, “send0” and the function SendRGB();

The SendRGB() function is a prime example of Padauk IDE weirdness, containing both assembly instructions, macros and plain old C. But what can I say: It works. I probably could’ve shifted the rgb EWORD x in a while loop(more efficiently than the 24 macro if’s) but I decided to try out the macro and it was more than efficient enough for this purpose. The rest of the code(which I haven’t included here) is basic manipulation of the r,g & b values followed by a show(); to set the right colors. Leave a comment if you want to see, and I’ll throw the complete project on github.

After popular demand, the complete source is available here:
https://github.com/AndersBNielsen/pms150c-projects

byte red, green, blue; //Could save these three RAM bytes by using the rgb EWORD directly ( rgb$0, rgb$1, rgb$2)

EWORD rgb;

word pixels; //Only has to be a word if number of pixels > 255
define definedPIXELS 300;

send1 MACRO
SET1 LED;
.DELAY 5; //Around 0.85uS
$ LED low; //Same as SET0 LED;
// .DELAY 1; //Going around is enough delay 1.25uS in total
ENDM

send0 MACRO
SET1 LED;
.DELAY 2; //Around 0.40uS
$ LED low;
.DELAY 2; //With the loop around 0.85uS
ENDM

void SendRGB (void) {
DISGINT; //Let’s not get interrupted

.FOR bitno, <23,22,21,20,19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0> //Regular for() loop doesn't work, but at least the compiler can do the hard work

if (rgb.bitno == 0) {

send0;

} else {

send1;

}

.ENDM

ENGINT;
}

void show (void) {
rgb$0 = blue; //I lost track of MSB, LSB and endians.. This is what works.
rgb$1 = red;
rgb$2 = green;
SendRGB();
}

void clearLED (void) {
rgb = 0;
pixels = definedPIXELS;
do {
SendRGB();
} while (–pixels);
.delay 2000; //If you want to make sure the LED-reset is caught, use a longer one.
}

So.. Why would I choose this instead of a major brand MCU?

Obviously, the major selling point of this microcontroller is the price. At 3 cents each it’s ten times cheaper than the Pic equivalent(at 3000 MOQ) – the pic10f200(34 cents) or the ATTiny10(28 cents @ 4500 MOQ). //Digikey
Also, the customer service is far from bad – I got an email reply from Padauk within 12 hours.
The downside for the PMS150c is the OTP nature, the limited instruction set, and the sometimes curious and seemingly random IDE documentation – only partially translated into English. (Getting better with every release though from 0.84 to 0.86)
If you’re thinking about making a toy with an ATTiny10 in it and it doesn’t need to do a lot of heavy math – this might be able to do the same job for a tenth of the cost. That doesn’t mean I would be happy to see it in a pacemaker.

What else can it do?

My guess is: More than you’d think. I have a feeling my next project might involve controlling the nrf24L01+ SI24R01 2.4Ghz radio module or maybe a budget Raspberry Pi module.

Either way, please tell me what you think, point out my mistakes and let me know in a comment what you’d like to see me do with this thing in the future.

What I meant to say was: Don’t waste your time. I could’ve had these made for 50 cents each but instead I wasted my time. Lesson learned

This is my business card. It works as a USB-HID device, takes input from a 2.4Ghz transceiver and it also comes with some flashy RGB LED’s and a prototyping header. Oh.. And it has my contact information.

Spoiler: This is also on Github if you just want to skip to code and PCB files. If you want to know more, read on.

Why?

After seeing a couple of PCB business cards on hackaday.com, I knew I had make my own. But how do I make it stand out? What should it do? How expensive can I get away with?

For this little project I decided to squeeze as much as possible out of a cheap ATTiny84. I chose the T84 because it’s dirt cheap (<1$), I’ve been through it’s datasheet more than just a few times, and I wanted to see exactly how much it’s possible to squeeze into the 8192 bytes available.

Turns out the answer is: A lot!

I have a lot of individually addressable RGB WS2812B’s LED’s – aka NeoPixels – spread around my home(and about 850 left on a reel) that I’ve been controlling with prototypes made up of ATMega32u4’s and ATMega328p’s with 2.4Ghz nRF24L01+ tranceivers and a Raspberry Pi with the same tranceiver so I can control it from my phone. To justify spending more than a few cents per business card you need it to actually do something useful. Controlling RGB-LED’s was a start.

Attiny84 √

WS2812B’s √

nRF24L01+ √ (though i suspect pretty much everything out of China is actually SI24r1)

I also added a 20 pin header that makes it easy to use this board for prototyping with the 14pin ATTiny’s. Easy access to every pin(and a few extra power pins) means you can easily solder sensors etc. directly onto the pins – or add male header pins and push it into a breadboard.

How about USB?

One of my annoyances when designing prototypes has always been that it’s really hard to make anything USB-capable(not to speak of compliant) for less than 5$. It is possible though, if you don’t follow the usual path. OBDev’s V-USB (with a little bit of help from Adafruit’s TrinketHidCombo library) made it possible to squeeze some  USB capability into this project without adding much more extra hardware than two zener’s and three resistors.

Software

I have to be honest. I like the Arduino IDE for prototyping. Slapping a couple of libraries together doesn’t usually result in the most efficient code but when you want to put something together that showcases a lot of features fast – as in: a few hours – the vast amount of libraries for interfacing with every popular IC makes it hard no to take the easy route.
Everything didn’t work straight out of the box though. The RF24 library needed pin definitions changed for the ATTiny84(since the USI’s DO/DI are reversed compared to MISO and MOSI and this hasn’t been fixed in the current version) and Adafruit’s TrinketHidCombo library also needed some tweaking to work with the T84. I also went with the Adafruit NeoPixel library  for controlling the WS2812b’s, even though it’s relatively huge for a tiny chip, but somehow I managed to fit the basic functionality into the 8k of flash anyway. It does however, use every single byte available and the debug functions won’t fit unless something else is disabled.

I thought about using the smaller FAB_LED library for driving the LED’s to leave more space for HID-stuff, but it doesn’t really play nice with the 10ms USB-polling when controlling more than one LED at a time so I went the easy way with the NeoPixel library and limited the HID capability to just pressing media keys (start/pause, volume up, volume down and stop). I pride myself in making software that’s good enough for doing the job without too much “gold plating”.

So for now, all it does is work as a 2.4Ghz USB-dongle for media keys along with controlling flashy flashy LED’s. Pretty good for 5$, gold plated board included, though.

PCB Design

So how do you make a PCB business card look cool? The easy way to make it would’ve been some silkscreen text with contact information etc. but to me the typically low resolution silkscreen text wasn’t good enough so I went with making a big ground plane and putting the text and logo on the solder mask layer. The font in KiCAD isn’t my favourite either, so I went with making a footprint of the text from a bitmap instead.
For the surface plating I could’ve gone with the cheaper options but I really believe the immersion gold(ENIG) makes too much of a difference to skip.
I chose 0.8mm board thickness because it’s enough not to break unintentionally and also fits in a standard credit card slot of a wallet – without components that is.

How do you program it?

At first I thought I would just skip the programming interface and use a test probe clip(like this one from Pomona) to program it.

But since I have a feeling I will be using this as a protoboard many times, I decided to find a better solution. Of course I could just hold down jumper wires to the 20-pin header or solder them on – but in my opinion that would either be a hassle for fast prototyping or ruin the look.
Instead I decided to experiment a little bit with programming pads(J2 if you take a look at the schematic), since I already had some pogo pins on the way from China when I ordered this. I didn’t have exact specs for how big the pads needed to be, so I went with a footprint meant for an SMD male header. When I got the pogo pins I soldered them onto female dupont wire terminators and then onto a perfboard. You can see the final result on the right, together with my overused USBasp. This is a solution I can really recommend, but the next time I make an interface like this I will most likely just use tiny pads 2.54mm(.1″ standard header) apart and as small as possible. With the thickness of the solder mask, the pins slide right into place. The only downside is you need to apply a tiny bit of pressure while programming the device, but I prefer this to connecting jumper wires any day.

If you want to read more about this subject, take a look at my post about programming an AVR without taking up board space.

Want to make your own PCB Business card?

The point of a business card is to share it with other people, so I’ve uploaded this whole project to Github. Feel free to fork it and put your own spin on it.

Leave a comment if you have any questions, suggestions etc. Any feedback – good or bad – is very welcome