White Paper RL78 IDE/Compiler Migration Guide · White Paper – RL78 IDE/Compiler Migration Guide Page 1 of 18 ... CA78K0R development tools. ... functions in the code by writing

White Paper – RL78 IDE/Compiler Migration Guide Page 1 of 18

White Paper

RL78 IDE/Compiler Migration GuideRenesas Electronics America Inc.

November 2015

Executive SummaryEmbedded system engineers who want to migrate code from a Renesas 78K MCU to an RL78 MCU, or who are considering RL78 MCUs for new designs, should consider three main factors regarding software development: the device, compiler and integrated development environment (IDE). They have multiple tool options from which to choose. Compilers and IDEs offer different features and have unique ways of implementing their capabilities. Often tool choices may require software engineers to get acquainted with operational procedures or to find ways of implementing features that a particular compiler doesn’t provide.

In general, developers of software for Renesas 78K legacy devices use the Renesas CS+ tool chain. The newer RL78 MCU family doesn’t support that tool chain in the Americas region because better support exists there for other compilers and IDEs. Therefore, system engineers in the Americas have the following compiler/IDE migration choices for moving code from 78K MCUs to RL78 MCUs:

Migration Path

Migration from Migration to

Device: 78K0 Compiler: Renesas CA78K0 IDE: Renesas CS+

Device: RL78 Compiler: IAR IDE: IAR Embedded Workbench

Device: 78K0R Compiler: Renesas CA78K0R IDE: Renesas CS+

Device: RL78 Compiler: Renesas CC-RL IDE: Renesas CS+

Device: RL78 Compiler: Renesas CA78K0R IDE: Renesas CS+

Device: RL78 Compiler: IAR IDE: Renesas e2 studio

Device: RL78 Compiler: KPIT GNU IDE: Renesas e2 studio

Device: RL78 Compiler: Renesas CC-RL IDE: Renesas e2 studio


This white paper describes cost and performance tradeoff between these various IDE/compiler options. It also explains steps for migrating C source code that originally was tailored for the CS+/CA78K0R development tools. The discussion covers key differences in project structure, interrupt declarations, SFR access, and preprocessor directives. The information presented will help system engineers make the best RL78 tool chain selections for new development projects.

Common Migration HeadachesWhen migrating a project from one compiler to another, differences between IDEs and compilers are major software engineering challenges. Significant amounts of time can be expended learn-ing the features and functionalities of each SW tool, depending on how different they are. Moving from one compiler to another can mandate changes in the I/O register structure, variable sizes, and system functions. These code migrations require reconfigurations of each I/O register and can consume major amounts of development time. Libraries used in projects will also require updating, further expanding the engineering effort and time.

Code Generator, Applilet and MigrationSystem engineers who have previously used code generators typically find code migration easier than programmers who have developed custom low-level drivers. The Renesas code generator—called “Applilet” — makes all of the system and peripheral options available to the user in its GUI before any code is written, without requiring any knowledge of the registers described in the MCU’s datasheet or hardware user’s manual.

Cost vs. Performance ConsiderationThis section compares various IDE/compiler combinations for MCUs in the RL78 family in terms of price, performance and support. It also indicates which software tools are available at no cost.

Item

IDEIAR

Embedded Workbench

Renesas e2 studio

Renesas e2 studio

Renesas e2 studio Renesas CS+

Compiler IAR RL78 KPIT GNU RL78 IAR RL78 CC-RL CA78K0R

P/N - - - YRL-E2STUDIO-1U R0C07800QSW01D

Performance (Speed, Code efficiency)

Tool Integration (Code Generator, etc.)

Support for current RSKs - - -

Support for future RSKs - - -

Support from Partner solution (RTOS, etc.) - - - -

Support Devices RL78 RL78 RL78 RL78 RL78, 78K0R

Price $$ Free $$ $$ $$

Technical Support Yes Yes Yes Yes Yes

Free version

- For 30 days full memory size with some limitations

- Up to 16 KB with some limitations

Free See IAR

- For 60 days full memory size with some limitations

- After 60 days up to 64 KB support

Up to 64 KB

http://am.renesas.com/products/tools/coding_tools/coding_assistance/applilet/index.jsp


With an RL78 MCU, system engineers can tailor the available processing capability and the IAR Systems (IAR) is a leading supplier of development tools. In particular, the company is known for its high-speed, highly code-efficient compiler. The popular IAR tool chain supports many MCUs from Renesas and other companies. Software engineers who are already familiar with IAR prod-ucts and/or need a high-performance compiler, are well advised to select the IAR tool chain for new RL78 based system designs.

The Renesas e2 studio IDE, a popular eclipse based environment, is another excellent tool choice for new Renesas RL78 MCU users. Especially, it is a good migration path from Renesas tool chains such as CS+ or HEW. The two biggest advantages of the e2 studio IDE are (1) that it works with the popular GNU compiler and (2) that both of these very effective development tools are free. They can be downloaded at no cost from the Renesas website (e2 studio) and KPIT website (GNU compiler).

A particular advantage of the GNU/e2 studio tool chain is that it supports all of Renesas’ recently introduced MCU product lines, including the RL78 Family, RX Family, and the RZ Family RZ/A1 Group. So if tool cost is a primary concern and a solid level of performance is acceptable, the GNU/e2 studio compiler/IDE combination is an optimum choice for software development.

However, if the development team prefers other RL78 compiler for the e2 studio IDE, two more options are now available: IAR and CC-RL. Renesas released CC-RL C compiler, which offers faster performance than CA78K0R, in April 2015. Important advantages for the Renesas e2 studio IDE are its common inter-face for entire Renesas platform and the fact that it offers good compiler flexibility.

The new CC-RL C compiler provides three times better performance than the existing Renesas CA78K0R compiler. Additionally, its interrupt response time is six times better, for significantly faster application execution. The compiler’s improvements make possible better performance and reduced power consumption for RL78 MCU-based designs. For example, code produced by the CC-RL C com-piler enables longer operating times for battery-operated home appliances and industrial equipment such as healthcare equipment and fire detectors. More information is available on the website (CC-RL).

The CS+/CA78K0R compiler, Renesas’ original tool chain, is not generally promoted to customers in the Americas region. However, some 78K MCU users might want to continue using this com-piler to leverage their experience with it and with 78K devices, etc. Customers interested in doing so should contact a Renesas regional sales marketing department for details.

Program Change Consideration This section provides an overview of differences in program code generated by various compilers and IDEs. The information presented will help software engineers determine which tools produce code requiring the fewest changes in migrations, and, therefore, which development tools are the best choices for specific applications.

Migration CA78K0R/CS+ to IAR

Software developers must consider important differences between the CA78K0R/CS+ and IAR tools when porting an application. Ports to the IAR compiler induce changes affecting code size and performance. In general, the IAR compiler generates code that’s more compact and thus reduces memory requirements.

Support devices by IDE

IAR e2 studio CS+ HEW

RL78 V V V -

RX100 V V V -

RX200, 600 V V V V

RX700 V V V -

RZ/A1 - V - -

78K V - V -

R8C V - - V

http://am.renesas.com/products/tools/ide/ide_e2studio/downloads.jsp

http://www.kpitgnutools.com/latestToolchain.php

http://www.kpitgnutools.com/latestToolchain.php

http://am.renesas.com/products/tools/coding_tools/c_compilers_assemblers/rl78_compiler/index.jsp


The detailed information below describes a basic approach for porting programs from the CA78K0R/CS+ tools to the IAR compiler. It illustrates some of the major changes that system engineers might encounter when doing so.

1) Create a new project in IAR

The first step to port a CS+ project is to create a basic IAR project using the steps shown below.

From [Project]-[Create New Project], select “Empty project” and press “OK”. Specify the folder to save.

The project will be created as follows.

From the [Project]-[Option] screen, the target device and other configurations are set, as needed.

2) Add C source Files and header files from CS+ workspace to IAR project

After creating an IAR template project, it’s necessary to import the CS+ project source and header files to the IAR project. From the [Project]-[Add Files] screen, the files being added are specified. The process of adding the files follows.


3) Mapping I/O registers and intrinsic functions

After the CS+ files are registered in the IAR template project, the I/O registers, compiler intrinsic functions, and application codes in the CS+ files have to be modified so that the IAR compiler can compile the codes.

■ I/O mapping

The IAR compiler’s I/O mapping files differ from those of the CS+ compiler. The I/O mapping files, which are located in the IAR Systems folder, have to be included in the in all IAR *.c files or r_cg_macrodriver.h, etc.

IAR case:

#include “ior5f104pj.h”

#include “ior5f104pj_ext.h”

■ Special function register (SFR) access

One of the notable differences between the CA78K0R/CS+ and IAR compilers is the way the general-purpose port register bit is accessed. The I/O mapping files of the compil-ers define the port access differently. Here is an example of a Port 7 access that must be changed when migrating to the IAR compiler:

CA78K0R/CS+ case:

P7.2 = 0;

IAR case:

P7_bit.no2 = 0;

■ Radix support (Binary)

The CA78K0R/CS+ compiler supports binary literal value assignments. For example, the port assignment in CA78K0R/CS+ illustrated below shows the individual bit assignment implemented using a binary radix. However, IAR doesn’t support the binary radix, making it necessary to change the P0 assignment to another radix such as Hex.

CA78K0R/CS+ case:

P0 = 0b10001000;

P0 = 0x88;

IAR case:

P0 = 0x88;

■ Built-in library function

Because the CA78K0R/CS+ and IAR compilers have different sets of built-in library func-tions, system engineers must carefully evaluate library-function usage in the application code. They should also evaluate the overall code size effect by implementing the library functions in the code.

For instance, functions shown below are built into the CA78K0R/CS+ compiler. But when the code is ported to the IAR compiler, the development team has to implement these functions in the code by writing the actual function code by itself. There are many other examples of requisite changes—too many, in fact, to be described in this white paper.


CA78K0R/CS+ case:

btobcd(); // Convert binary to BCD

wtobcd(); // Convert word to BCD

IAR case:

May require function implementation of the library function

■ Preprocessor directives (Section definition)

The CA78K0R/CS+ and IAR compilers have different ways of defining preprocessor directives. For instance, the pragma usage for section definition requires changes for the segment definition.

CA78K0R/CS+ case:

#pragma section [compiler output section name] [new section name] [AT start address]

IAR case:

#pragma section = “Segment Name” [Segment type] [Align]

■ Option byte definition and security ID

In CS+, system engineers can define the option byte and security ID in IDE under the linker option category. However, IAR doesn’t have such option; therefore, the option Byte in the code has to be defined as shown below:

CA78K0R/CS+ case:

IAR case:

/* Set option bytes */

#pragma location = “OPTBYTE”

__root const UCHAR opbyte0 = 0xFFU;


__root const UCHAR opbyte1 = 0x3FU;


__root const UCHAR opbyte2 = 0xAAU;


__root const UCHAR opbyte3 = 0x84U;

/* Set security ID */

#pragma location = “SECUID”

__root const uint8_t secuid[10] =

{0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U};


■ Interrupt declaration

Importantly, the compilers have also different pragma directives for the interrupt declaration. This requires that the interrupt function in CS+ code be updated as follows.

CA78K0R/CS+ case:

#pragma interrupt INTTM00 r_tau0_channel0_interrupt

__interrupt static void r_tau0_channel0_interrupt(void) { … }

IAR case:

#pragma vector = INTTM00_vect

__interrupt static void r_tau0_channel0_interrupt(void) { … }

CA78K0R/CS+ to IAR/e2 studio

The Renesas e2 studio IDE has many debug-ging features that aren’t supported in the IAR Embedded Workbench. As a result, software developers often compile application code in the IAR Embedded Workbench to take the ad-vantage of its superior compiler efficiency, but then use the e2 studio IDE for debugging that code. For such situations, it’s necessary to first port CS+ code to the IAR compiler by follow-ing the suggestions previously described. After the IAR compiler compiles the code, the IAR project can be brought into the e2 studio using the Renesas tool’s “Import” feature.

CA78K0R/CS+ to GNU/e2 studio

Code migrations from CA78K0R/CS+ to the GNU/e2 studio development tools are easier than CA78K0R/CS+ to IAR ports due to the radix-support similarities that exist in the GNU and CA78K0R C-compiler-languages. Some minor language differences, such as port structures, can be adjusted. Also, compiler-specific language extensions such as #pragma must be re-written in accordance with the user’s manual for the GNU compiler.

Only three simple steps are required for code migrations from the CA78K0R/CS+ compiler to the GNU/e2 studio compiler.

1) Create a new project in e2 studio

Porting a CS+ project begins by creating a basic e2 studio project for the GNU compiler by using the procedure shown below.


The Target-specific setting for the RL78 device used in the project has to be selected.

There must be not be a checkmark in the code generator box.

The “Select Additional CPU Options” window is left to its default options.


Next, the default library source and its generator settings are selected. The library source selections are:

• Newlib:CompleteISOClibrarysupporting C/C++ code.

• Optimized:SubsetofISOClibrary,size-optimised, does not fully support C++ code but sufficient for most of the application.

The following summary window shown at right will open, showing the tool-chain version, device and library usage of the project.

Clicking “OK” creates a template project in e2 studio.


2) Import C sources and header files from CS+ workspace to the e2 studio project.

After creating an e2 studio template project, it’s necessary to import the CS+ project source and header files to the e2 studio project. This can be easily done using an import feature from [File]-[Import]-[General]-[File System]. Users just select all the files that have to be imported.

The files are added to the “src” folder in the e2 studio template project. The Project Explorer window will look like the illustration shown at right:


3) Mapping I/O register and intrinsic functions

After the CS+ files are registered in the e2 studio template project, the I/O registers, compiler intrinsic functions, and application codes in CS+ files have to be modified so that the GNU compiler can compile the codes.

■ Main

The CS+ project files include a “main” function which is the actual application to be used. Therefore, to avoid the duplication, the e2 studio-generated “main” function must be changed to another name (“main_no_use”, for example).

GNU/e2 studio case:

int main_no_use (void)

{

while (1) { }

return 0;

}

■ I/O mapping

The I/O mapping file for e2 studio is different than that for CS+. These I/O mapping files are automatically generated and then added to the template project. However, this file is not included in any of the CS+ project files. Hence, in order to recognize the I/O registers by the GNU compiler, software developers must include iodefine files in all CS+ *.c files.

GNU/e2 studio case:

#include “iodefine.h”

#include “iodefine_ext.h”

■ Hardware Initialization

CS+ project files have a ‘hdwinit()’ function that initializes the hardware. However, in the e2 studio, this function has a different name: the HardwareSetup() function, which has the same purpose. Thus, to make code compatible with the GNU/e2 studio compiler, it is necessary to call the hdwinit() function from the HardwareSetup() function, as indicated below.

GNU/e2 studio case:

void HardwareSetup(void)

{

hdwinit();

}

The function of HardwareSetup is redefined by removing DI and Sysyteminit and inserting hdwinit.


■ Intrinsic function

The GNU compiler uses a different syntax for the intrinsic function than the CA78K0R/CS+ compiler does. As a result, to be ported, the intrinsic function must be changed to the form the GNU compiler recognizes. For example, interrupt enable and disable functions, EI() and DI() functions have to be ported as indicated below in GNU e2 studio. However, the iodefine files may have included the revised definitions already.

CA78K0R/CS+ case:

#pragma DI

#pragma EI

DI();

EI();

GNU/e2 studio case:

asm(“di”);

asm(“ei”);


The CS+ compiler interrupt declaration is incompatible with the GNU compiler, making it necessary to modify the existing interrupt function in the CS+ files. The e2 studio template project also generates the interrupt declaration and default handler for all interrupts in the device. So before software developers change the interrupt declaration in the CS+ files, they must comment out the interrupt-handler function generated by the e2 studio, and then make the necessary modifications in the CS+ interrupt handler. An example of this procedure appears below:

CA78K0R/CS+ case:


__interrupt static void r_tau0_channel0_interrupt (void) {…}

GNU/e2 studio case:

void r_tau0_channel0_interrupt (void) __attribute__ ((interrupt));

void r_tau0_channel0_interrupt (void) {…}

Subsequently, the “void r_tau0_channel0_interrupt (void)” should be added as new name for the interrupt handler function. The GNU compiler recognizes this designation as inter-rupt service routine.

■ Special function register (SFR) access

Because the CS+ I/O port access structure is different than that of the GNU compiler’s, the port bit access for GNU compiler should be changed.

CA78K0R/CS+ case:

P7.2 = 0;

GNU/e2 studio case:

P7_bit.no2 = 0;


CA78K0R/CS+ to CC-RL/e2 studio

The main differences between the CA78K0R and CC-RL compilers are in the language standard support, inclusion of header files, and startup files. Therefore, software engineers must implement the following code changes in order to implement successful ports.

■ I/O mapping

iodefine.h file has to be included in all CS+ source file when migrating the project so that the CC-RL/e2 studio tools can recognize the SFR registers used in the code.

CC-RL/e2 studio case:


■ Update startup files and stack initialization files

When migrating the project, the startup files from the CA78K0R/CS+ project must be changed to the CC-RL/e2 studio startup file “cstart.asm”. The CC-RL migration also re-quires adding a stack initial-setting function file stkinit.asm file that initializes the stack. Both the cstart.asm file and stkinit.asm file can be generated by creating a template proj-ect, or by using the e2 studio IDE’s peripheral code generator.

■ Differences in #pragma directive

Pragma directives are different in the CA78K0R and CC-RL compilers. For example, the enabling of interrupt functions uses the pragma directive in the CA78K0R compiler. In the CC-RL/e2 studio, however, these pragma directives are replaced with direct functions.

CA78K0R/CS+ case:

#pragma DI

#pragma EI

DI( )

EI( )


__DI( );

__EI( );


Interrupt declarations have to be modified for the CC-RL/e2 studio. One such example us-ing INTP0 is shown below:

CA78K0R/CS+ case:


__interrupt static void r_tau0_channel0_interrupt(void) {...}


#pragma interrupt r_tau0_channel0_interrupt(vect=INTTM00)

static void __near r_tau0_channel0_interrupt(void) {...}


■ Preprocessor directives

If section is defined in the project, it needs to be changed to the syntax for the CC-RL compiler.

CA78K0R/CS+ case:



#pragma section [section type] [new section name]

A detailed migration guide is available at the CC-RL compiler and documents website.

http://www.am.renesas.com/products/tools/coding_tools/c_compilers_assemblers/rl78_compiler/Documentation.jsp


Summary table for program change consideration

CS+/CA78K0R IAR IAR/e2 studio GNU/e2 studio CC-RL/e2 studio

SFR access P7.2 = 0; P7_bit.no2 = 0;

<- The same as IAR

P7_bit.no2 = 0; P7_bit.no2 = 0;

Radix support (Binary)

Yes,

P0 = 0b10001000;

P0 = 0x88;

No,

P0 = 0x88;

Yes,

P0 = 0b10001000;

P0 = 0x88;

Yes,

P0 = 0b10001000;

P0 = 0x88;

Built in library function

Many built in library functions such as

btobcd();

wtobcd():




Preprocessor directives (Section definition)


#pragma section = “Segment Name” [Segment type] [Align]

__attribute__ ((section(“<section name>”)))

#pragma section [section type] [new section name]

Option byte definition and security ID setting

Can be defined in the IDE GUI.

Defined in the project file.


__root const UCHAR opbyte0 = 0xFFU;


__root const UCHAR opbyte1 = 0x3FU;


__root const UCHAR opbyte2 = 0xAAU;


__root const UCHAR opbyte3 = 0x84U;

#pragma location = “SECUID”

__root const uint8_t secuid[10] =

{0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U};

Defined in the project file.

#define OPTION_SECT __attribute__ ((section (“.option_bytes”)))

const uint8_t Option_Bytes[] OPTION_SECT = {0xFEU, 0x73U, 0xE8U, 0xC5U};

Can be defined in the IDE GUI.

Interrupt declaration (TAU channel 0 example)


__interrupt static void r_tau0_channel0_interrupt(void) {…}

#pragma vector = IN-TTM00_vect

__interrupt static void r_tau0_channel0_interrupt(void) {…}

void r_tau0_channel0_inter-rupt (void) __attribute__ ((interrupt));

void r_tau0_channel0_inter-rupt (void) {...}

#pragma interrupt r_tau0_channel0_interrupt(vect=INTTM00)

static void __near r_tau0_channel0_interrupt(void) {...}

Import Import project to e2studio.Import project to e2studio.

[change one main to main_no_use for example]

Import project to e2studio.

“I/O mapping filesstartup files”

‘Uses standard startup routine “s0rll.rel”






cstart.asm

stkinit.asm

Hardware Initialization

void hdwinit(void)

hdwinit();int __low_level_init (void) int __low_level_init (void)

void HardwareSetup(void);

void HardwareSetup(void) {...}

void hdwinit(void);

hdwinit();

#pragma directive: disable and enable inetrrupt

#pragma DI

#pragma EI

DI( )

EI( )

__intrinsic void __dis-able_interrupt(void);

__intrinsic void __en-able_interrupt(void);

__intrinsic void __dis-able_interrupt(void);

__intrinsic void __en-able_interrupt(void);

asm(“di”);

asm(“ei”);

__DI( );

__EI( );

Those portions are explained in the previous sections


Migration from 78K0, 78K0R to RL78The code generators for Renesas 78K0R and RL78 MCUs look almost identical, despite the differ-ences in peripherals in the devices and their compilers. High-level functions for peripheral drivers have the same name or are similar; many are identical. Nevertheless, code generated for 78K0R projects won’t work in RL78 projects. That is because the two MCU families have different register sets. System engineers should be intimately familiar with the register and bit names of the MCUs they are using. Otherwise, they will find it very difficult to read generated code, despite symbolic representations. It is important to be aware that variations in peripheral functions between MCU families can cause applications to execute differently in ways that are both obvious and subtle.

General Migration Strategy

Experienced software engineers know that, when considering a code port, they should first review the Hardware Manuals of the device and make sure that the desired migration can, in fact, be achieved. If possible, they should also get the original project’s design requirements and produce a flowchart that can serve to guide the conversion.

If the code generator is one that the engineers have used before, they should obtain a copy of the original Code Generator GUI project file and then let the code generator do most of the work of migrating the low-level drivers. However, it’s important to choose the system and peripheral set-tings that best fit the application into the new hardware. This process can be simplified by using the code generator GUI’s to find differences in the peripheral features.

The user code should be inserted where it belongs within the user section comment as Start and End. Also, any other files needed to finish the code should be added and updated.

Migration Examples

Example 1:

Migration from: 78K0 device with CS+

Migration to: RL78 device with IAR EWRL78

Minimum Migration tasks:

1. Develop low-level peripheral drivers in Applilet for any peripherals that are different between the 78K0 and RL78 MCUs. The Applilet project should be set up to target the IAR EWRL78.

2. Configure port pins in Applilet. Use the iodefine for EWRL78.

3. Change the API calls to the peripherals in the original application code to the API calls to the new peripheral drivers.

4. Rewrite any assembly code that may have been written in the 78K0 instruction set over to the RL78 instruction set.

5. Change all memory allocation directives (i.e., pragmas, etc.) from the CA78K0 compiler to the IAR compiler.

6. Change all vectored-interrupt declarations, ISRs and callbacks from the CA78K0 compiler to the IAR compiler (some of this work is done in Applilet).

7. Configure C-SPY to use IECUBE to target the RL78 device.


Example 2:


Migration to: RL78 device with GNU/e2 studio


1. Develop low-level peripheral drivers in Applilet for any peripherals that are different between the 78K0 and RL78 MCUs. The Applilet project should be set up to target the GCC toolchain.

2. Configure port pins in Applilet. Use the iodefine for GCC toolchain.

3. Change the API calls to the peripherals in their application code to the API calls to the new peripheral drivers.

4. Rewrite any assembly code that may have been written in the 78K0 instruction set over to the RL78 instruction set.

5. Change all memory allocation directives (i.e., pragmas, etc.) from the CA78K0 compiler to the GNU compiler.

6. Change all vectored-interrupt declarations, ISRs and callbacks from the CA78K0 compiler to the GNU compiler (some of this work is done in Applilet).

7. Configure GDB debug to use IECUBE to target the RL78 device.

Example 3:


Migration to: RL78 device with CA78K0R/CS+


1. Develop low-level peripheral drivers in the CS+ Code Generator for any peripherals that are different between the 78K0 and RL78 MCUs.

2. Configure port pins in the Code Generator.

3. Change their API calls to the peripherals in the application code to the API calls to the new peripheral drivers.

4. Some rewrite of the assembly code that may be involved in switching to CA78K0R compiler.

5. Configure CS+ debug to use IECUBE to target the RL78 device.

Example 4:


Migration to: RL78 device with CC-RL/e2 studio


1. Port the 78K0 application code over to CS+, as outlined in Example 3.

2. Import the CS+ project into the CC-RL/e2 studio IDE.

3. Configure the debug plug-in to use IECUBE to target the RL78 device.


ReferencesReference materials for the information presented in this white paper are listed below.

1. Integrated Development Environment for RL78 Family – Migration from CA78K0R to CC-RL

o Coding: R20UT3416EJ0100

o Linkage Editor Options: R20UT3417EJ0100

o Project Manipulation: R20U T3415EJ0100

o Compiler Options and Assembler Options: R20UT3418EJ0100

2. RL78 Family User’s Manual: Software: R01US0015EJ0220

3. 78K0R Microcontrollers User’s Manual: Instructions: R01US0029EJ0600

4. CC-RL Compiler User’s Manual: R20UT3123EJ0100

5. CC78K0 Ver. 3.70 C Compiler Language: U17200EJ1V0UM00

6. CC78K0 Ver. 3.70 C Compiler Operation: U17201EJ1V0UM00

Note: The contents of this white paper were correct as of the day it was published. Please check the Renesas website and other materials for the latest technical information.

Documents

White Paper RL78 IDE/Compiler Migration Guide · White Paper – RL78 IDE/Compiler Migration Guide Page 1 of 18 ... CA78K0R development tools. ... functions in the code by writing