Ccs C Compiler Example Programs

0 views
Skip to first unread message

Pasty Luckenbaugh

unread,
Aug 5, 2024, 7:35:42 AM8/5/24
to notobinda
TheCCS C compiler includes a library of example programs for many common applications. Each example program contains a header with instructions on how to run the example, and if necessary, the wiring instructions for interfacing external devices.

There seems to be little example code around for the RX65N Envision kit in general, and even less when using the GCC-RX compiler. I've seen a request or two here for a simple hello world type application. The example app that Renesas supplies for this board using their compiler is complicated and tied in to Emwin, so I've put together a much simpler one for anyone who's interested. It has touch screen and LCD drivers incorporated, all using direct register access, but neatly abstracted away into a simple API. The app reads touch screen coordinates and plots a box on the screen displaying the touch point screen coordinate inside it as text. The main function is effectively this...


Colours parameters to the lcd_* functions are in 24 bit (RGB888) format even though the display uses 16 bit (RGB565) format and are downsized in the functions. I know this is inefficient, but in demo code it's more intuitive to deal with RGB888 format colours.


I've added another simple project which writes and reads from the on-chip data flash memory. This project includes a driver for writing a variable length data structure always to the start of the data flash memory (this can easily be changed in the driver code if required). The driver uses direct register access but has a simple API so that the main program is this...


Also I've added in the repo's README.md file instructions on how to create a project for the Envision Kit using GCC RX, including instructions on how to change the default stack size from the default 256 to something larger.


There's now a 3rd one up. This one sets up GLCDC to use both display buffers. The primary buffer (2) is configured as before as 16bit RGB565 format, but this time the secondary buffer (1) is configured as 1 bit monochrome.


On running the app the primary colour one is shown most of the time with a simple moving graphic display, but at the same time the LCD API can be used to write text and scroll it to the secondary monochrome buffer (1). This is not shown until the user button is pressed when the buffer shown flips from primary to secondary when the button is pressed. When the button is released it reverts to showing the primary display.


Thought this could be useful when developing a UI application - show your UI using the primary buffer but log text output to the secondary buffer and flip to it temporarily at any time by pressing the user button.


Another one today, number 4. This is a port of FreeRTOS version 10.2.0 to run on the Envision Kit. It uses the RX600v2 for GCC port layer available on the FreeRTOS website and bits from the FreeRTOS example project for the RX64M processor.


This is by no means a tested verified port of FreeRTOS to the RX65N, it's just a bit of amateur tinkering, so should be used as demonstration, hobbyist or prototype code only, and not be used in a commercial product.


This example has drivers written going directly to registers and provides a simple API for initialising the RTC, settings and getting the time, and a simple main program that uses them that looks like this...


There are some issues with getting FatFS working on this board. Using CC-RX and FIT libraries it's easy - use the Renesas supplied USB host library, the Mass Storage Class library, and even their own cut down version of FatFS, all integrated for you. Without these libraries for GCC, it's not so easy.


A first alternative is to use the RX65N SD interface with an on-board SD card reader, for which there is board space but no hardware. Unfortunately, the SD card reader Renesas specified is unusual, single manufacturer, and now discontinued.


A simplistic synchronous SPI driver has been created for this project, using direct register access, for the SPI connections available on the Pmod connector, SCI2. This has been integrated with the SD interface part of FatFS, which means that the full FatFS API can be used once the hardware has been initialized. The default stack size needs to be increased from 256 bytes to 1024 bytes, and will need increasing again if any FatFS objects are local variables.


This is only a simple demonstration project. It's not quick, thread safe or asynchronous, and has no error checking, but might be a useful starting point if further features are required. The project is in github here...


EnvisionDemo8 - Reads the on-chip temperature sensor and calculates the chip temperature (this is almost always a few degrees higher than the environment temperature because of the heat generated by the processor).


Number 10 uses the simple 8 bit timer in PWM mode to control P55 that's available on the Pmod connector (CN14). By putting a LED in series with a resistor between this connection and the ground line also available on the Pmod connector the brightness of the LED can be varied.


Number 11 is also PWM, but a bit more complex. This demonstration shows how to use the Multi-Function Timer Pulse Unit 3 module (MTU3) for PWM generation to control the level of the Envision Kit's display's backlight.


Although this module can do simple PWM output that's not available on the pin that the backlight enable line is on (P66). This pin is only available for MTU3 PWM using one PWM output line of complementary PWM or reset synchronized PWM. Reset synchronized PWM is simpler, so that is used. The MTU3 knows this output as MTIOC7D, and is one of multiple output lines controlled in reset synchronized PWM. The other lines in this example are unused.


This demonstration shows how to use the DMA to copy from memory to memory. The LCD is set up to show 16 bit RGB565 data. A bitmap is included that is in the same format as the display. DMA is used to copy the bitmap data to the display buffer.


As the bitmap is less wide than the display, to copy the bitmap to the display buffer, non-contiguous DMA is required. The copy process is split into sections where one section is a horizontal line of the bitmap.


The copy process is initiated by pressing the user button. DMA channel 0 is initialized to start its transfer on a peripheral interrupt. The user button is initialized to create IRQ13 when it is pressed and the DMA channel is configured to be triggered by this interrupt.


When a line has been copied by DMA a DMA transfer complete interrupt is generated. This updates the destination address to the next line in the display buffer and the next DMA transfer is initiated by software. All subsequent transfers for the remaining bitmap lines are software initiated.


The example goes directly to registers. When the application is running press the user button. On each press the bitmap is copied to the display buffer (for 3 presses after which the display is full).


This example demonstrates the independent watchdog in window mode. The watchdog cycles is set to approximately 4 seconds and the window in which the watchdog is allowed to be kicked is the middle 2 seconds of that period (after 1s, before 3s). Kicking the watchdog outside of that window, or not kicking it at all, causes a reset. After a reset the reset cause is determined and displayed.


The watchdog is set up to start running automatically at reset. This requires configuring the watchdog in the Option Setting Memory, in register OFS0. The value of the register is hard coded in the e2studio generated file vects.c near the bottom of the file. This file has been edited manually to set this register value.


The watchdog in this example is kicked by pressing the user button. The state of the watchdog cycle is shown on the LCD. Pressing the user button at the appropriate time according to the message displayed will allow the application to continue. Pressing the button too early or too late according to the messages will cause a reset and restart.


I'm trying to simply use the gcc compiler to comile the blinky project and I have followed the steps outlines here and tried many other options in trying to get it to work and i keep getting the same errors.


This is actually my first time trying to compile any of the example and for the first attempt i wanted to do it in gcc. I compiled blinky and tried to debug and it doesn't let me step through the code. The program can't be loaded to the device.


Branko Miletic said:The change that I made was where it said on the website for porting the blinky led to gcc "Edit the linker script (.lds file) to rename the interrupt vector section from .intvecs to .isr_vector "




What i did was I put it back to how it originally was and the LED started to blink and i was able to debug. So i did the opposite as it was said on the site.


A compiler is an executable program that takes program source code (text) as input and translates it into an executable program (binary machine code) that it writes into a file as output. That executable program can then be run to process input data and generate output according to whatever we wrote our program to do.


Another important factor to consider: the executable is tied to the CPU and operating system on which it was generated. If you compile a program in Linux on an x86 CPU, you cannot run that executable on a Windows x86 PC, nor on a Linux ARM PC.


An interpreter is an executable program that takes program source code (text) as input, translates it internally to determine what computation it describes, then simulates the execution of that program to process input data and generate output according to whatever we wrote our program to do.


Interpreters are usually easier to work with than compilers, but they are usually slower in executing a program than it would be to run the native executable code generated by a compiler. In addition, if you want to run a program multiple times, in the compiler model you translate it once and then run the executable multiple times. In the interpreter model, you have the extra time penalty caused by re-translating the code each time you want to run the program.

3a8082e126
Reply all
Reply to author
Forward
0 new messages