Error with Pmod OLEDrgb demo

[BeamPower]

I'm now working with an Arty board.
I was able to build a Microblaze example and print Hello World to the console.
So now I'm moving forward, slowly, into Pmods.
I thought I'd try the OLEDrgb Pmod first.

Question: Starting with the Hello World example, how do I clean up the pre-existing C code in order to start with a clean slate?
Is it necessary to delete the old code samples, or can I just leave them in the workspace?

I saved the project as a new name.
A new folder was created in my c:VivadoProjects folder.

The example talked about creating the clocks.
The clock reconfiguration does not quite match what's on the screen.
First of all, there was no 100 MHz option for Clock 0.
Aren't we based on a 166.667 MHz clock, so how can that get reduced to 100 MHz exactly?
It said to make a clock less than (or equal to) 50 MHz.
So I set the following clocks:
Clock 0 9947 ps (100.52831 MHz)
Clock 1 21276 ps (47 MHz)
And I wired them to the Pmod as instructed.

I initiated a Generate Bitstream.
Some popups appeared.

One was a critical warning:

 [IP_Flow 19-4965] IP PmodOLEDrgb_axi_quad_spi_0_0 was packaged with board value 'digilentinc.com:zybo:part0:1.0'. Current project's board value is 'digilentinc.com:arty:part0:1.1'. Please update the project settings to match the packaged IP.

 [IP_Flow 19-4965] IP PmodOLEDrgb_axi_gpio_0_1 was packaged with board value 'digilentinc.com:zybo:part0:1.0'. Current project's board value is 'digilentinc.com:arty:part0:1.1'. Please update the project settings to match the packaged IP.

 [IP_Flow 19-4965] IP PmodOLEDrgb_pmod_bridge_0_0 was packaged with board value 'digilentinc.com:zybo:part0:1.0'. Current project's board value is 'digilentinc.com:arty:part0:1.1'. Please update the project settings to match the packaged IP.

No other popups

Synthesis is proceeding
Implementation is proceeding

When I get to the part about copying the source code to the Pmod src folder, I got some errors.
It needed the h files and all the xspi files copied up there too.
After I copied up all the needed files from the system wrapper, the C code is crashing on this error:
     'XPAR_PMODOLEDRGB_0_AXI_LITE_GPIO_BASEADDR' undeclared (first use in this function)
I don't think I can move forward until this is resolved.

Here's a snippet of the code that's found in main.c

void DemoInitialize()
{
    OLEDrgb_begin(&oledrgb, XPAR_PMODOLEDRGB_0_AXI_LITE_GPIO_BASEADDR, XPAR_PMODOLEDRGB_0_AXI_LITE_SPI_BASEADDR);
}

How do I fix this?

 

[Notarobot]

Hi BeamPower!

I also tested PmodOLEDrgb and it worked as expected. Unfortunately my board is Zybo and I can't provide your with detail guidance since your board different.

I assume that your have a copy of the Digilent IP from GitHub and you included it in the Vivado IP catalog. This makes Pmod resources available to SDK without any extra effort. The source code you can find in the Driver folder along with the image file which will be displayed on the screen. The easiest approach is to start as new application and then copy and paste the source code created by Digilent. BTW you should see a driver folder in the SDK.

The warnings you can ignore. I don't think exact frequency matters also. It is important to create correct system block diagram and make sure that Pmod module is connected to the Pmod ports on the board. PmodOLEDrgb should have connection to a port JB (or other) and if not use Vivado Board Tab to make such connection. Also function usleep(us) should be replaced by sleep(seconds) for the Microblaze.

Good luck!

[D@n]

@BeamPower,

I've also used OLEDrgb quite successfully on an Arty board, just not with the MicroBlaze processor.  You can find my work here, the OLEDrgb Verilog driver here, and an example program that runs drives it from the ZipCPU here.

Dan

[jpeyron]

Hi @BeamPower,

I am sorry about the inconvenience, we are currently in the process of updating the Pmod IP tutorial. The pop up critical warnings are to let you know that the IP's were made on a different board. These warning first started in Vivado 2016.x and are not an issue. When I completed the project as I describe below I did not have an issue with 'XPAR_PMODOLEDRGB_0_AXI_LITE_GPIO_BASEADDR' being undeclared (first use in this function) so for now I would suggest to follow the getting started with Microblaze tutorial for the arty here.

When using a SPI Pmod IP I add an additional output clock of 50 Mhz to the clock wizard when using Microblaze. I then add the Pmod IP cores when I would add the UART in the getting started with Microblaze tutorial. In this case you do not need to add the UART. Next I connect the additional output clock on the clocking wizard to the ext_spi_clk on the pmod and continue with the tutorial for Vivado.

Once you are in sdk add a new empty application. Next import the three files from vivado-library\ip\Pmods\pmodOLEDrgb_v1_0\drivers\PmodOLEDrgb_v1_0\examples to the src folder in the application. In the case of the PmodOLEDrgb usleep is set to go for too long. I reduced the delay and the project works fine. I have attached a working project using the Arty and the PmodOLEDrgb  in Vivado 2016.4.

cheers,

Jon

PmodOLEDRGB_Arty.zip

[BeamPower]

Hello,

I am running Vivado 2016.4 on a Windows 10 box.

I am attempting to learn how to use the OLEDrgb.

I restarted the project and got no errors this time.

But the display is slow as molasses in January!

It blips out one letter every 10 seconds or so.

Very odd.

Maybe there's a clocking error on my Block Design?

Maybe someone can help me?

Say, is there some way I could sent you my project file for you to look at?

Anyway, I will attached a separate OpenOffice file that includes popups and graphic snapshots.

I added 2 clocks as instructed, but there's an unconnected pin down there.

The drawing in the tutorial shows a completely different connection.

 

Let me back up to the beginning.

First of all, is this an accurate drawing of your basic Microblaze circuit?

My drawing looks like this:

If I take the simplistic approach, my drawing has 9 blocks including the OLEDrgb interface connector.

The tutorial drawing has 11 blocks prior to the addition of the OLEDrgb interface coinnector.

Somehow, even with my abbreviated circuit, I have established a connection to the OLEDrgb. The OLEDrgb is just very, very, slow!

I notice the final drawing for the tutorial has 14 blocks. Wow!

I wish I could read it...

Thanks and have a great weekend.

 

 

Arty OLEDrgb slow.odt

[BeamPower]

How do you paste images into a posting?

I copy and paste from OpenOffice, but all the graphics get lost.

[artvvb]

@BeamPower

Once you have attached an image to your post just like any other file, you can insert it into your post with the plus button as seen below. You can zip and attach your project as well.

 

I'm not sure what would cause that slow of an update, and it would certainly be helpful to see the project. What is particularly strange is that it sounds like a full character is being updated once every ten-ish seconds? I'm more familiar with the PmodOLED, which is fairly similar, but I would expect a slow clock to write a vertical line of eight pixels at a time at least for that device. My best guess right now is that perhaps the sleep functions (MB_sleep, usleep, sleep) are acting strangely, Xilinx made some changes to which of those functions can be used in SDK 2016.4 for microblaze. I'd very much like to see your C files at least.

Thanks,

Arthur

[D@n]

@artvvb,

I've been digging into the straight (non-RGB) OLED, and the two have *very* different data structures.  The OLEDrgb memory is more similar to a traditional video memory than the OLED(non-rgb) is.

Dan

[artvvb]

@D@n

Perhaps I need some more coffee, you are totally right, from the driver point of view, the OledRGB has a single spi transaction with a bitmap buffer per character write, so that behavior makes a lot more sense. If I am reading the driver code correctly, it looks like each character transaction requires sending a few bytes more than 128 bytes, so confirming the ext_spi_clk frequency going into the Pmod IP would be a very good idea. There is a call to usleep per Oled_DrawBitmap call, which is called once per character write, so the sleep headers are also still a possible problem. From what I can tell, these would be the two main plausible sources of per-character delay.

Arthur

[BeamPower]

I'm not sure it's the C-code that's the problem.
I think there's a wiring problem on the block diagram.
Has anyone had a chance to view the document I attached earlier?
Thanks.

[artvvb]

For the block diagram, I notice that ui_addn_clk_0 from the MIG is disconnected? What are the frequencies of ui_clk, the ui_addn_clks, as well as clk_out1 and clk_out2 from the clk_wiz? Clicking on the pin name will give these frequencies. Your clocks all appear to be connected as I would expect. The following would be my starting point for a new pmod ip design, the only notable change is the addition of an axi_uartlite block for a little more debugging - the clk_out3 frequency is 50MHz. (There are potential issues that we are looking into with sourcing the ext_spi_clk from the MIG, we will let you know when that has been answered)

I hope this image is readable enough...

 

Thanks,

Arthur

[alpha94]

hi

I was trying to connect PmodOLED instead of PmodOLEDrgb. The resource centre mentioned to connect the 50MHz clock to ext_spl_clk but I couldn't find that port for the Pmod.

[artvvb]

@alpha94

Could you create a new thread in the FPGA subforum as well as provide what version of Vivado you are working with, and a screenshot of your block design as it currently is?

Posting in an existing thread may or may not create notifications for everyone who has posted here before.

Thanks,

Arthur

[artvvb]

@alpha94

This was an error in the Pmods Supported table of the Pmod IP tutorial, thanks for bringing it to our attention. The Pmod OLED IP does not have an ext_spi_clk port, as the internal pin that is normally sourced by a port with this name is tied to the AXI clock. If the AXI clock is faster than ~160MHz, then this implementation will cause problems, otherwise, it should be fine. I will make sure that this gets made more consistent in the next validation pass, and will update the wiki page. The IP core should work as is (Vivado version depending, as always).

Thanks,

Arthur