619 views
in System Integration by

Hi,

We have integrated the RX platform package with our IAR development environment, and everything seems to running well with the EW_USE_GRAPHICS_ACCELERATOR turned OFF.
However, with the EW_USE_GRAPHICS_ACCELERATOR enabled, the contents of the framebuffer memory do not get updated. On setting the breakpoint in dave_base_rx.c -> d1_setregister() and looking at the contents of the *dlistp, everything seems fine. I did a comparison with the *dlistp contents on the envision board, but did not find any significant differences. I am running an Embedded Wizard test app on both the devices which is simply coloring the entire rectangle, which is the size of the screen, with a single color such as red/green/yellow/aqua/white, and cycling through the colors every 10seconds or on every key press event.


I have verified that the MDE bits are set to 111 for setting the CPU to little endian mode, and verified that the MSTPCRC bit 28 is set to 0 when the d1_opendevice() is called.
I have also verified that the GLCDC driver is working fine, by adding a static image data into the framebuffer memory and verifying it on the screen (ILI9341). All the settings for this GLCDC driver are with respect to the PCLKA set to 120MHz, which is also the clock source for the DRW2D peripheral.

Is there any other register setting that I need to check, in order to get this DRW2D peripheral working?

1 Answer

0 votes
by
Hi,

our RX65N Platform Package and the Build Environment for the RX65N-EnvisionKit using the DRW2D graphics accelerator is completely based on the DRW2D/DAVE API provided by Renesas. This means, we only have used this API and did never made direct register settings of the graphics accelerator.

Due to the fact that the drawing functions with EW_USE_GRAPHICS_ACCELERATOR=0 are running well and the results appear on the display, the GLCDC settings seem to be fine. As far as I know there is no dependency between DRW2D and GLCDC.

Concerning the DRW2D/DAVE API I have to refer to Renesas and their documentation. Are there any error codes reported from previous function calls (maybe the initialization of the render buffer fails)?

Best regards,

Manfred.
by
Manfred,

I don't observe any errors while allocating/initializing the render buffers.

Thanks,
Neeraj
by
Hi Neeraj,

in the past we got reports about compiler issues when using IAR in combination with RX65. Do you get any compiler warnings? Can you try to switch off the optimization?

Is it possible to make an example on your hardware by using the e2Studio from Renesas?

Just some ideas...

Best regards,

Manfred.
by
Yes Manfred,
We did have some compiler warning for IAR, which was asked by one of my colleagues here :https://ask.embedded-wizard.de/5333/the-view-frame-displayed-with-incorrect-color-target-device?show=5338#c5338.

We did not get a solution for this from IAR, so for now, as a work-around, we have replaced such structure assignment operations with memcpy, and continuing with our further development. We do not see any such warnings now.

We haven't applied any optimizations to our project's debug configuration either.

It does not seem possible to port our entire project into e2studio since the EW code is a small part (library) that we integrated into our build environment.
However, I will try to create a stand-alone project to run on our hardware by making necessary changes to the RX Envision Board example that we have.

It seems to me that the DRW2D peripheral is either inactive, or is unable to access the external SDRAM, where the framebuffer is allocated, although the display list and other local variables in D/AVE library seem to run ok in that memory space.

Thanks,
Neeraj
by
Hi Neeraj,

the SDRAM access could be the difference.

But anyhow, the IAR compiler restriction should be solved, because the generated code may contain a lot of assignments of colors, rects, points...

Manfred.

Embedded Wizard Website | Privacy Policy | Imprint

...