JP2003005967A - Information processor and information processing method and information processing program for program development - Google Patents

Abstract

PROBLEM TO BE SOLVED: To easily discover the mismatching of programs in an early stage by detecting various problems due to the use of an already existing user defining module. SOLUTION: This information processor is provided with an environment defining part for defining environment definition data in an performing environment with respect to a program to be developed, a check part for verifying the virtual performing state of the development program in the performing environment based on the environment definition data, a display information preparing part for preparing display information for visually displaying the virtual performing state, a display device for displaying the display information to a user, an interface part formed on the display screen of the display device for allowing the user to perform an operation to change the visually displayed virtual performing state on the display screen, an performance object generating part for outputting the development program in configurations performable under the performing environment, and a user defining module registering part for defining information related with a user defining module to be used by the development program.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a technique for performing various verifications under an execution environment when an existing user-defined module is used in a programming stage in developing an application program or the like.

[0002]

2. Description of the Related Art In developing an application program or the like, using a user-defined module, which is an existing asset, has great merits such as reduction of labor for program creation and prevention of mistakes.

Conventionally, when programming is performed using such a user-defined module, the person in charge of programming analyzes the user-defined module and uses the resources under the execution environment in the user-defined module. It is necessary to fully understand such matters. In addition, the person in charge needs to incorporate the user-defined module into his or her program, taking into consideration the state change of the resource due to the use of the user-defined module and the consistency / inconsistency of the program.

Further, the work of confirming the consistency of the entire application program incorporating the user-defined module is performed by sequentially executing the objects in the execution format under the same conditions as the actual execution environment and verifying the behavior of the application program. A method for achieving overall consistency is adopted. By this method, for example, it is possible to recognize problems such as an irregular state change of hardware resources caused by the use of the user-defined module and a shortage of hardware resources caused by using the same user-defined module multiple times. The consistency of the entire application program that incorporates the user-defined module can be achieved.

[0005]

However, as described above, in order to analyze an existing user-defined module, it is necessary to dig down to the same level as when creating the user-defined module, and to analyze the module. The configuration and the description method tend to depend on the module creator, and when other person in charge uses it, the analysis requires considerable time and labor. Furthermore, errors such as oversights and misunderstandings may occur during analysis, making it difficult to use existing user-defined modules.

Furthermore, as described above, it is possible to confirm the consistency of the entire application program including the user-defined module unless the execution format objects are sequentially executed under the same conditions as the actual execution environment. Can not.

Therefore, in the programming stage, it is very difficult to detect problems caused by utilizing the existing user-defined module.

According to the present invention, in the programming stage, it is possible to detect various problems caused by utilizing the existing user-defined module and detect the inconsistency of the program at an early stage. An object of the present invention is to provide an information processing device, an information processing method, and an information processing program that enable the development of a general application program.

[0009]

In order to solve the above problems, the present invention provides an environment definition unit for defining environment definition data in an execution environment including hardware and software resources for a program to be developed, and the environment definition. A check unit for verifying the virtual execution state of the development program in the execution environment based on the data, a display information creation unit for creating display information for visually displaying the virtual execution state, and a user for the display information. A display device to be displayed on the display device, an interface unit that is formed on the display screen of the display device, and that allows a user to perform an operation of changing the virtual execution state visually displayed on the display screen; A program development unit that includes an execution object generation unit that outputs the program in a form that can be executed under the execution environment The information processing apparatus according to claim 1, further comprising a user-defined module registration unit that defines information about a user-defined module used by the development program, wherein the user-defined module registration unit is a hardware used by the defined user-defined module. It is characterized by having a function of prompting the user to define the information of the wear resource or the software resource in the environment definition unit.

According to the present invention, it is possible to define information about a user-defined module and easily register and manage information on hardware resources or software resources used by the user-defined module based on the information.

Further, the checking unit may be configured such that, when the development program uses the user-defined module,
A position check unit that verifies the validity of the position to be used based on information about the user-defined module; and, when the development program uses the user-defined module, the user-defined module for the resource under the execution environment. When a resource operation check unit that detects a malfunction related to an operation based on information about the user-defined module and the development program uses the same user-defined module a plurality of times, the use is detected a plurality of times and the execution is performed. It is characterized by including a usage number check unit that prompts the user to exclusively control the use of the user-defined module each time by using the resource under the environment.

According to the present invention, the validity of the use position of the user-defined module, the defect regarding the operation of the user-defined module with respect to the resource, the problem of using a plurality of the same user-defined module, etc. are detected early in the programming stage. be able to.

[0013]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention will be described below with reference to the drawings.

In this embodiment, the μITRON3.0 specification (Micro Industrial Real-time Operating System Nucl), which is a built-in real-time OS for microcomputers, is used.
eus Ver.3.0; hereinafter referred to simply as "RTOS") will be described as an example of the case of developing an application program.

[Configuration of Hardware Resources and Software Resources] FIG. 1 is a schematic view showing the configuration of hardware resources for implementing the information processing apparatus 10 for program development according to this embodiment.

As shown in FIG. 1, the hardware resources include a central processing unit (CPU) 1 and a RAM 2. The central processing unit (CPU) 1 and the RAM 2 are
It is connected to the ROM 3, the communication device 4, the auxiliary storage device 5, the display device 6, the input device 7, and the output device 9 via the bus 8.

The ROM 3 and the auxiliary storage device 5 store the code of a computer program in which a series of processing procedures for realizing the information processing executed by the information processing device 10 is described. This computer program gives instructions to the central processing unit 1 and the like in cooperation with the operating system on the information processing apparatus 10, and is executed by being loaded in the RAM 2.
The code of the computer program is stored in a computer-readable / writable recording medium such as information storage means (semiconductor memory, floppy (registered trademark) disk, hard disk, etc.) or optical reading means (CD-ROM, DVD, etc.). Can be recorded.

As the user interface hardware in the information processing apparatus 10, an input device 7 for inputting data such as screen position information and character information.
There is also a display device 6 and an output device 9 for presenting data to the user. The input device 7 includes, for example, a pointing device, a keyboard, and the like, and the display device 6 and the output device 9 include devices such as a monitor and a printer that visualize and display or output data. The user can interactively operate the information processing apparatus 10 by using the input device 7, the display device 6, and the output device 9.

As another method for inputting / outputting data, the communication device 4 may be used to access a computer network (LA).
N, WAN such as the Internet, wireless communication network, etc.), a method of transmitting and receiving data to and from other computers, etc., and a method of inputting and outputting data via a recording medium such as the auxiliary storage device 5 are also assumed. It

The information processing apparatus 10 is realized by controlling the hardware resources of the computer system as described above by software, and various concrete configurations of this computer system and software are conceivable.

[Functional Configuration of Information Processing Apparatus] FIG. 2 is a block diagram schematically showing the functional configuration of the information processing apparatus 10 in the present embodiment.

As shown in FIG.
Has an environment definition setting unit 11, a programming unit 15, a template file generation unit 21, a user definition module registration support unit 13, a check unit 16, an execution object generation unit 19, and a display information generation unit 17.

The environment definition setting unit 11 analyzes the environment definition data input from the input device 7, and supplies the analysis result to the programming unit 15. This environment definition data contains the RT used by the application system to be developed.
It includes the number of objects under OS management, their initialization settings, initialization data for external / internal interrupt factors generated in the microcomputer in which the development application system operates. The environment definition setting unit 11 also generates environment definition information from the analysis result and stores it in the environment definition information database 12.

FIG. 14 shows the environment definition information database 12
A configuration example of is shown. In the example shown in FIG. 14, the environment definition information database 12 includes task-related information 90 and mailbox-related information 95. The task-related information 90 includes a task name 91, a task ID 92, and a task name 91 for each task.
Information such as the priority 93 and the initial state 94 is stored, and the information 95 regarding the mailbox stores information such as the mailbox name 96, the mailbox ID 97, and the message 98.

Returning to FIG. 2, the programming section 15
A development program is constructed by a programming operation performed via the input device 7 and stored in the programming database 18. Also, programming database 1
Reference numeral 8 is a database for managing the dynamic state and error information of the object being programmed, and information such as the state change of the object due to the use of system calls and user-defined modules is updated sequentially.

FIG. 13 shows the programming database 1
8 shows an example configuration. In the example shown in FIG. 13, the programming database 18 includes task-related information 60, ready queue-related information 70, mailbox-related information 75, dispatch condition information 80, user-defined module information 85, and the like.

Returning to FIG. 2, the template file generation unit 21 receives a template file generation instruction from the programming unit 15, generates a template based on the information in the programming database 18, and outputs it to the template file 22.

User-defined module registration support unit 13
Analyzes the user-defined module data input from the input device 7 and stores it in the user-defined module database 14. On the other hand, when the user-defined module inputs the use of the environmental resource, the user is requested to separately register the environmental resource.

FIG. 15 shows a configuration example of the user-defined module database 14. In the example shown in FIG. 15, the user-defined module database 14 stores information such as a system call 101, a usage section 102, an object 103, and a remark 104 used by the user-defined module.

Returning to FIG. 2, the check unit 16 executes the application program to be developed based on the environment definition data in the environment definition information database 12 and the user definition module data in the user definition module database 14. The environment is virtually constructed according to the operation rules of the environment, and the operation of the development program is checked under this virtual environment. The check unit 16 includes a user-defined module use position check unit 23.
A user-defined module system call use check unit 24, a user-defined module use number check unit 25, and other check unit 26 are included. When the development application program uses the user-defined module, the user-defined module use position check unit 23 verifies the validity of the position to be used based on the information about the user-defined module.
When the development application program uses the user-defined module, the system-call usage check unit 24 in the user-defined module detects a defect related to the operation of the user-defined module with respect to the resources under the execution environment based on the information about the user-defined module. . User-defined module usage count check unit 25
When a development application program uses the same user-defined module multiple times, it should detect the multiple usages and exclusively control each usage of the user-defined module by using resources under the execution environment. Prompt the user. The other check unit 26 performs check items other than the above, such as checking the interface between the application program and the user-defined module, and checking for duplicate variable names.

Further, the execution object generation unit 19
Is to compile the developed program and output it as an execution object file (electronic file) 20. The display information creating unit 17 is for generating each information so that the display device 6 such as a monitor can output the information.

[Configuration of GUI (Graphical User Interface)] Next, the configuration of a GUI (Graphical User Interface) that is an interface of the programming unit 15 will be described. FIG. 3 illustrates the screen configuration displayed on the display device 6.

This GUI is displayed as a window on the display device 6, and this window is composed of the following elements.

(1) System call / user-defined module list display section 31 for selecting system calls and user-defined modules used in the development application program (2) In the development application program acquired from the environment definition information database 12 Available in R
RTOS object display section 32 for displaying objects under TOS management (3) Programming operation section 33 for performing operations associated with programming (4) Time axis for each object unit in the programming operation section 33, which is a system call or user-defined Processing line 34 for designating the position where the module is used or the position where the module is operated. For programming operations that use system calls or user-defined modules, select the system call or user-defined module to be used from the system call / user-defined module list display section 31. After the selection, the position of the selected module is determined on the processing line 34 of the task in the execution state. The position on the processing line 34 is referred to as a "use position". The programming operation is performed along the flow of time on the processing line 34, with the starting point of the program being the starting point.

The processing line 34 has editing operation functions such as system call and user-defined module addition, movement, and deletion operations.

[Processing Procedure of Entire Information Processing Device] FIG.
It is a flow chart which shows the example of the whole operation of information processor 10 concerning this embodiment.

First, as the necessary data, the user inputs environment definition data for developing an application program from the input device 7 to the environment definition setting section 11 (Step 01). The environment definition setting unit 11 saves the input environment definition information in the environment definition information database 12 (Step 02). Here, the environment definition information that is input includes information about system calls, objects, etc. used by the application program.

On the other hand, the user inputs information on the user-defined module used in the development application program to the user-defined module registration support unit 13 from the input device 7 (Step 03). The user-defined module registration support unit 13 saves the input information about the user-defined module in the user-defined module database 14 (Step 04). Here, the input information about the user-defined module is, for example, information about resources such as objects and system calls used by the user-defined module, and information about task priorities.

When the environment definition setting unit 11 has the necessary data, the input device 7 inputs information for activating the programming unit 15 to the environment definition setting unit 11. The environment definition setting unit 11 that has received the input is the programming unit 15
Start (Step 05). At the time of this activation, the GUI (Gr) that is the interface of the programming unit 15 shown in FIG.
aphical User Interface) is displayed on the display device 6.

After being activated, the programming device 15 waits for a user to input a programming operation from the input device 7. The user inputs programming data or the like by programming operation via the input device 7 (Step 06).

Next, regarding the program input in Step 06, each check function 23-2 in the check unit 16
Check programming information according to Step 6 (Step
07).

As a result of the check, it is judged whether or not there is an error (Step 08), and if there is an error, the display information creating section 17 creates the information of the error display concerning the content of the error, and the display device 6 And then display again
Return to Step 06.

If it is determined in step 08 that no error has occurred, the programming database 1
The programming information and the object information are stored in step 8 (step 09 to step 10).

Thereafter, the user waits for a selection as to whether or not to end programming (Step 11), and if programming is to be continued, the process returns to Step 06 to accept the input of programming data again.

When the end of programming is selected in step S108, the template file generator 21 generates and outputs the template file 22 (Step 12), and the execution object generator 19 saves the execution object file 20. Generate and output, and finish the work (Step12 to Step13).

Next, a more detailed description will be given by showing a concrete example when developing the application program using the user-defined module. In the present embodiment, an example of developing an application program using the user-defined module "set_led_on" will be shown. This user-defined module "set_led_on" uses the system call "rcv_msg" for the mailbox "MBXA", which is an RTOS object, and according to the content of the received message, LED (Light Emit) which is a hardware resource.
ting diode) is lit and displayed. The mailbox is an object for performing synchronization and communication by passing a message placed on the shared memory. The mailbox function includes a function of creating / deleting a mailbox, a function of sending / receiving a message to / from a mailbox, a function of referring to the status of the mailbox, and the like.

[First Embodiment] The registration processing (Step 03 to Step 04) of information regarding the user-defined module described above with reference to FIG. 4 will be described in more detail.

FIG. 5 is a flow chart exemplifying a detailed processing procedure of the registration processing (Step 03 to Step 04) of information regarding this user-defined module.

First, the user inputs information regarding the user-defined module used in the development application program to the user-defined module registration support unit 13 from the input device 7 (Step 21). 6 to 9 show examples of the configuration of the input window, which is the GUI at this time.

FIG. 6 is a window 41 for registering the module name of the user-defined module. In the input field 42, the module name "set_led_on" of the user-defined module is entered.

FIG. 7 shows a window 43 for inputting a system call name used by the user-defined module.
System call name "rcv_msg" and system call "rc
The mailbox name "MBXA", which is an object used by v_msg ", is entered.

FIG. 9 shows a window 47 for inputting the RTOS object, and the mailbox name "MBXA" and the mailbox ID are entered in the input field 51. Also, in this window 47, a mailbox number 48, an event flag number 49, a semaphore number 50
Can also be specified.

FIG. 8 is a window 45 for inputting information to be written in the remarks column, and "Light a LE" is added as a comment for the user-defined module "set_led_on".
D "is entered.

When the above input operation is confirmed, the user-defined module registration support unit 13 determines whether or not the input information on the user-defined module includes information on the environment definition (Step 22). As a criterion for the determination, for example, in the window 47 for inputting the RTOS object shown in FIG.
It is determined by whether or not the information of the object under the OS management is input.

If the result of determination is that it is not included,
The entered information about the user-defined module is saved and the user-defined module database 14 record is generated (Step 28 to Step 29).

On the contrary, when the information about the environment definition is included in the input information about the user-defined module (Step 22), the object is registered from the input device 7 to the environment definition setting unit 11. A comment to the effect is displayed and output to the user (Step 23).
For example, the comment is "Please register the mailbox in the environment definition setting section".

According to the instruction, the user activates the environment definition setting unit 11 from the input device 7 and registers the information of the RTOS object (Steps 24 to 25). here,
One mailbox "MBXA" will be registered, and this information is saved as environment definition information and stored in the environment definition information database 12 (Step 26 to Step 27).

At the same time, the information input as environment definition information is also saved as user definition module information,
It is also stored in the user-defined module database 14 (Step 28 to Step 29). Here is the mailbox "MBX
ID information of "A" is user-defined module database 1
4 is also stored (object 10 in FIG. 14).
3).

As described above, by providing the means for registering the user-defined module information, the user-defined module information can be easily made into a database and can be effectively used in the subsequent programming operation. Further, when the user-defined module to be registered has a function of prompting the user to register information regarding the resource when using a resource such as an RTOS object, the hardware resource or software used by the user-defined module is registered. Resource information can be registered / managed easily and reliably.

[Second Embodiment] An example in which the user-defined module "set_led_on" registered in the first embodiment is used from the task "TASKA" of the development target application program will be described.

The user selects the user-defined module "set" in the system call / user-defined module list display section 31 of the GUI of the programming section 15 shown in FIG.
_led_on "is selected, and the use position of the user-defined module" set_led_on "is selected on the processing line 34 of the task" TASKA ".

On the other hand, the programming section 15
The user-defined module use position check unit 23 in the check unit 16 checks whether the user-defined module "set_led_on" can be used at the position selected by the user. The user-defined module use position check unit 23 executes a predetermined check according to the processing procedure illustrated in FIG.

As shown in FIG. 10, first, the user-defined module use position check unit 23 determines whether or not the use position of the user-defined module selected by the user is within the task dispatch prohibited section.
The determination is made based on the information 80 on the dispatch condition in the programming database 18 (Step 31). Figure 1
In the example shown in FIG. 3, since the dispatch condition 80 is as follows, it is determined that it is not the dispatch prohibited section.

(1) During interrupt: "0" (not during interrupt) (2) Kernel dispatch: "1" (enabled) (3) User dispatch: "1" (enabled) (4) Dispatch request: "1""(Allow) When it is determined in the determination process of Step 31 that the dispatch-disabled section is not included, the user-defined module use position check unit 23 determines that the user-defined module is" set_led_o ".
Allow use of n "(Step 36).

On the contrary, when it is determined that the dispatch-prohibited section is set, the user-defined module use position check unit 23 next determines the user-defined module "set_led".
It is determined whether a system call is used in "_on" (Step 32). This determination process is performed based on the information 101 about the system call in the user-defined module database 14. In the example shown in FIG. It can be seen that the system call "rcv_msg" is used in the user-defined module "set_led_on".

When it is determined in step 32 that the system call is not used in the user-defined module, the user-defined module use position check unit 23
Permits the use of the user-defined module "set_led_on" (Step 36).

On the contrary, if it is determined that the system call is used in the user-defined module, then the user-defined module use position check unit 23 is used in the user-defined module "set_led_on". It is determined whether or not there is a system call whose use is prohibited in the dispatch prohibited section (Step 33). This determination process is performed based on the information 102 on the usage section in the user-defined module database 14. In the example shown in FIG. 15, since the system call "rcv_msg" used in the user-defined module "set_led_on" is as follows, it can be seen that it is not a prohibited system call.

(1) Task: "1" (Issuable) (2) Handler: "0" (Issuable) (3) Dispatch prohibited section: "0" (Not prohibited section) User-defined module "set
If it is determined that there is no system call whose use is prohibited in the dispatch prohibited section among the system calls used in "_led_on", the user-defined module use position check unit 23 determines that the user-defined module "set_led_on". Is permitted (Step 36).

On the contrary, when it is determined that there is a system call whose use is prohibited in the dispatch prohibited section,
The user-defined module use position check unit 23 displays an error message on the display device 6 and disables the use of the user-defined module "set_led_on" (Step3
Five).

As described above, since the validity of the usage position of the user-defined module can be verified at the programming stage, the inconsistency of the development application program when the user-defined module is used can be detected early. You can

[Third Embodiment] Next, various resources (RTOS such as tasks) used inside the user-defined module
An example of detecting a defect related to a programming operation for an object) will be shown. Here again, an example in which the user-defined module "set_led_on" registered in the first embodiment is used from the task "TASKA" of the development target application program will be described.

The programming section 15 causes the system call use check section 24 in the user-defined module in the check section 16 to check the system call used in the user-defined module "set_led_on". The system call usage check unit 24 in the user-defined module executes a predetermined check according to the processing procedure illustrated in FIG.

As shown in FIG. 11, first, the system call usage check unit 24 in the user-defined module acquires the information 101 on the system call from the user-defined module database 14 and sets it as the system call to be investigated (Step 41). ~ Step42). At this time, if there is no system call used in the user-defined module, the subsequent processing is skipped and the process proceeds to Step 47 described later.

Next, the system call usage check unit 24 in the user-defined module determines the return value when the system call to be investigated is used in the application program to be developed, based on the information in the programming database 18. Then, the return value at that time is stored as the error code 68 in the programming database 18.

The system call use check unit 24 in the user-defined module determines whether the return value set here is a value indicating normal termination (Step 43). Return to Step 41 to verify the system call of. If the value does not indicate normal termination, an error message regarding the return value of this system call is displayed on the display device 6 and the user is asked whether the return value is correct or not (Step 44).

On the other hand, when the user determines from the input device 7 that there is no problem with this return value,
If "Continue" is selected, and if it is determined that there is a problem, then "Stop" is selected (Step 45).

When "continue" is selected, the system call use check unit 24 in the user-defined module
Returns the process to Step 41 to verify the next system call (Step 46).

When the verification is completed for all system calls, or the user "interrupts" in the middle
If is selected, the system call usage check unit 24 in the user-defined module prompts the user to make a final decision as to whether or not to use this user-defined module (Step 47).

If the user's final judgment is "confirmed", the use of the user-defined module is decided, and conversely, if "cancel", the use of the user-defined module is canceled (Step 48- Step50).

When the above processing is applied to the case of this embodiment, the system call "rcv_msg" used inside the user-defined module "set_led_on" is the target of the investigation, and the system call of this case is used. The return value is
According to the information in the programming database 18, "EV_W
AIT "(waiting state) is determined. Here, the system call usage check unit 24 in the user-defined module
Asks the user to decide "continue" or "interrupt", and if the user selects "continue", this system call "r"
The investigation on "cv_msg" is completed. If there is the next system call, the same processing is performed again. If the final user's judgment is "confirmed", the system call usage check section in the user-defined module 24 enables the use of this user-defined module "set_led_on" and ends the processing.

After that, the programming unit 15 receives this, confirms the ready queue head task 70 at this time from the programming database 18, and sets the processing line 34 of the task as an effective line to perform the next programming by the user. Wait for the operation.

As described above, the execution environment by using the user-defined module is confirmed by checking the return value of the system call used when the system calls used inside the user-defined module are sequentially processed. It is possible to sequentially check changes in managed resources and state transitions of task objects. Therefore, in the programming stage, it is possible to detect inconsistency in the state transition of the task object due to the use of the user-defined module, excess or deficiency of resources under the execution environment, etc. at an early stage.

[Fourth Embodiment] Next, an example in which the same user-defined module is used a plurality of times in an application program to be developed will be described.

The programming unit 15 causes the user-defined module usage number check unit 25 in the check unit 16 to check whether the user-defined module "set_led_on" is used multiple times in the application program to be developed. The user-defined module usage number check unit 25 executes a predetermined check according to the processing procedure illustrated in FIG.

As shown in FIG. 12, first, the user-defined module usage number check unit 25 determines that the same user-defined module has the same task or another task before the selected position at which the user has selected to use the user-defined module. It is determined whether the processing line 34 is not being used (Step 61). If the same user-defined module is not used, the process ends.

When the same user-defined module is used in the processing line 34 of the same task or another task, the user-defined module usage number check unit 25 is next used before the usage position. The information of the location where it is displayed is displayed on the display device 6 and presented to the user (St
ep62), ask the user if it is necessary to manage this user-defined module (Step 63).

If the instruction from the user is "unnecessary", the process is terminated, and if it is "necessary", the process proceeds to the next process (Step 64).

Next, the user definition module usage number check unit 25 displays the management procedure information on the display device 6 and presents it to the user (Step 65). This management procedure information is an R for managing multiple uses of the same module.
Information such as a TOS object (for example, a semaphore) and setting values related to the object.

Further, the user definition module usage number check unit 25 activates the environment definition setting unit 11 and prompts the user to input the environment definition information regarding the RTOS object (Step 66).

When the user inputs environment definition information regarding the RTOS object via the input device 7 (Step 6
7), User-defined module usage count checker 25
Displays the system call necessary for managing the use of the same module a plurality of times and the information such as the position where it should be used on the display device 6 and ends the processing (Step 68).

After that, the user performs programming operation according to the information displayed on the display device 6.

If the above processing is specifically applied to the case of this embodiment, for example, the task "TASKB" is used before the user-defined module "set_led_on" is used by the task "TASKA".
It is assumed to be used in. User-defined module "set_led_on" on processing line 34 for task "TASKA"
When the user specifies the usage position for using, the user-defined module usage number check unit 25 operates and the user-defined module "set_l
The position where ed_on is used, that is, the position used by the task "TASKB" is detected, it is displayed on the display device 6, and further an instruction as to whether to manage the user-defined module "set_led_on" is issued. Prompt the user to do so.

When the user inputs an instruction that the management is "necessary" from the input device 7, the user-defined module usage number check unit 25 displays a comment on the display device 6 indicating that the user defined module is used for management. , Activates the environment definition setting unit 11.

When the user registers one semaphore having an initial semaphore count in the environment definition setting section 11 via the input device 7, the user defined module usage number check section 25 uses the user defined module "set_led_on". Before that, a comment indicating that the system call "wai_sem" is issued to acquire the semaphore resource is displayed on the display device 6.

The user uses the user-defined module "set_led_on" only when the semaphore resource can be acquired by the system call "wai_sem". For example, when the conditions for changing the LED state are met, the system call " sig_s
Program to return the semaphore resource with "em".

As described above, when the same user-defined module is used a plurality of times in the application program, by managing it, the hardware resources etc. used by the user-defined module can be managed. Shortages and inconsistencies in state changes can be prevented at the programming stage.

Although the present invention has been described in detail above, the present invention is not limited to this embodiment, and various improvements and modifications may be made without departing from the spirit of the present invention. For example, although the present embodiment has been described by taking an ITRON-compliant application program as an example, the present invention is not limited to such a real-time OS and can be widely applied to programs that operate in other methods.

[0098]

According to the present invention, it is possible to define information about a user-defined module and to easily register and manage information on hardware resources or software resources used by the user-defined module based on the information. It is possible to detect the validity of the usage position of the user-defined module, the defect regarding the operation of the user-defined module with respect to the resource, the problem of using a plurality of the same user-defined module, and the like early in the programming stage.

Therefore, by detecting inconsistency in programming early and reducing the return of the work process, it is possible to develop an efficient application system.

[Brief description of drawings]

FIG. 1 is a block diagram illustrating a configuration example of hardware resources of an information processing device according to an embodiment.

FIG. 2 is a block diagram showing a functional configuration example of an information processing apparatus according to the present embodiment.

FIG. 3 is an explanatory diagram illustrating a GUI screen configuration example of the information processing apparatus according to the present embodiment.

FIG. 4 is a flowchart showing a flow of developing an application system using the information processing apparatus according to the present embodiment.

FIG. 5 is a flowchart showing a processing flow of the information processing apparatus when registering information about a user-defined module in the present embodiment.

FIG. 6 is an explanatory diagram illustrating an example of a GUI screen configuration when registering information about a user-defined module in the present embodiment.

FIG. 7 is an explanatory diagram showing an example of a GUI screen configuration when registering information about a user-defined module in the present embodiment.

FIG. 8 is an explanatory diagram showing an example of a GUI screen configuration when registering information about a user-defined module in the present embodiment.

FIG. 9 is an explanatory diagram showing a GUI screen configuration example when registering information about a user-defined module in the present embodiment.

FIG. 10 is a flowchart showing the flow of processing of the information processing apparatus regarding checking the usage position of the user-defined module in the present embodiment.

FIG. 11 is a flowchart showing a flow of processing of the information processing device regarding checking of a system call in a user-defined module in the present embodiment.

FIG. 12 is a flowchart showing the flow of processing of the information processing apparatus regarding the usage number check of the user-defined module in the present embodiment.

FIG. 13 is an explanatory diagram showing a configuration example of a programming database that constitutes the information processing apparatus according to the present embodiment.

FIG. 14 is an explanatory diagram showing a configuration example of an environment definition information database which constitutes the information processing apparatus according to the present embodiment.

FIG. 15 is an explanatory diagram showing a configuration example of a user-defined module database that constitutes the information processing apparatus according to the present embodiment.

[Explanation of symbols]

1 ... Central processing unit, 2 ... RAM, 3 ... ROM, 4 ... Communication device, 5 ... Auxiliary storage device 6 ... Display device, 7 ... Input device, 8 ... Bus, 9 ... Output device, 10 ... Information processing device 11 ... Environment definition setting unit, 12 ... Environment definition information database, 13 ... User definition module registration support unit, 14 ...
User-defined module database, 15 ... Programming section, 16 ... Check section, 17 ... Display information generating section,
18 ... Programming database, 19 ... Execution object generation unit, 20 ... Execution object file, 21
... Template file generation unit, 22 ... Template file 23 ... User-defined module usage position check unit 24 ... User-defined module system call usage check unit 25 ... User-defined module usage number check unit 26 ... Other checking unit

Continued front page    (72) Inventor Naoshi Miyata             1st Komukai Toshiba-cho, Sachi-ku, Kawasaki-shi, Kanagawa             Ceremony Company Toshiba Microelectronics Sen             Inside F-term (reference) 5B042 HH08 HH11 NN04 NN09                 5B076 DB04 DD01 DD05 DD08 DE02                       DE08

Claims (12)

[Claims] 1. A program to be developed, an environment definition unit that defines environment definition data in an execution environment including hardware and software resources, and a virtual execution state of the development program in the execution environment based on the environment definition data. A check unit for verifying, a display information creating unit for creating display information for visually displaying the virtual execution state, a display device for displaying the display information to a user, and a display screen of the display device. And an execution object that outputs the development program in a form that can be executed under the execution environment, the interface unit being operated by the user on the display screen to change the virtual execution state visually displayed. An information processing apparatus for program development comprising a generation unit, wherein the development program is A user-defined module registration unit that defines information about a user-defined module to be used, and the user-defined module registration unit provides information on hardware resources or software resources used by the defined user-defined module to the environment definition unit. An information processing apparatus having a function of prompting a user to define the information processing apparatus. 2. The check unit includes a position check unit that verifies the validity of a position to be used when the development program uses the user-defined module, based on information about the user-defined module. The information processing apparatus according to claim 1, which is characterized in that. 3. The check unit, when the development program uses the user-defined module, detects a defect related to an operation of the user-defined module with respect to a resource under the execution environment based on information about the user-defined module. 3. The information processing apparatus according to claim 1, further comprising a resource operation check unit for detecting. 4. The check unit, when the development program uses the same user-defined module a plurality of times, detects the use a plurality of times and uses the resources under the execution environment to perform the user-defined module for each time. The information processing apparatus according to any one of claims 1 to 3, further comprising: a usage number check unit that prompts a user to exclusively control the usage of. 5. For a program to be developed, a step of defining environment definition data in an execution environment including hardware and software resources, a step of defining information on a user-defined module used by the development program, and programming data to be developed. Inputting, a step of verifying a virtual execution state of the development program in the execution environment based on the environment definition data, a step of creating display information for visually displaying the virtual execution state, A step of displaying the display information to a user, and a step of operating on the display screen an operation of changing the virtual execution state which is formed on the display screen of the display device and visually displayed. , Execute the development program under the execution environment An information processing method for program development, comprising: outputting information in a hardware form or software resource used by the defined user-defined module in the user-defined module definition step. An information processing method characterized in that the user is prompted to define in the environment definition data definition step. 6. The verifying step includes the step of verifying, when the development program uses the user-defined module, the validity of a position to be used based on information about the user-defined module. The information processing method according to claim 5. 7. The verifying step is based on information about the user-defined module for a defect related to an operation of the user-defined module for a resource under the execution environment when the development program uses the user-defined module. 7. The information processing method according to claim 5, further comprising a detecting step. 8. The verifying step detects, when the development program uses the same user-defined module a plurality of times, the use of the user-defined module a plurality of times and uses the resources under the execution environment to perform the user-defined module for each time. 8. The information processing method according to claim 5, further comprising a step of urging the user to exclusively control the use of. 9. An environment definition data definition function for defining environment definition data in an execution environment including hardware and software resources for a program to be developed, and a user definition module for defining information about a user definition module used by the development program. A definition function, a programming data input function for inputting programming data to be developed, a verification function for verifying the virtual execution state of the development program in the execution environment based on the environment definition data, and the virtual execution state visually A display information creating function of creating display information for displaying, a display function of displaying the display information to a user, the virtual execution state formed on the display screen of the display device and visually displayed. The user can change the operation on the display screen. An information processing program for causing an information processing apparatus to realize a user interface function operated by a user and an output function for outputting the development program in a form executable in the execution environment, wherein the user-defined module definition function An information processing program for prompting a user to define information on a hardware resource or a software resource used by the defined user-defined module in the environment definition data defining step. 10. The verification function, when the development program uses the user-defined module, includes a function of verifying the validity of a position to be used based on information about the user-defined module. The information processing program according to claim 9. 11. The verification function, when the development program uses the user-defined module, based on the information about the user-defined module, detects a defect related to an operation of the user-defined module with respect to a resource under the execution environment. The information processing program according to any one of claims 9 to 10, further comprising a detecting function. 12. The verification function, when the development program uses the same user-defined module a plurality of times, detects the use a plurality of times and uses a resource under the execution environment to perform a user-defined module for each time. The information processing program according to any one of claims 9 to 11, further comprising a function of prompting a user to exclusively control the use of the.