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:
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 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:
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: