UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Adam Taylor’s MicroZed Chronicles Part 32: Driving Adafruit RGB NeoPixel LED arrays

by Xilinx Employee ‎05-12-2014 10:28 AM - edited ‎05-14-2014 02:01 PM (29,440 Views)

In my last blog I introduced the addictive Adafruit NeoPixel RGB LEDs and outlined the cardinal points of the NeoPixel drivers. (See “Adam Taylor’s MicroZed Chronicles Part 31: Systems of Modules, Driving RGB NeoPixel LED arrays.”) In this blog I am going to address the hardware aspects of the design solution and will then look at the overall architecture in my next blog. The design uses both the PS (processor system) and PL (programmable logic) in the Zynq SoC.

 

For this example, I have chosen to drive a 1-meter strip of NeoPixels with a LED density of 30 NeoPixels per meter. Reading the data sheet shows that the Neo Pixel array is designed to work with a 5V supply. However, reading the datasheet more carefully reveals that the highest voltage required is for powering the Blue LED, which needs a voltage between 3.2 and 3.4 volts. That’s right in the range of the 3.3V supply voltage available on the MicroZed I/O Carrier Card, which is what we’ll use.

 

The MicroZed I/O Carrier card has two on-board voltage regulators that you can use to supply I/O banks 34 and 35 on the Zynq SoC (and bank 13 if you are using the Zynq Z7020). The output voltages of these regulators are selectable between 1.8V, 2.5V, and 3.3V. Of the two regulators, the one associated with bank 35 has a higher current rating (2.8A) compared to the 2.3A rating for the regulator associated with bank 34.  As we will be driving a large number of LEDs, I will be using the regulator for bank 35 to power the 1m NeoPixel array.

 

Each of the individual LEDs in a NeoPixel requires a maximum current of 20mA. There are three LED’s in each NeoPixel, hence each RGB pixel requires 60mA. With 30 NeoPixels per meter, we need a maximum current of 1.8A from the 3.3V supply. That is well within the rated current capacity of both of the I/O Carrier Card’s power supplies but we achieve maximum regulator de-rating by using the higher-rated regulator of the pair.

 

This means that the Pmod wire-terminal adapter plug attached to the NeoPixel array will be plugged into one of the I/O Carrier Card’s JE, JF, JG, or JH PMOD connectors because these four Pmod connectors are connected to the bank 35 regulator. The figure below shows the pinout for a Pmod interface:

 

 

Figure 1.gif 

 

Pmod Connector Pinout

 

 

The Digilent PmodCON1 wire-terminal adapter I am using breaks out only the power, ground, and four I/O signals. These pins are sufficient for driving the NeoPixel array, which only requires, power, return and Din.

 

The Din pin is how we program a pixel’s color. Each NeoPixel requires a 24-bit control word consisting of eight 8-bit green, red, and blue values in the order shown below:

 

 

 Figure 2.gif

 

 

NeoPixels have no clock line. They use a unique self-clocking, non-return-to-zero (NRZ) waveform to specify the bit values, as shown below:

 

 

NeoPixel timing Waveforms.gif

 NeoPixel bit timing

 

 

The waveform’s bit period and duty cycle both change depending on whether the bit value represented is a 1 or 0. The timings are: T0H = 0.35μsec, T0L = 0.8μsec, T1H = 0.7μsec, and T1L = 0.6μsec. All timing values have a tolerance of ± 150nsec. These times give slightly different durations for a Low bit (1.15μsec) compared to a High bit (1.3μsec). We will analyze this serial communications scheme in much more detail when we write the software driver in a future blog.

 

If a NeoPixel does not start receiving another word within 50μsec after receiving all 24 data bits in a data word, it loads the received 24-bit word into an internal register and lights its three LEDs using that 24-bit value. However, if the NeoPixel does receive another 24-bit word within the 50μsec timeout period, it retransmits the previously received word on its Dout port instead of using it internally. This mechanism allows you to use one serial signal line to control a large number of pixels in a very simple manner.

 

In the next blog, I will introduce the architecture within the Zynq PS and PL needed to drive the NeoPixels through the MicroZed I/O carrier card. Meanwhile, to whet your appetite, here are examples of the waveform output from the finished solution when it is outputting a High (1) and Low (0) bit.

 

 

 Figure 3.gif

 

Neo Pixel High bit output

 

 

 

 

 Figure 4.gif

 

 

Neo Pixel Low bit output

 

 

 

Please see the previous entries in this MicroZed series by Adam Taylor:

 

Adam Taylor’s MicroZed Chronicles Part 31: Systems of Modules, Driving RGB NeoPixel LED arrays

 

 Adam Taylor’s MicroZed Chronicles Part 30: The MicroZed I/O Carrier Card

 

Zynq DMA Part Two – Adam Taylor’s MicroZed Chronicles Part 29

 

The Zynq PS/PL, Part Eight: Zynq DMA – Adam Taylor’s MicroZed Chronicles Part 28  

 

The Zynq PS/PL, Part Seven: Adam Taylor’s MicroZed Chronicles Part 27

 

The Zynq PS/PL, Part Six: Adam Taylor’s MicroZed Chronicles Part 26

 

The Zynq PS/PL, Part Five: Adam Taylor’s MicroZed Chronicles Part 25

 

The Zynq PS/PL, Part Four: Adam Taylor’s MicroZed Chronicles Part 24

 

The Zynq PS/PL, Part Three: Adam Taylor’s MicroZed Chronicles Part 23

 

The Zynq PS/PL, Part Two: Adam Taylor’s MicroZed Chronicles Part 22

 

The Zynq PS/PL, Part One: Adam Taylor’s MicroZed Chronicles Part 21

 

Introduction to the Zynq Triple Timer Counter Part Four: Adam Taylor’s MicroZed Chronicles Part 20

 

Introduction to the Zynq Triple Timer Counter Part Three: Adam Taylor’s MicroZed Chronicles Part 19

 

Introduction to the Zynq Triple Timer Counter Part Two: Adam Taylor’s MicroZed Chronicles Part 18

 

Introduction to the Zynq Triple Timer Counter Part One: Adam Taylor’s MicroZed Chronicles Part 17

 

The Zynq SoC’s Private Watchdog: Adam Taylor’s MicroZed Chronicles Part 16

 

Implementing the Zynq SoC’s Private Timer: Adam Taylor’s MicroZed Chronicles Part 15

 

MicroZed Timers, Clocks and Watchdogs: Adam Taylor’s MicroZed Chronicles Part 14

 

More About MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 13

 

MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 12

 

Using the MicroZed Button for Input: Adam Taylor’s MicroZed Chronicles Part 11

 

Driving the Zynq SoC's GPIO: Adam Taylor’s MicroZed Chronicles Part 10

 

Meet the Zynq MIO: Adam Taylor’s MicroZed Chronicles Part 9

 

MicroZed XADC Software: Adam Taylor’s MicroZed Chronicles Part 8

 

Getting the XADC Running on the MicroZed: Adam Taylor’s MicroZed Chronicles Part 7

 

A Boot Loader for MicroZed. Adam Taylor’s MicroZed Chronicles, Part 6 

 

Figuring out the MicroZed Boot Loader – Adam Taylor’s MicroZed Chronicles, Part 5

 

Running your programs on the MicroZed – Adam Taylor’s MicroZed Chronicles, Part 4

 

Zynq and MicroZed say “Hello World”-- Adam Taylor’s MicroZed Chronicles, Part 3

 

Adam Taylor’s MicroZed Chronicles: Setting the SW Scene

 

Bringing up the Avnet MicroZed with Vivado

Adam Taylor’s MicroZed Chronicles Part 31: Systems of Modules, Driving RGB NeoPixel LED arrays

 

 

 

 

 

Comments
by Visitor xil3s92f
on ‎05-12-2014 11:01 AM

Excited!

Labels
About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.