RE: Renesas RX65 Envision Kit - part 3: Port an example from Renesas toolchain to GCC

Jan Cumps — Mon, 01 Apr 2024 16:12:00 GMT

I'm trying a few new things with this kit.

Here, I'm using a different display: EastRising 5" 480 * 272. It's the same resolution as the original (an Newhaven), but larger. It doesn't have a capacitive touch screen. I ordered one that (hopefully) matches.

Some sites mention that it has resistive touch, but I don't know how to enable that on RX65N.

RE: Renesas RX65 Envision Kit - part 3: Port an example from Renesas toolchain to GCC

Jan Cumps — Wed, 11 Dec 2019 18:58:39 GMT

In this blog, I took a shortcut to define the LCD frame buffer:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:3ef06e6b-9b7d-4651-b12d-db8be7f5e991:type=c_cpp&text=%23define+FRAME_BUF_BASE_ADDR+++0x00800000]

The default GCC toolchain loader file does not list this part of expansion RAM - not unexpected because frame buffer is application dependent.

The CC-RX linker settings in Renesas' example do handle this:

In the linker, the section start address is defined:

[View:/resized-image/__size/331x458/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-5d2595ef-e99c-4d72-8f6b-7aa5ffe2ba10/4760.contentimage_5F00_205571.png:331:458]

and in the code a CC-RX specific construct is used to reference that memory section's start address ( __sectop() ):

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:3ef06e6b-9b7d-4651-b12d-db8be7f5e991:type=c_cpp&text=%23define+FRAME_BUF_BASE_ADDR++%28__sectop%28%22FRAME_BUFFER%22%29%29]

I think this is good practice, to avoid hard-coding the address in source, when you have the linker/loader that's the guardian of memory sections.

Although I took a shortcut, there's no real reason to do that. GCC has a construct that performs the same:

Reserve the MEMORY block and define a SECTION for the buffer in the linker file:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:3ef06e6b-9b7d-4651-b12d-db8be7f5e991:type=c_cpp&text=MEMORY%0A%7B%0A%2F%2F+...%0AFRAME_BUFFER+%3A+ORIGIN+%3D+0x800000%2C+LENGTH+%3D+0x80000%0A%7D%0A%2F%2F+...%0ASECTIONS%0A%7B%0A%2F%2F+...%0A.FRAME_BUFFER+0x00800000+%28NOLOAD%29+%3A+%0A++%7B%0A++++%22_FRAME_BUFFER%22+%3D+.%3B++++%0A++%7D+%3E+FRAME_BUFFER%0A%7D]

This will define a virtual C variable _FRAME_BUFFER that does not take memory space but has an address. That address is available in our C code:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:3ef06e6b-9b7d-4651-b12d-db8be7f5e991:type=c_cpp&text=extern+uint16_t+FRAME_BUFFER%3B%0A+%23define+FRAME_BUF_BASE_ADDR+++%26FRAME_BUFFER]

You'll see that, when the FRAME_BUF_BASE_ADDR is used, it points to the 0x008000000 location.

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:3ef06e6b-9b7d-4651-b12d-db8be7f5e991:type=c_cpp&text=++++%2F*+Get+the+top+address+of+the+frame+buffer+*%2F%0A++++p_pixel_addr+%3D+%28uint16_t+*%29FRAME_BUF_BASE_ADDR%3B]

[View:/resized-image/__size/620x86/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-5d2595ef-e99c-4d72-8f6b-7aa5ffe2ba10/7002.contentimage_5F00_205572.png:620:86]

I don't have a very strong opinion on what's the best approach. If the LCD driver would come with a header file that has the address defined, I'd definitely use that.

In this case, where it's dependent on memory mapping in the controller's extended RAM, I prefer to put it in the loader because it sets clear boundaries of external resources that are memory mapped in a single location.

RE: Renesas RX65 Envision Kit - part 3: Port an example from Renesas toolchain to GCC

Jan Cumps — Sun, 01 Dec 2019 15:15:47 GMT

Here's a list of all Renesas examples, application notes and downloads for the RX65 family. There's a lot available.