CHAPTER 2 SYSTEM CONSTRUCTION
This chapter describes how to build a system (load module) that uses the functions provided by the RI78V4.
System building consists in the creation of a load module using the files (kernel library, etc.) installed on the user development environment (host machine) from the RI78V4's supply media.
In the RI78V4, the processing program is classified into the following three types, in accordance with the types and purposes of the processing that should be implemented.
- Tasks
A task is processing program that is not executed unless it is explicitly manipulated via service calls provided by the RI78V4, unlike other processing programs (cyclic handler and interrupt handler).
A task is processing program that is not executed unless it is explicitly manipulated via service calls provided by the RI78V4, unlike other processing programs (cyclic handler and interrupt handler).
- Cyclic Handlers
The cyclic handler is a routine dedicated to cycle processing that is activated periodically at a constant interval (activation cycle).
The RI78V4 handles the cyclic handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when a specified activation cycle has come, and the control is passed to the cyclic handler.
The cyclic handler is a routine dedicated to cycle processing that is activated periodically at a constant interval (activation cycle).
The RI78V4 handles the cyclic handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when a specified activation cycle has come, and the control is passed to the cyclic handler.
- Interrupt Handlers
The interrupt handler is a routine dedicated to interrupt servicing that is activated when an interrupt occurs.
The RI78V4 handles the interrupt handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when an interrupt occurs, and the control is passed to the interrupt handler.
The interrupt handler is a routine dedicated to interrupt servicing that is activated when an interrupt occurs.
The RI78V4 handles the interrupt handler as a "non-task (module independent from tasks)". Therefore, even if a task with the highest priority in the system is being executed, the processing is suspended when an interrupt occurs, and the control is passed to the interrupt handler.
Code the SYSTEM CONFIGURATION FILE required for creating information files (system information table file, system information header file, Interrupt information definition file) that contain data to be provided for the RI78V4.
Note For details about the system configuration file, refer to "CHAPTER 13 SYSTEM CONFIGURATION FILE".
Code the user-own coding modules that are extracted to allow the RI78V4 to be supported in various execution environments.
In the RI78V4, the user-own coding module is classified into the following four types, in accordance with the types and purposes of the processing that should be implemented.
- Interrupt Entry Processing
A routine dedicated to entry processing that is extracted from the INTERRUPT MANAGEMENT FUNCTIONS as a user-own coding module to assign instructions to branch to relevant processing (such as Interrupt Handlers or Boot Processing), to the vector table address to which the CPU forcibly passes the control when an interrupt occurs.
A routine dedicated to entry processing that is extracted from the INTERRUPT MANAGEMENT FUNCTIONS as a user-own coding module to assign instructions to branch to relevant processing (such as Interrupt Handlers or Boot Processing), to the vector table address to which the CPU forcibly passes the control when an interrupt occurs.
Note 2 When the interrupt handler is described by C language (the TA_HLNG attribute is specified in a interrupt handler definition of the system configuration file(DEF_INH)), the user does not have to describe interrupt entry processing because of the C compiler outputing "interrupt entry processing which corresponds to an interrupt request name" automatically.
- Boot Processing
A routine dedicated to initialization processing that is extracted from the SYSTEM CONFIGURATION MANAGEMENT FUNCTIONS as a user-own coding module to initialize the minimum required hardware for the RI78V4 to perform processing. It is called from Interrupt Entry Processing that is assigned to the vector table address to which the CPU forcibly passes the control when a reset interrupt occurs.
A routine dedicated to initialization processing that is extracted from the SYSTEM CONFIGURATION MANAGEMENT FUNCTIONS as a user-own coding module to initialize the minimum required hardware for the RI78V4 to perform processing. It is called from Interrupt Entry Processing that is assigned to the vector table address to which the CPU forcibly passes the control when a reset interrupt occurs.
- Initialization Routine
A routine dedicated to initialization processing that is extracted from the SYSTEM CONFIGURATION MANAGEMENT FUNCTIONS as a user-own coding module to initialize the hardware dependent on the user execution environment (such as the peripheral controller), and is called from the Kernel Initialization Module.
A routine dedicated to initialization processing that is extracted from the SYSTEM CONFIGURATION MANAGEMENT FUNCTIONS as a user-own coding module to initialize the hardware dependent on the user execution environment (such as the peripheral controller), and is called from the Kernel Initialization Module.
- Idle Routine
A routine dedicated to idle processing that is extracted from the SCHEDULER as a user-own coding module to utilize the standby function provided by the CPU (to achieve the low-power consumption system), and is called from the scheduler when there no longer remains a task subject to scheduling by the RI78V4 (task in the RUNNING or READY state) in the system.
A routine dedicated to idle processing that is extracted from the SCHEDULER as a user-own coding module to utilize the standby function provided by the CPU (to achieve the low-power consumption system), and is called from the scheduler when there no longer remains a task subject to scheduling by the RI78V4 (task in the RUNNING or READY state) in the system.
Specifies the start address of section by the user to fix the address allocation done by the linker. In the RI78V4, the allocation destinations (section names) of management objects modularized for each function are specified.
Note 1 Specification of .kernel_work0, .kernel_work1, .kernel_work2 and .kernel_work3 is required only when the relevant section names are specified in Data queue information and Fixed-sized memory pool information.
Note 2 The RI78V4 occupies the 8-byte area from the saddr area (0xffe20 to 0xfff1f). Therefore, the available saddr area for the user is up to 247 bytes.
Note 3 The section for RI78V4 is set automatically on CS+. When you want to change the start address of section, changes in the linker setting. For details about the directive file, refer to "CS+ RL78 Building".
The size of the .kernel_system section is approximately 1 KB to 9 KB depends on the service calls used in the processing program.
The following shows an expression required for estimating the .kernel_system_timer_n section size (unit: bytes).
The following shows an expression required for estimating the .kernel_system_trace_f section size (unit: bytes).
The following shows an expression required for estimating the .kernel_const section size (unit: bytes).
const = ( tsknum * 10 ) + semnum + flgnum + ( dtqnum * 5 ) + ( mpfnum * 8 ) + ( cycnum * 12 ) + ( kindnum * 4 ) + 16
kindnum: Total number of types defined in the system configuration file among five types of information related to OS resources (Semaphore information, Eventflag information, Data queue information, Mailbox information, Fixed-sized memory pool information and Cyclic handler information)
The following shows an expression required for estimating the .kernel_const_f section size (unit: bytes).
The following shows an expression required for estimating the .kernel_stack section size (unit: bytes).
sys_stksz: Stack size specified in System stack information. When multiple interrupt occurs, adds 18 bytes every one time.
The following shows an expression required for estimating the .kernel_data section size (unit: bytes).
The expression varies depending on whether or not Semaphore information is defined in the system configuration file.
data = align2 ( maxtpri + 1 ) + align2 { ( tsknum * 24 ) + ( semnum * 2 ) + 1 } + align2 ( flgnum * 3 ) + align2 { ( dtqnum * 4 ) + 1} + ( mbxnum * 8 ) + align2 ( primbx ) + ( mpfnum * 4 ) + ( cycnum * 8 ) + 20
data = align2 ( maxtpri + 1 ) + ( tsknum * 24 ) + align2 ( flgnum * 3 ) + align2 { ( dtqnum * 4 ) + 1} + ( mbxnum * 8 ) + align2 ( primbx ) + ( mpfnum * 4 ) + ( cycnum * 8 ) + 20
primbx: Total amount of Mailbox information for which the priority is specified for the attribute (message queuing method)
The following shows an expression required for estimating the size of the .kernel_work0, .kernel_work1, .kernel_work2, and .kernel_work3 section (unit: bytes).
The following shows an expression required for estimating the .kernel_data_trace_n section size (unit: bytes).
The following shows an expression required for estimating the .kernel_const_trace_f section size (unit: bytes).
Run a build on the CS+ for files created in sections from "2.2 Coding of Processing Program" to "2.5 Start address of section", and library files provided by the RI78V4 and C compiler package, to create a load module.
Note See "RI Series Start" or "CS+ Start" for details about creating a new project or loading an existing one.
Note See "CS+ Build" for details about adding or removing build target files for the project and updating the dependencies.
Note Specify "cfg" as the extention of the system configuration file name.
If the extension is different, "cfg" is automatically added (for example, if you designate "aaa.c" as a file name, the file is named as "aaa.c.cfg").
If the extension is different, "cfg" is automatically added (for example, if you designate "aaa.c" as a file name, the file is named as "aaa.c.cfg").
Note 1 If the system configuration file is added to the Project Tree panel, the Realtime OS generated files node is appeared.
The following information files are appeared under the Realtime OS generated files node. However, these files are not generated at this point in time.
The following information files are appeared under the Realtime OS generated files node. However, these files are not generated at this point in time.
Note 2 When replacing the system configuration file, first remove the added system configuration file from the project, then add another one again.
Note 3 Although it is possible to add more than one system configuration files to a project, only the first file added is enabled. Note that if you remove the enabled file from the project, the remaining additional files will not be enabled; you must therefore add them again.
On the [System Configuration File Related Information] tab, set the output of information files (system information table file and system information header files).
