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(ish) Chronicles Part 83: Simple Communication Interfaces Part 3

by Xilinx Employee on ‎05-26-2015 10:07 AM (54,367 Views)

 

By Adam Taylor

 

In the last blog we had looked how we can use the SPI via both the Zynq SoC’s PS (Processor System) MIO and the PL (Programmable Logic) EMIO. To get the OLED powered up in this blog, we will use both the SPI and GPIO via the EMIO.

 

To control the OLED we need to use a number of GPIO identified in the table below and mentioned briefly in part 81:

 

 

Signal

FPGA IO

PS GPIO ID

Comment

Direction

Reset

U9

54

Active Low Reset

Output

VDD

U12

55

Active Low Digital Power Enable

Output

VBatt

U11

56

Active Low Dc/Dc Power Enable

Output

D/C

U10

57

Data / Command. Command = 0

Output

 

 

We can use these GPIO in the EMIO in exactly the same manner as we would if they were within the MIO. We need to drive these signals to meet the timings identified in the diagram below:

 

 

Image1.jpg

 

 

OLED Power Up

 

 

 

Image2.jpg 

 

OLED Power Down

 

 

We can do this using the private timer on the Zynq SoC’s CPU. Once these timings have been achieved (t1 =3us, t2 = 3 us toff = 100 ms) using the GPIO signals, we can then initialize and send commands to the OLED over the SPI bus.

 

To use the GPIO in the EMIO we have to follow the steps below:

 

  • Include the header file xgpiops.h
  • Declare the GPIO using the type XGpioPs
  • Declare a GPIO Configuration pointer using the type XGpioPs_Config
  • Look up the configuration of the GPIO using XGpioPs_LookupConfig()
  • Initialize the GPIO using XGpioPs_CfgInitialize()

 

Once we have the GPIO initialized and ready to go for each of the signals, we need to declare its direction and enable it if necessary. All of these signals are outputs so we declare them as outputs and enable the outputs before we define the initial signal states. An example of how to do this is shown below:

 

 

#define vdd 55

XGpioPs_SetDirectionPin(&Gpio, vdd, 1);

XGpioPs_SetOutputEnablePin(&Gpio, vdd, 1);

XGpioPs_WritePin(&Gpio, vdd, 1);

 

 

With the OLED powered up correctly, we can now send commands to the OLED.

 

But what commands do we send?

 

To initialize the OLED, we need to configure its built-in controller, which requires sending a 23-byte configuration string to get the OLED controller into a state where it will display information. In the next blog, we’ll then start sending information for the OLED panel to display but for now, we need to configure the controller by sending the following commands over the SPI link as provided in the OLED panel data sheet:

 

 

  1. Set the display off
  2. Set the Clock, Frequency dividers and multiplexer setting
  3. Set the display offset and start line
  4. Configure the charge pump to drive the OLED panel
  5. Configure the mapping, scan direction and pin hardware configuration
  6. Set the precharge period
  7. Set the display on

 

As I said above, these seven commands take 23 bytes. To make this process very simple, I declared a u8 array containing all of these configuration words, which can then be cycled through as we write out our commands over the SPI bus. By the end of the configuration, we can see that the OLED has come to life although nothing yet is displayed upon it. A snippet of the configuration code used can be seen below.

 

 

u8 init_vector[23] = {0xae, 0xd5, 0x80, 0xa8, 0x1f, 0xd3, 0x00, 0x40, 0x8d, 0x14, 0xa1, 0xc8, 0xda, 0x02, 0x81, 0x8f, 0xd9, 0xf1, 0xdb, 0x40, 0xa4, 0xa6, 0xaf};

for(i =0; i<23; i++){

   wr_buff[0] = (u8) init_vector[i];

   XGpioPs_WritePin(&Gpio, dc, 0); // set DC to command

   XSpiPs_SetSlaveSelect(&SpiInstance_EMIO, 0x01); //select the slave

   XSpiPs_PolledTransfer(&SpiInstance_EMIO, wr_buff, NULL, 1); //write the word

   XGpioPs_WritePin(&Gpio, dc, 1); // set DC to data

}

 

 

 

Next time, we look at how we can get the OLED to display an image

 

 

The OLED data sheet for the device in question can be found here.

 

 

 

 MicroZed Chronicles.jpg

 

 

 

 

 

 

Now, you can have convenient, low-cost Kindle access to the first year of Adam Taylor’s MicroZed Chronicles for a mere $7.50. Click here.

 

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

 

Adam Taylor’s MicroZed(ish) Chronicles Part 82: Simple Communication Interfaces Part 2

 

Adam Taylor’s MicroZed(ish) Chronicles Part 81: Simple Communication Interfaces

 

Adam Taylor’s MicroZed Chronicles Part 80: LWIP Stack Configuration

 

Adam Taylor’s MicroZed Chronicles Chronicles Part 79: Zynq SoC Ethernet Part III

 

Adam Taylor’s MicroZed Chronicles Chronicles Part 78: Zynq SoC Ethernet Part II

 

Adam Taylor’s MicroZed Chronicles Microzed Chronicles Part 77 – Introducing the Zynq SoC’s Ethernet

 

Adam Taylor’s MicroZed Chronicles Part 76: Constraints for Relatively Placed Macros

 

Adam Taylor’s MicroZed Chronicles, Part 75: Placement Constraints – Pblocks

 

Adam Taylor’s MicroZed Chronicles, Part 73: Physical Constraints

 

Adam Taylor’s MicroZed Chronicles, Part 73: Working with other Zynq-Based Boards

 

Adam Taylor’s MicroZed Chronicles, Part 72: Multi-cycle Constraints

 

Adam Taylor’s MicroZed Chronicles, Part 70: Constraints—Clock Relationships and Avoiding Metastability

 

Adam Taylor’s MicroZed Chronicles, Part 70: Constraints—Introduction to timing and defining a clock

 

Adam Taylor’s MicroZed Chronicles Part 69: Zynq SoC Constraints Overview

 

Adam Taylor’s MicroZed Chronicles Part 68: AXI DMA Part 3, the Software

 

Adam Taylor’s MicroZed Chronicles Part 67: AXI DMA II

 

Adam Taylor’s MicroZed Chronicles Part 66: AXI DMA

 

Adam Taylor’s MicroZed Chronicles Part 65: Profiling Zynq Applications II

 

Adam Taylor’s MicroZed Chronicles Part 64: Profiling Zynq Applications

 

Adam Taylor’s MicroZed Chronicles Part 63: Debugging Zynq Applications

 

Adam Taylor’s MicroZed Chronicles Part 62: Answers to a question on the Zynq XADC

 

Adam Taylor’s MicroZed Chronicles Part 61: PicoBlaze Part Six

 

Adam Taylor’s MicroZed Chronicles Part 60: The Zynq and the PicoBlaze Part 5—controlling a CCD

 

Adam Taylor’s MicroZed Chronicles Part 59: The Zynq and the PicoBlaze Part 4

 

Adam Taylor’s MicroZed Chronicles Part 58: The Zynq and the PicoBlaze Part 3

 

Adam Taylor’s MicroZed Chronicles Part 57: The Zynq and the PicoBlaze Part Two

 

Adam Taylor’s MicroZed Chronicles Part 56: The Zynq and the PicoBlaze

 

Adam Taylor’s MicroZed Chronicles Part 55: Linux on the Zynq SoC

 

Adam Taylor’s MicroZed Chronicles Part 54: Peta Linux SDK for the Zynq SoC

 

Adam Taylor’s MicroZed Chronicles Part 53: Linux and SMP

 

Adam Taylor’s MicroZed Chronicles Part 52: One year and 151,000 views later. Big, Big Bonus PDF!

 

Adam Taylor’s MicroZed Chronicles Part 51: Interrupts and AMP

 

Adam Taylor’s MicroZed Chronicles Part 50: AMP and the Zynq SoC’s OCM (On-Chip Memory)

 

Adam Taylor’s MicroZed Chronicles Part 49: Using the Zynq SoC’s On-Chip Memory for AMP Communications

 

Adam Taylor’s MicroZed Chronicles Part 48: Bare-Metal AMP (Asymmetric Multiprocessing)

 

Adam Taylor’s MicroZed Chronicles Part 47: AMP—Asymmetric Multiprocessing on the Zynq SoC

 

Adam Taylor’s MicroZed Chronicles Part 46: Using both of the Zynq SoC’s ARM Cortex-A9 Cores

 

Adam Taylor’s MicroZed Chronicles Part 44: MicroZed Operating Systems—FreeRTOS

 

Adam Taylor’s MicroZed Chronicles Part 43: XADC Alarms and Interrupts 

 

Adam Taylor’s MicroZed Chronicles MicroZed Part 42: MicroZed Operating Systems Part 4

 

Adam Taylor’s MicroZed Chronicles MicroZed Part 41: MicroZed Operating Systems Part 3

 

Adam Taylor’s MicroZed Chronicles MicroZed Part 40: MicroZed Operating Systems Part Two

 

Adam Taylor’s MicroZed Chronicles MicroZed Part 39: MicroZed Operating Systems Part One

 

Adam Taylor’s MicroZed Chronicles MicroZed Part 38 – Answering a question on Interrupts

 

Adam Taylor’s MicroZed Chronicles Part 37: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 8

 

Adam Taylor’s MicroZed Chronicles Part 36: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 7

 

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 Visitor richardrv
on ‎02-05-2017 10:05 PM

Hello Adam. Part #81 mentions that the Zedboard has no display, but the current design now seem to have one. It looks like the constraint file uses the same pins used in this example, and have the prefix "OLED" in the signal names, making it convenient. It looks to me like the blog is about an older board that has been improved since it was written.

 

What I am confused about is that the PS GPIO ID numbers used in this example to address the EMIO pins. These are assiged the values 54 to 58 in your code (Res,Vbat,Vdd,Sig,D/C), as you have shown here in Part #83. I cannot find any documentation showing how these MIO numbers are determined. 

 

In the Zedboad UG, page 24, Table 13 (Pmod Connections) they show the MIO pin numbers for JE1 as MIO13,10,11,12,0,9,14 and 15, respectively. I can't find the MIO values for the JC connector used to drive the OLED. The code example you have shows that we need thise "MIO" pin iD values, even though the port is using the EMIO port space. 

 

I realized all those MIO pins are for 2-rows of the connector, so I'm only going to need half of them. I presume then that I would be using MIO13,10,11,12 instead of the values shown (54 thru 58). Or MIO0, 9, 14 and 5 for the other row.

 

Could you help walk us through a pin assignment from the SPI to an arbitrary set of pins on the Pmod JC1 connector? 

 

Thank you, Richard Vasquez

by Observer taylo_ap
on ‎02-06-2017 01:32 PM

Richard,

 

Thanks for reading the blog, with respect to the OLED in #81 I mentioned there was no OLED on the MicroZed but there is on the Zedboard which is why these few examples are based on the Zedboard not the MicroZed. 

 

With respect to pin numbering it is not so straight forward, as you may think 

 

On the Zedboard JE is connected to the MIO in the PS as such it uses the MIO as you indicate. 

 

The OLED is connected to the PL IO pins as such we need to use EMIO, which uses a combination of SPI EMIO and GPIO EMIO both are different. 

 

When it comes to EMIO GPIO, remember the PS MIO could be all used as GPIO, giving 54 GPIO in total. This is arranged as one bank of 32 and another of 22, these are referred to as bank 0 and bank 1. We can also have up to 64 EMIO these are 2 banks of 32 and are bank 2 and 3 respecitviely. As such they rank in number from 54 to 118. We can route these as normal PL signals to the output pin we require using XDC constratints. Within the SW we just address them like GPIO in banks 2 and 3 and the connected PL pin will toggle. 

 

The same goes for the SPI pins they are broken out through EMIO and the pins are then made external by assinging them to the PL IO pins which connect to JC. In this case the EMIO are not GPIO but SPI and as such we can route them as normal signals in the PL. 

 

I hope this answers your question, the Zynq TRM is pretty good at explaining the EMIO concept for both SPI and GPIO

 

Best 

 

Adam 

by Visitor richardrv
on ‎02-07-2017 09:34 PM

Hello Adam. Thank you for your help. However, what you wrote has both helped and confused me a little. Maybe my attached image will describe this a little better. This is from the Zedboard schematic. As you can see, these are the correct pin numbers per your code. I added in the PS GPIO ID values you use in your code.

 

You refer to Bank 2 starting off here at 54, but here this schematic clearly shows it's "Bank 13". Also, the GPIO numbers you use are out of sequence. Based on this sequencing I'm not sure which one of these is "58" (sig). There is no "order".

 

So I get it hat "54" is the first EMIO pin number available because 0 through 53 are the MIO. But how does that connect to these pins as shown? Please realize, these schematics are ALL the information we have to tie into the datasheet and figure out how your code works.

 

In short, where are these bank boundaries defined? 

 

I did look into the Technical Reference Manual, but these bank boundaries are not shown. Would you please point them out?

 

Thank you, Richard V

 

 

 

 

 

Adam. Zedboard Schematic page 9 closeup.png

by Observer taylo_ap
on ‎02-08-2017 02:29 PM

Richard 

 

It is a little confusing however the PL IO bank 13 has no bearing on the GPIO bank within the PS. This is because when EMIO GPIO is broken out via EMIO through the PL they could be placed on any bank with the PL. Where they are placed is controlled via the XDC constraints file. In effect they become just like any other signal in the PL 

 

The sequencing comes in how you tie the EMIO GPIO to the PL pins, they are not in a logical order most likely as I numbered them as how I numbered them how I needed them in the SW I think, though it is a while since I wrote this.

 

I hope this helps 

 

Adam 

 

 

by Visitor richardrv
on ‎03-07-2017 05:37 PM

Hello Adam, I'm back working on this. Thank you for your previous efforts in trying to explain, but I still don't see the association between the contraint file provided and your example code. I've already pointed this out with the image I have shown. Please let me try to explain again.

 

Please let us concentrate on just one pin: OLED_VDD.

 

The constraint file (for the Zedboard, provided on website) shows the variable name "OLED_VDD" connecting to pin number U12, but that is all. I have no idea how you came up with the value "55" in your code.

 

I do realize that the EMIO starts numbering from 54 beause pins 0 to 53 are used by the PS side. The value 55 means it's the 2nd EMIO pin, and that's all I know about this numbering so far. I realize that an EMIO signal can be placed on any PL pin that is available, using the constraint file to route the pin.

 

Here's the true confusion:

The example C code you have provided does not use the variable name "OLDE_VDD". Instead, the value "55" is assigned to variable "vdd". This doesn't make any sense at all since there is no connection between the contraint file and this code using that variable name.

 

Could you please help clear up my confusion on this one pin as an example?

 

I'm thinking that I just don't understand how to use the constraint file, as is, with your code. Do I need to alter it to make this example work? I didn't see anything about this particular constraint file in your blog.

 

Thank you, Richard V

by Observer taylo_ap
on ‎03-08-2017 11:46 AM

Richard 

 

I hope the diagram below will help you understand what is going off with the  connection between the EMIO, pin the routing in the PL,  constraints file and the processor if not email me and I will talk you through it on Skype. 

 

Adam 

 

Capture.PNG

by Visitor richardrv
on ‎03-08-2017 05:17 PM

Hello Adam. I just wanted to say "thank you". Yes, that image makes things much clearer now. I see that the array GPIO_O are the pins you are using. GPIO_O[0] is 54, the reset line. GPIO_O[1] is 55, and so on. This is the connection I was looking for.

 

Best regards, Richad V

by Visitor richardrv
on ‎03-09-2017 05:27 PM

Hello Adam. One last question regarding this subject. I just took a look at the XDC file for the ZedBoard. Here is one line for that one pin I was focusing on: 

set_property PACKAGE_PIN U12  [get_ports {OLED_VDD}];  # "OLED-VDD"

 

I know "OLED_VDD" is actually the value 1 (as shown in your image). However, I'd like to know where these constants are defined?

 

That's all. Thank you for all your help. 

 

Best regards, Richard V

 

 

by Observer taylo_ap
on ‎03-10-2017 02:23 PM

Hi Richard,

 

Taking the example below

 

XGpioPs_SetDirectionPin(&Gpio, vdd, 1);

XGpioPs_SetOutputEnablePin(&Gpio, vdd, 1);

XGpioPs_WritePin(&Gpio, vdd, 1);

 

We want these pins to be a output, so we need to write  a 1 to it,how you know to write a one to it to set it as an output is an interesting question. If you hover your mouse above on the fucntion call you should get a pop up box appear which shows the information on how to use the fucntion.

Capture.PNG

 

Of course once we have set it up as an output, the value we write to it 1 or 0 depends upon how we drive the schematic circuit for that you need to review the schematics which are connected to the pins 

 

Hope this helps

 

Adam 

by Visitor richardrv
on ‎03-13-2017 09:25 PM

Hello Adam. Thank you for the I/O refresher in your previous post. I'm still trying to generate the Bitstream though. I've seen this before in the SDK code, which is next, once I can generate this bitstream.

 

I'm having some trouble getting the Generate Bitstream function to complete. It made it through Implementation, but crashes on this last step. It becomes difficult to share the interior settings of the block diagram I have shown, but I did set the EMIO to the SPI0, and set the GPIO width parameter to 4. 

 

It appears I haven't correctly set the pin directions correctly. All 6 of my pins fail. Could you suggest what I might have done wrong here?

 

Thank you, Richard V (details follow)

 

Here is the error message  (shown as 1 long line):

ERROR: [DRC 23-20] Rule violation (NSTD-1) Unspecified I/O Standard - 6 out of 136 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1].  NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: SDO, sclk, GPIO_O[3:0].

 

Here is my complete contraint file:

set_property PACKAGE_PIN U10 [get_ports {GPIO_O[3]}]; 
set_property PACKAGE_PIN U9 [get_ports {GPIO_O[0]}]; 
set_property PACKAGE_PIN AB12 [get_ports {sclk}]; 
set_property PACKAGE_PIN AA12 [get_ports {SDO}]; 
set_property PACKAGE_PIN U11 [get_ports {GPIO_O[2]}]; 
set_property PACKAGE_PIN U12 [get_ports {GPIO_O[1]}]; 

 

TMZC Blog 83 Block Diagram.png

by Observer taylo_ap
on ‎03-14-2017 02:24 PM

Richard 

 

This is an easy one, you need to tell the bit gen tool in your constraitns what the IO voltage of the bank is check out https://forums.xilinx.com/t5/Xcell-Daily-Blog/Adam-Taylor-s-MicroZed-Chronicles-Part-74-Physical-Constraints/ba-p/576914

 

To save cluttering up with comments feel free to email me directly your questions to adam@adiuvoengineering.com

 

Cheers

 

Adam

 

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.