With the arrival od the festive season comes a cool application on PSoC by Mark!
Below is the post from the PSoC Insiders Blog.
If you have used microcontrollers as long as I have, you have most likely bit-banged a serial protocol a couple of times. For those of you new to microcontrollers, bit-banging is when you write 1s and 0s to a GPIO port to simulate hardware you controller doesn't have. It is almost always a pain, it takes excessive CPU cycles and is even worse if you are on the receiving end, like an I2C slave. If anyone ever asks you to bit-bang an I2C slave, just say NO! Just trust me on this one!
Anyway, it is impossible for your microcontroller to always have every serial interface that may come along. For example, I read about a string of 50 Christmas lights that had red, green, and blue LEDs in each bulb and here comes the best part, each bulb is addressable. Yes, you can control each individual bulb for color and intensity, four bits for each color (red, green, and blue) and 8 bits for intensity. Of course the string of lights came with its own controller that could generate 12 different patterns, but I wanted to create my own patterns. With a little Google searching I found that someone had already hacked the asynchronous protocol and bit-banged an IO port to control the lights with some microcontroller. Nobody had actually created hardware to make this easier or less CPU intensive, you know why? Because nobody else used a PSoC3 or PSoC5 with their powerful UDBs! Yes a PSoC3/5 can bit bang with the best of them, but why bother when you have extremely flexible hardware, plus bit banging is so 90's.
The protocol was a 26-bit packet with one start and three stop bits. Each data bit was divided into three 10uS periods. The first period is always low, the second period was low if the data was a 1 and high if the data bit was a 0 . The last period is always high. See images below for bit and packet formats.
The packet format is pretty straight forward with the address, brightness level and three colors packed into 26 bits. See figure below.
I had a choice, be lazy and use a 32-bit wide shifter or use a single 8-bit wide shifter with a slightly more complicated state machine. The 32-bit wide implementation would be easier but would be a bit wasteful in hardware. The 8-bit wide implementation would take a bit longer, but much more efficient. I choose to go with the 8-bit wide design. One other nice feature in the UDBs, is that you can create two 4 byte FIFOs for data flowing into or out of an interface. This turned out to be perfect since it took 4 bytes to transfer the full 26-bit packet.
The string of lights is 50 bulbs long and if you want to update all the bulbs at one time, it would take 200 bytes (50 bulbs * 4 bytes per packet). Since you don t want the processor to just sit and wait for an interface to move data, DMA is the perfect solution. This way I was able to update the entire string using DMA with almost no CPU overhead! Where the other guys are wasting their CPU cycles toggling bits, the CPU in the PSoC could concentrate on generating cool interactive patterns, converting DMX commands to the light string format, or any other task. What is even better, I could implement 8 of these interfaces in a single PSoC3 or PSoC5 at the same time.
Making this interface into a PSoC Creator component, provides a way to setup all the hardware and DMA with a single start command as with all Creator components. More APIs are added to generate cool lighting patters.
Just think of the possibilities interfacing a string of lights to anything that can be measured with a PSoC!
Here are a few other images of the actual box the string came in, the string that I modified, my interface board, and a close up view of one of the bulbs.
Stay tuned for an upcoming video with the details of what it took to make the lighting component and how easy it is to interface the string with the Cypress PSoC3 First Touch Kit.