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 36: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 7

by Xilinx Employee ‎06-09-2014 02:01 PM - edited ‎06-09-2014 02:05 PM (33,672 Views)

By Adam Taylor

 

The example I have been explaining over my last few blogs requires communication over RS-232 (in reality a USB-to-serial device) to control the settings of each RGB LED pixel in the Adafruit NeoPixel array. I therefore needed to implement a basic communications protocol between the PC (DTE) and the MicroZed (DCE).

 

I will be using the UART within the PS of the Zynq to send and receive data. This is declared within the BSP to be the STDIO as shown below:

 

 

 Figure 1.png

 

 

 

This declaration allows me to use the getchar() function to implement my NeoPixel communications protocol.

 

Now because I do not want to re-invent the wheel—why would any engineer?—my simple protocol uses 8-bit ASCII characters to exchange data. (An ASCII table is here.) Using this protocol, each pixel can be can be addressed by sending the following data format:

 

<STX> <Pixel Number> <Green><Red><Blue><ETX>

 

To update a number of pixels using this protocol, each pixel to be updated requires a packet formatted as above. These packets are transmitted sequentially at a speed of 115200 bps, no parity.

 

This protocol allows the length of the NeoPixel string to be determined by the size of the internal memory used to store the pixel values in the FPGA. The string can be very large because the FPGA memory can store 4096 pixels, which can easily be increased in a few minutes for adventurous designers.

 

Within the software, all I had to do was to implement a simple state machine that loops through the states, receiving the pixel values and then storing the received data into the correct Block RAM memory location.

 

Having received all of the bytes over the serial link, the received red, green and blue bytes are formatted into a 24-bit word and written to the correct address within the FPGA’s Block RAM to enable the PL side of the Zynq SoC to set the color if the pixels are enabled.

 

All told, this is a very simple communication protocol. However, as it is transmitting data there will at times be issues with the communication channel (noise or glitches for example) that may have undesirable effects on the performance, which is why the protocol must be able to handle errors.

 

The state machine needed to implement this protocol uses the only seven states and can be seen in the attached file below. This code is not quite the final version as it still has code within it to echo back over the serial link what was received so I can verify the interface using a simple terminal program. That’s all part of my verification strategy, as discussed in my previous blog post (“Adam Taylor’s MicroZed Chronicles Part 35: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 6”.)

 

The RS-232 terminal program I use is called termite, which has a hex-view plug in to allow me to directly transmit hex codes. This approach allows me to transmit hex codes much easier from my laptop computer, to test that the protocol is working as expected and to corrupt the data for checking error handling and protocol resiliency. Here’s a screen shot of the termite terminal application:

 

 

 Figure 2.png

 

 

Having looked at verification in the last blog and the serial interface in this blog, I will explain the development and of the GUI and final system tests in my next blog. Then I’ll start to cover more exciting aspects of learning to use the Zynq.

 

Is this example useful to you?

 

 

 

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

 

Adam Taylor’s MicroZed Chronicles Part 35: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 6

 

Adam Taylor’s MicroZed Chronicles Part 34: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 5

 

Adam Taylor’s MicroZed Chronicles Part 33: Driving Adafruit RGB NeoPixel LED arrays with the Zynq SoC

 

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

 

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

 

 

Comments
by Voyager
on ‎12-11-2014 02:55 AM

Hello Adam,

 

thanks for the great tutorial. I tried to paste your VHDL source in Vivado (2014.4), when I 'elaborate' the design vivado gives me this error :

 

loop limit (65536) exceeded [neo_pixel.vhd:232]

 

that refers to this piece of code :

 

clk_gen : PROCESS
BEGIN
LOOP
clk <= NOT(CLK);
WAIT FOR(clk_period/2);
clk <= NOT(CLK);
WAIT FOR(clk_period/2);
END LOOP;
END PROCESS;

 

looks like the compiler does not like an endless loop ?

 

 

by Observer taylo_ap
on ‎12-11-2014 03:49 PM

Hi Ronny

 

Th code snippet you refer to is part of the test bench, it generates the clock for the UUT have you set it as simulation correctly in Vivado?

 

Adam 

by Voyager
on ‎12-12-2014 12:12 AM

Hello Adam,

 

you're right - I copy/pasted the entire word file content into the source file and hit the synthesize button ... I removed the testbench part, error gone ... thanks !

 

 

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.