JPH0934698A - Software generating method and software developing and supporting method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To eliminate the necessity for a software developer to understanding specifications information on hardware in a specialized field different from that of the software developer and to reduce the influence of change in hardware specifications on the software developer. SOLUTION: A macro definition 108, a structured body definition 109 and a function definition 110 which are device driver programs 107 are generated (101) from macro definition information 122, external specifications information 104, hardware operating description information 105 and external specifications- operating description correspondence information 106 which are hardware component specifications information 103. As a result, the software defective due to the erroneous transmission of the hardware specifications to a software developer is eliminated. By reducing the work of the software developer according to the change of the hardware specifications, a software development period is shortened.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software development supporting method for supporting software development for controlling hardware by a microcomputer system, and more particularly to generating a device driver which is software for directly controlling hardware. It is about the method. The present invention also relates to a method for extracting a change transmission destination for software when there is a change in hardware specification information.

[0002]

2. Description of the Related Art Various techniques such as automatic generation of programs using a computer have been proposed in order to improve the efficiency of program development.

A method for generating a source program from a state transition diagram described as software specifications is shown in "Source Program Automatic Generation Device" of Japanese Patent Laid-Open No. 4-352029.

Also, as described in Information Processing Society of Japan, VOL.33 NO.11, Volume 333, in recent years, a movement to use a hardware description language as a language for supporting hardware design has become active. . Further, in a visual programming tool for a hardware description language, it is possible to perform programming by designating a connection relation of hardware constituent elements and performing behavioral description in the hardware constituent elements by a state transition diagram or the like. .

In Hitachi SEWB3 / FLOW,
Create a graphic that represents the process in the dataflow diagram, along with a graphic that represents the relationship to another dataflow diagram, and
While displaying the data flow diagram on the interactive terminal,
A method of displaying a data flow diagram related to a process on an interactive terminal by instructing a graphic representing the process with an input device is used.

Also, the IPSJ 48th (first half of 1994) national convention performances (5), pp181-182
"Design of application automatic / interactive execution support system by schematic process description" describes a method of graphically describing a process indicating a work guideline and executing the process according to this description. The feature of the application execution support system by this method is that the information of the process showing the work guideline is managed by dividing it into elements and diagrams. Elements are keywords organized according to the properties of the executable file.

The above-mentioned execution support system prepares information representing the connection between the nodes and the elements of the diagram and information representing the connection between the elements and the execution file, and when the application is executed, it follows the diagram. The process execution order is determined by using the above information, and the execution file having the connection with the process to be executed is executed by using the above information. This is a support system that allows a worker to interactively select an executable file to be executed when executing a process connected to a plurality of executable files.

[0008]

When developing software for controlling hardware by a microcomputer system, the processing contents of software for directly controlling hardware are determined based on the hardware configuration and interface specifications. It Therefore, it is necessary for the software developer to understand the hardware configuration and hardware specifications such as interfaces. Also,
If the hardware developer makes changes to the hardware configuration or the hardware interface, the software developer will change the software source code based on these changes.

The SEWB3 / FLOW described above is a method of handling a software configuration diagram created by a plurality of workers belonging to similar specialized fields. However, the relation between the configuration diagrams created by a plurality of workers having different specialized fields is related. It cannot be handled. That is, the above method cannot handle the relationship between the software configuration diagram and the hardware configuration diagram. Therefore, when developing software that is closely related to the hardware, it is difficult for the software developer to identify the changed part of the software unless the hardware developer directly communicates with the hardware developer when the hardware configuration is changed. There was a problem that was.

Further, the method described in "Design of application automatic / interactive execution support system by schematic process description" has the same problem as above.

An object of the present invention is to enable software development even if the software developer does not understand the specification information of hardware of different fields of expertise.
Another object of the present invention is to reduce the influence of a software developer on a change in specifications of hardware in different fields of expertise. Further, another object of the present invention is to support extraction of a change influence point between configuration diagrams created by a plurality of workers having different specialized fields.

[0012]

In order to achieve the object of the present invention, the following method is performed in the present invention. External specification information as required specification information for hardware, behavior description information that is hardware design information, correspondence information between external specification information and behavior description information, and macro definition information that indicates the meaning of numerical data in the specification information. Are described in accordance with a predetermined format, a software component for controlling hardware is generated.

Further, the generated software and information about it are held as software parts, and corresponding hardware information is held as hardware parts,
Further, by holding the link information indicating the correspondence between the software component and the hardware component and creating / changing the hardware configuration diagram using these component information,
Enables identification of software components that are affected by changes in hardware configuration

[0014]

According to the present invention, a software component for controlling hardware is generated only by the hardware developer describing the hardware specification information in a predetermined format. Further, according to the present invention, when the hardware developer creates / changes the hardware configuration diagram by using the hardware components, the link information indicates that the information in the software configuration diagram affected by the change in the hardware configuration is Can determine software components.

[0015]

Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a block diagram showing the configuration of a software development support system according to the present invention. The macro definition information 122, the external specification information 104, the hardware operation description information 105, and the external specification-operation description correspondence information 106 in the hardware component specification information 103 are information input from the user interface 102. The device driver program 107 is software generated by the device driver generation processing 101 based on the hardware component specification information 103, and includes a macro definition 108, a structure definition 109, and a function definition 110.

The device driver generation processing 101 is a macro definition generation processing 111 for generating a macro definition 108 from the macro definition information 122, a structure definition generation processing 114 for generating a structure definition 109 from the external specification information 104, and external specification information. 104, hardware behavior description information 105, and external specification-behavior description correspondence information 106 to function definition 110
And a function definition generation process 115 for generating The function definition generation processing 115 further includes the function return type generation processing 12
1, function name generation processing 116, function argument generation processing 117,
It includes an event execution process generation process 119 and a function footer generation process 120.

FIG. 2 is a block diagram showing the configuration of a general-purpose computer that operates the system to which the present invention is applied. In FIG. 2, a program of the system of the present invention is stored in the external storage device 205. When executing the system, the memory 201 is loaded with the system program from the external storage device 205. The CPU 203 has a memory 20.
Execute the system program read in 1. The user's instruction is input from the input device 204, and the display device 20
In item 2, confirmation items for the user are displayed.

The macro definition information 122 includes register address definition information 301, register bit configuration information 401, and data value information 501, as described later.

FIG. 3 shows an example of the data structure of the register address definition information 301 which is one of the macro definition information 122. Register address definition information 301 is register name 3
02 and register address 303. Specifically, "0x10" (305) is stored as the address of the register corresponding to the register name "StsReg" (304).

FIG. 4 shows an example of the data structure of the register bit configuration information 401 which is one of the macro definition information 122. The register bit configuration information 401 is information indicating the meaning of each bit group that configures the register, and the register name 40
9, name of meaning 402 indicated by each bit group, bit position 4
03, and a value 407 indicating the state of each bit group and a name 40
Consists of states 404 having eight. Specifically, bit “0” (406) of the register “StsReg” (410)
Represents the name “D0B” (405) and the value “0” (407) represents “NotBusy” (408).

FIG. 5 shows an example of the data structure of the data value information 501 which is one of the macro definition information 122. The data value information 501 is information indicating the correspondence between the name and value of the data set in the register, and includes a data name 502 and a value 503. Specifically, the data name “ReadDataCm
The value of “d” (504) is “0xC4” (505).

FIG. 6 shows an example of the data structure of the external specification information 106. The external specification information 106 includes a name 602 indicating a hardware component, an external function name 603, a function parameter 604 which is a parameter on the external specification for each function, and a result data 608. Function parameter 604
Is an identifier 605 indicating a name and a sentence 606 indicating meaning content.
And the number of bits 607 indicating the size of the parameter information. The result data 608 is data indicating the execution result returned for each function, and the identifier 6 indicating the name.
09, a sentence 610 indicating the meaning, and a bit number 611 indicating the size of the result data information. Specifically, the hardware component “FDC” (612) has the function “READ DA
TA ”(613), and parameters of this function are“ HD ”,“ US ”, and“ C ”. For example, the meaning of the parameter “C” (614) is “execution start sector ID information”.
(615) and the size is “8 bits” (616). In addition, “IC”, “SE”, and “EC” are returned as data as a result of operating the function “READ DATA”. For example, the meaning of the result data “EC” (617) is “Equipmnt Check” (618),
The size is "1 bit" (619).

FIG. 7 shows an example of the data structure of the state transition table 701 which is one form of the hardware operation description information 105. The horizontal axis 702 of the table 701 represents each state of the hardware, and the vertical axis 704 represents access (event) from the software to the hardware that may occur. Each state and each event are identified by numbers on both the horizontal and vertical axes. The inside 707 of the table represents the state number of the state transition destination when the event indicated by the vertical axis 704 occurs in the state of the horizontal axis 702. Specifically, if the "event (a)" (705) occurs when the state of the hardware component shown in this table is "state (1)" (703), the state of the hardware component is " State (2) ”(7
06).

FIG. 8 is an example of a data structure showing the contents 801 of each state in the state transition table 701 shown in FIG.
The content of each state shown on the horizontal axis in the state transition table 701 is represented by a number 803, a name 804, and a condition 805. The state number 803 is a serial number assigned to all states in the table 701. The state name 804 is a name representing the state. State condition 805 is the value of the register for that state. For example, the name of the state 806 of the state number (1) is “command reception” (807), “the value of the CB bit of StsReg (status register) is a value indicating NotBusy, and the D0B bit, D1B bit, D2B
The same applies to bits and D3B bits "(80
8) is the condition of the state.

FIG. 9 is an example of a data structure showing the content 901 of each event in the state transition table 701 shown in FIG. Events shown on the vertical axis in the table 701 are number 902, read / write type 903, and register name 904.
And setting / acquiring data 906. Event number 9
02 is a serial number assigned to all events in the table. The read / write type 903 identifies whether the event is a read access or a write access. For example, the event 907 of the event number (a) indicates “write access” (908). The register name 904 is an identifier indicating a register to be accessed. For example, the event 907 with the event number (a) indicates that “DataReg (data register)” (909) is accessed. Setting / acquisition data 906
Represents the data to be set for the indicated address in the case of write access, and the data to be acquired in the case of read access. For example, event 9 of event number (a)
In 07, "command data of function Read Data"
This indicates that (910) is set.

FIG. 10 shows the external specification-behavior description correspondence information 10
6 is an example of a data structure of a function-transition correspondence table 1001 which is one of the six. The function name 1002 is the same as that shown on the external specification information 104 shown in FIG. Transition route 10
03 is a state transition table 70 for executing each function 1002
In the case of 1004, for example, in order to execute the function "READ DATA", the event (a) is issued in the state (1), and the event (a) is transited to the state (2). It is indicated that it is sufficient to issue b), transition to state (3) and issue event (c), and transition to state (4) and issue event (d) (100
5). Below, a set of states and events is called a node in the transition path. For example, in 1005, "(1) (a)"
Is a node.

FIG. 11 shows external specification-behavior description correspondence information 10.
Parameter-register bit correspondence table 11 which is one of 6
It is an example of the data structure of 01. This table 1101 is the parameter 6 of each function shown in the external specification 104 shown in FIG.
4 shows the setting unit of 04 and the result data 608 to the actual hardware and the bit configuration at the time of mapping by the setting unit. Function name 1102 is external specification 10
4 is identical to that shown above. The parameter / result data type 1103 names the parameters and result data shown on the external specification 104 in units of setting on the actual hardware. For example, the function READ DAT
In A (1106), the parameter is divided into two and set, so a number is added to the parameter and parameter 1 (11
07) and parameter 2. Also, the function READ D
The result data of ATA is 1 because it is read in one batch.
And The parameter name / result data name 1104 is the same as the parameter and result data names 605 and 609 shown on the external specification 104. The position 1105 on the register is the function parameter 604 on the external specification 104.
And the result data 608 shows which bit is assigned as a setting unit for actual hardware. Specifically, the function READ DATA (1106)
Parameter "HD" (1108) is "Parameter 1"
“Bit 0x02” in (1107) (1109)
"1 bit" from (the number of bits of the external specification information 104 is 6
07) is set in actual hardware.

Next, FIG. 12, FIG. 13, FIG. 14, FIG.
The first embodiment will be described in detail with reference to FIGS.
The first embodiment uses the macro definition information 122, which is the hardware part specification information 103 input from the user interface, the external specification information 104, the hardware operation description information 105, and the external specification-operation description correspondence information 106. This is an example of generating a device driver program 107 that is software that directly controls hardware.

17, 18, and 19 are specific examples of the device driver program generated. From line (1) to line (25) in FIG. 17, macro definition 108 and line (2
From 6) to line (32) is the structure definition 109. 18 and 19 show the function definition 110.

FIG. 12 shows the device driver program 10.
7 is a flowchart showing a procedure of a process (111) for creating a macro definition 108 in FIG. First, a pair of a register name 302 and an address 303 is acquired from the register address information 301 (step 1201). Specifically, FIG.
From the register address information 301 shown in
tsReg ”(304) and address“ 0x10 ”(30
5) is obtained. Next, a macro name is created from the register name 302, and the macro definition statement is output to the file with the address 303 as a macro value in the format of "#define [macro name] [macro value]" (1202). Specifically, from the register name “StsReg” (304) to the macro name “S
"tsRegAdr" is created, and "#define StsRegAdr 0x1" is created in the file as shown in FIG.
0 ”(1701) is output.

Next, the pair of the meaning name 402 and the bit position 403 and the pair of the state value 407 and the state name 408 shown in the bit group are acquired from the register bit configuration information 401 (step 1203). Specifically, from the register bit configuration information 401 shown in FIG. 4, the meaning name “D0B” (40
5) and the bit position “0x01” (406) and the state value “0x00” (407) and the state name “NotBus”.
y ”(408) pairs are obtained.

Next, the semantic name 402 is used as a macro name and the bit position 403 is used as a macro value in the file "#defi".
ne [macro name] [macro value] ”(step 1204). Also, the state name 408 is used as a macro name, and the state value 407 is used as a macro value in the file "#de
The macro definition statement is output in the format of "fine [macro name] [macro value]" (step 1205). Specifically, the macro name “D0B” (405) and the macro value “0x01”
(406) pair and macro name “D0B_NotBus
From the pair of "y" (408) and the macro value "0x00" (407), "#defin" is added to the file as shown in FIG.
e D0B 0x01 ”(1702),“ #defin
e D0B_NotBusy 0x00 ”(1703)
Is output.

Next, from the data value information 501 to the data name 5
02 and the data value 503 are acquired (step 120).
6). Specifically, the data name “ReadDataCmd” 504 and the data value “0xC4” 505 are acquired from the data value information 501 shown in FIG. Next, data name 502
Is used as a macro name and the data value 503 is used as a macro value, and a macro definition statement is output to the file in the format of "#define [macro name] [macro value]" (step 1207).
Specifically, the macro name “ReadDataCmd” (5
04) and the macro value "0xC4" (505).
As shown in, the file has "#define Read
DataCmd 0xC4 "(1704) is output.

FIG. 13 shows the device driver program 10.
7 is a flowchart showing a procedure of a process (114) for creating a structure definition 109 in FIG. First, external specification information 1
Result data for each function No. 04 is acquired (step 1301). Specifically, the external specification information 10 shown in FIG.
The result data 608 is acquired from No. 4. Next, the function name 603
A structure tag name is generated from the structure, and a structure header part is generated (step 1302). Specifically, the function name "READ
DATA ”(613) to the tag name“ RsltRead
Data ", and as shown in FIG. 17, a structure header portion" struct RsltReadData {"
(1705) is generated.

Next, the members of the structure are generated (step 1303). The member is generated from each data of the result data 608. The name 609 of the result data is used as the member identifier, and the type is set according to the size of the register used. For example, if an 8-bit register is used, "char", 16
If the bit register is used, it is set to “short”, and if the 32-bit register is used, it is set to “long”. When the number of bits 611 of the result data 608 is larger than the register length in the external specification information 104, the array is used. Since the 8-bit register is used in this embodiment, the parameter type is "char". Since the number of bits 611 of the result data IC, SE, and EC (609) in the external specification information 104 is all within 8 bits, the array type is not used. Specifically, as shown in FIG. 17, as a member, "char I
C; char SE; charEC; "(170
6) is generated. After generating all the members of the structure,
A structure footer is generated and the structure definition is completed (step 1304). Specifically, as shown in FIG. 17, “};” (1707) is generated. The above processing is performed for each function.

FIG. 14, FIG. 15 and FIG. 16 are flowcharts showing the procedure of the function definition generation processing 115 for creating the function definition 110 in the device driver program 107. As long as there is an external function, the following processing is repeated (step 1401). First, one function name is acquired from the external specification information 104 (step 1402). For example, the function name READ DATA (613) is acquired. Next, the transition path 1003 for the acquired function name 1002
From the function-transition correspondence table 1001 (step 1
403). For example, the function name READ DATA (10
As a transition route for 04), "(1) (a)-(2)
(B)-(3) (c)-(4) (d) "(1005) is acquired.

Next, processing for generating the return type of the function to be generated is performed (121). First, the status numbers in the acquired transition path are acquired, and it is confirmed from the hardware operation description whether or not there is an interrupt status condition for these statuses (step 1405). When there is an interrupt in the state condition in the transition path, the return type of the generation function is set to "voi
d ”(step 1407). If there is no interruption in the state condition in the transition path, a tag name is generated from the function name and set as a structure type (step 1406). For example,
For the function name "READ DATA", "sru
ct RsltReadData {”. In the example, “(1), (2), (3), and (4)” are the state numbers in the transition path, in which the state condition 8 of the state (4) is 8
Since 09 is an interrupt, the return type is "void"
(1801).

Next, the name of the driver function to be generated is generated (116). The function name is mechanically determined from the function name. If there is an interrupt in the state condition in the transition path, the driver function for one function is composed of a plurality of functions, so that numbers are added in the order in which they are generated so that names do not overlap (step 1408). For example, in the example, since it is the first generation function for the function READ DATA, the function name is “readData1” (180
2).

Next, function arguments are generated (117).
If there is an interrupt in the state condition in the transition path (step 1409), the event setting data (906) of the transition path before the interrupted node is acquired from the state transition table 901 (step 1411). Figure 11 shows the acquired data.
Parameter name / result data name 1 in the matching column of function name 1102, parameter / result data type 1103
The identifier described in 104 is used as an argument of the generation function (step 1412). The type of argument depends on the bit length of the register used, and if an 8-bit register is used, "char",
"Short" if using 16-bit register, 32
If a bit register is used, it is set to "long". If the number of bits 607 of the parameter 604 is larger than the register length in the external specification information 104, an array is used (step 1413).

In this embodiment, first, the transition path before the node having the interrupt is "(1) (a)-(2)".
(B)-(3) (c) ”, and the setting data 906 for the event in this transition path is“ READ DATA.
Command ”(910),“ READ DATA parameter 1 ”(911), and“ READ DATA parameter 2 ”(912). The parameter-register bit correspondence table 1101 is searched based on this, and the function name 1102
Is “READ DATA” and the parameter / result data type 1103 is “Parameter 1” or “Parameter 2”, the identifier HD (1108), US (111) described in the parameter name / result data name 1104
0) and C (1111) are used as parameters of the generation function.
In this embodiment, since the 8-bit register is used, the parameter type is "char". Since the number of bits of parameters HD, US, and C are all within 8 bits in the external specification information, the array type is not used. Therefore, as a function argument, "(char HD, char US, c
Har C) ”(1803).

Next, as shown in FIG. 15, a program corresponding to the event action for each node in the transition path is generated (119). First, one node is acquired in order from the beginning of the transition route (step 1501). If the state of the acquired state number of the node is searched from the state transition table 701, the state condition is acquired, and the state condition is an interrupt and it is not the first node after function header generation (step 1502), the function The definition is finished (step 1503). In this embodiment, first, the node “(1) (a)” is acquired. Since the state number of this node is (1), the state condition 808 of the state (1) of the state transition table 701 is acquired. The state condition in this case is "St
sReg (CB) = NotBusy, StsReg (D
0B) = NotBusy, StsReg (D1B) = N
otBusy, StsReg (D2B) = NotBus
y, StsReg (D3B) = NotBusy ”.

It is determined whether the node is at the head of the route and the status condition for the node is an interrupt (step 1504).
If the state condition is not an interrupt, first, as the generation of the state condition confirmation waiting process, the loop statement start portion “while” is generated.
(! (”(1805) is generated (step 150
5). Next, the acquired state condition is mechanically converted to generate a state condition check sentence (step 1508). For example, the state condition “StsReg (CB) = NotBus”
"((StsReg & C
B_NotBusy) = CB_NotBus
y)) ”(1806). If there are multiple status conditions, "&&" is placed between the status check statements.
Insert (1807). When the state check sentences for all the state conditions are generated (step 1506), finally the loop sentence end portion ")) {}" (1808) is generated (step 1507).

Next, as shown in FIG. 16, as the generation of the program corresponding to the event execution processing, the event number for the node is acquired and the event in the state transition table is acquired. In this embodiment, the node “(1)
Since the event number of “(a)” is (a), the event (a) 907 of the state transition table 701 is acquired (step 1609). Next, when the R / W type 903 of the event is write (step 1601), a parameter composition sentence and an event execution sentence are generated.

The parameter synthesizing statement is a program corresponding to the process of synthesizing the argument of the generating function according to the configuration of the setting register of the actual hardware. First, paying attention to the data 906 corresponding to the event in the state transition table, the function name and parameter-register bit correspondence table 1101 shown in the data
The function name 1102 of is searched for. If there is no matching function name, nothing is generated. If there is a matching function name, the event data 906 of the state transition table
The command / parameter type shown in is acquired and the column acquired in the parameter-register bit correspondence table 1101 is searched. That is, the matching columns of the function name 1102 and the parameter / result data type 1103 are searched (step 1603). If there is no matching column, nothing is generated. If there is a matching column, a parameter composite sentence is generated from the parameter / result data name of that column and the position on the register (step 1604). For example, event (b) 913
If the function name is READ DATA (914) and the parameter / result data type is parameter 1 (915), the function name matches the parameter / result data type in the parameter-register bit correspondence table, and is acquired. Parameter / result data name, position on register is HD
(1108), 0x02 (1109), and US (1
110) and 0x00 (1112). For these, mechanically “prm = prm | (HD <<0x02);”
(1809) and “prm = prm | (US << 0x0
0); ”(1810) is generated. The above process is repeated as long as there is data to be written in the parameter-register bit correspondence table (step 160).
3).

Next, when the event execution statement is generated, the parameter "prm" synthesized by using "OUTPUT ()" prepared in advance as an output function and the address item in the event column of the state transition table are described. DataReg, "OUTPUT (prm, DataReg);" (1
811) is generated (step 1605).

Next, when the R / W type 903 of the event is read (step 1601), an event execution statement and a parameter division statement are generated as event execution processing. First, pr is a temporary variable using "INPUT ()" prepared in advance as an input / output function as the event execution statement.
m and the register name described in the register name 904 of the event of the state transition table are generated in the format of "prm = INPUT ([register name]);" (step 1602).
Specifically, in the event (d) 916, since the R / W type 903 is read, the register name 904 "Da
"prm = INPUT (DataR
(eg); ”(1901) is generated.

Next, a parameter division statement is generated. The parameter division statement is a statement for dividing the acquired register value into the temporary variable “prm” and assigning it to the return value according to the content. First, paying attention to the event data 906 of the state transition table, a search is made for a match between the function name shown in the data and the function name 1102 of the parameter-register bit correspondence table 1101. The obtained command / parameter type is further searched in the column in which the function name of the parameter-register bit correspondence table 1101 matches. That is, the matching columns of the function name 1102 and the parameter / result data type 1103 are searched. A parameter division statement is generated from the parameter / result data name in the matched column and the position on the register (step 1608).

Specifically, in event (d) 916, function name READ DATA (917), parameter /
When the result data type is result data 1 (918), the parameter / result data name acquired in the parameter-register bit correspondence table 1101 and the position on the register are ICs.
(1113), 0x02 (1116), SE (111
4), 0x01 (1117), EC (1115), 0x
00 (1118). Further, for these, the number of bits of each result data is acquired from the external specifications and mask data is created. For example, if the number of bits is 1, 0x01,
If the number of bits is 2, data for masking bits corresponding to the number of bits is created like 0x03. By using these data and the return value type variable “rtn” created in advance, mechanically “rtn.IC = (pr
m >> 0x02) &0x03;"(1902)and" rt
n. SE = (prm >> 0x01) &0x01;"(1
903) and “rtn.EC = (prm >> 0x00) &
A parameter division sentence "0x01;" (1904) is generated.

Parameter-register bit correspondence table
As long as there is data to be read, the above processing is repeated (step 1607).

When the state condition generation process and the event generation process are completed, the node of interest on the state path is advanced by one and the same process is performed (step 1501). If the state condition of the node of interest is an interrupt (step 1502),
"}" (1812) is generated and the function definition is once ended (step 1503). Then, with the node currently focused on as the first node, the processes from the return type generation (121) are similarly performed on the remaining transition paths. If there is no target node (step 1501), "re
"turn rtn;" (1905) and "}" (190
6) is generated and the function definition is completed (step 151).
0). These operations are performed for all the functions according to the external specifications, and when there are no functions, the process ends (step 1401).

According to the above example, the software developer can operate the hardware as if calling one function without knowing the details of the hardware specifications. Further, the software generated in this example can be used as a boot program for testing hardware.

In the second embodiment, the device driver program 107 generated in the device driver generation processing 101 of the first embodiment is stored as a software component in a form associated with the hardware component, and the already registered hardware component is stored. This is an embodiment in which the corresponding software component can be easily used when using the. In addition, a link is placed between the hardware configuration diagram showing the hardware connection relationship and the software configuration diagram showing the software calling relationship, and when the hardware configuration is changed, the affected parts on the software configuration diagram Is an example of displaying. The second embodiment will be described in detail.

FIG. 20 is a block diagram showing the configuration of the software development support system in the second embodiment.
Hardware component specification information 103, device driver program 107, and device driver generation processing 101
Is the one shown in the first embodiment. In the second embodiment, the identifier indicating the device driver program generated by the device driver generation processing 101 and the identifier indicating the corresponding hardware component are held as the component information 2010, and the processes 2001, 2007, and 20
03 is added.

That is, the hardware configuration diagram information 2009 is created / changed / displayed based on the input from the user interface 102, the change information 2002 based on the component information 2010, and the software component and the hardware component Hardware configuration diagram information creation / change / display processing 2001 for creating link information 2006 indicating a relationship 2001
And a software source code 2011 including the device driver 107 to extract a function / procedure call relationship, and create software configuration diagram information 2004 indicating the call relationship as one of the software specification information 2005. Creation process 20
07, the change information 2002 of the hardware configuration diagram, the link information 2006 indicating the relationship between the hardware component and the software component, and the software configuration diagram information 2004 based on the change of the hardware configuration diagram to the software configuration diagram. Change influence point display processing 200 for displaying points
3 is added.

FIG. 21 shows an example of the data structure of the hardware component information 2010. The component information 2010 includes an identifier 2101 that identifies a hardware component and an identifier 2102 that identifies a device driver program that is a related software component corresponding to a hardware component.
These pieces of information are stored when the device driver 107, which is a software component, is generated from the hardware component specification information 103 (101).

FIG. 22 shows an example of the data structure of change information 2002 for the hardware block diagram. Change information 200
2 is an identifier 2 that identifies the hardware component to be changed
201 and the type 2202 of changes made to the parts. The change type 2202 includes “delete / insert / move”. However, the "movement" shown here is a change in the connection relationship. For example, FIG. 22 shows that the hardware component “FDC” (2203) has been deleted (2204) from the hardware configuration diagram.

FIG. 23 is link information 2006 showing the related software component 2302 corresponding to the hardware component 2301 used in the hardware configuration diagram. These pieces of information are acquired from the parts information 2010.

FIG. 24 shows the hardware configuration diagram information 2009
It is an example of the data structure of. Hardware configuration diagram information 20
Reference numeral 09 denotes a display position 2 which is display data necessary for displaying a hardware configuration diagram, corresponding to an identifier 2401 which identifies a hardware component which is a hardware component.
402, a name 2403, and connection data 2405 are stored.

FIG. 25 shows software block diagram information 2004.
It is an example of the data structure of. Software configuration diagram information 20
Reference numeral 04 denotes a display position 2502 which is display data necessary for displaying a software configuration diagram, a caller 2503, and a callee 250 corresponding to an identifier 2501 which identifies a function / procedure which is a software component.
4 is stored. One or a plurality of descriptions can be made for each of the call source and call destination. FIG. 26 shows the hardware configuration diagram creation / change / display processing 20.
It is a flowchart showing the processing procedure of 01. FIG. 27 is a flowchart showing the processing procedure of the software block diagram information creation processing 2007. FIG. 28 is a flowchart showing the processing procedure of the software block diagram / change spread point display processing 2003. 29 is an example of a screen displaying a hardware configuration diagram in the hardware configuration diagram display field 2904, FIG. 30 is an example of a screen displaying a software configuration diagram, and 3003 is a change spread for displaying hardware configuration change information. A location display column is provided.

First, referring to FIG. 26, the hardware configuration diagram creation / change / display processing 2001 will be described. In FIG. 26, first, it is checked whether or not an instruction to create / change the hardware block diagram has been received from the input device (step 260).
1). Specifically, Quit indicating the end in FIG.
If the button 2901 is pressed, it means that the creation / modification is completed. If there is an instruction to end the creation / modification (step 2601), the information processing apparatus ends the hardware configuration diagram creation / modification processing 2001, and proceeds to execution of the modification spread portion display processing 2003.

When there is no instruction to end the creation / modification (step 2601), an identifier for specifying the designated hardware component is received via the input device (step 26).
02). Specifically, on the hardware configuration diagram input screen in the example of FIG. 29, an icon 2902 “DMAC” representing a component for performing DMA control in the hardware component display column 2903 or a hardware configuration diagram display column 2904.
"DMAC" icon 2 representing similar parts in
When 905 is instructed via the input device, the hardware component ID “DMAC” (210
1) is acquired.

Next, in response to the instruction to create / change the hardware configuration diagram input from the input device (step 2603), the creation / change data is received from the input device (step 2604).

Next, the hardware configuration diagram information 2009 is corrected based on the received creation / change data, and the contents of the change are stored in the change information 2002 (step 260).
5). Specifically, when a change is made in the hardware configuration diagram (FIG. 29) such that the hardware component “DMAC” is deleted, the information processing device corrects the hardware configuration information and creates change information. ,save.

Next, all the corresponding software components are searched using the identifier for identifying the hardware component and the inter-component link information (step 2606). Then, the presence / absence of the change end instruction is confirmed again (step 2601).

Next, the software block diagram information creating process 2007 will be described with reference to FIG. In FIG. 27, first, the source code of the software is read, and the calling relationships of functions / procedures and the like are analyzed (step 270).
1). Display information such as a display position is created based on the analyzed calling relationship and stored in the software configuration diagram information 2004 (step 2702). Specifically, the source is a software component ID (2501) indicating a function name / procedure name as shown in FIG. 25, a caller software component ID (2503), and a callee software component ID (2504) corresponding thereto. The display position information 2502 of each software component is extracted from the code, and based on the overall calling relationship, the display position information 2502 is created and stored in the software configuration diagram information 2004.

Next, the software configuration diagram / change spread point display processing 2003 will be described with reference to FIG. In FIG. 28, first, if there is data in the change information 2002 (step 2801), one piece of data is taken out from the change information 2002, and an identifier 220 for identifying a hardware constituent element.
Get 1 Then, using this identifier 2201 and the link information 2006, all the identifiers that identify the software component corresponding to the hardware component are searched (step 2802). Specifically, change information 2002
From FIG. 22, the hardware component ID “FDC”
(2203) is acquired and the link information 2006 (FIG. 23)
From "readData" (2303) as the software component ID corresponding to "FDC" (2303)
Search for "readDeletedData" or the like.

Next, the display data (2502, 2503, 2504) of the software component is acquired from the software configuration diagram information 2004 using the identifier (2501) for identifying the retrieved software component (step 2804). Specifically, the display information is acquired from the software configuration diagram information 2004 (FIG. 25) using the software configuration element ID “readData” (2506).

Then, the presence / absence of data in the change information is checked again. When no data remains in the change information 2002 (step 2801), the change information 2002 and the software configuration diagram information 2004 are used to change the software configuration diagram and the change. The spillover point is displayed on the dialogue terminal (step 280).
3). Specifically, as shown in FIG. 30, software components "readData" (3001) and "rea" are stored.
"dId" (3002) is collaboratively displayed with a thick line,
It indicates that these are changes. Further, a dialog box (3003) displaying the contents shown in the change information 2002 (FIG. 22) is displayed as change guidance.

According to the second embodiment, when the hardware developer changes the hardware configuration diagram by deleting / inserting / moving a hardware component, the software developer determines the software configuration affected by the change. Since the element can be easily specified and the change contents of the hardware configuration can be easily known, it is possible to reduce the load of the software correction work accompanying it.

[0070]

[Effect of the Invention] By using the hardware specification information described by the hardware developer to generate the part of the software that is closely related to the hardware, the software developer can obtain the specification information of the hardware in different specialized fields. No need to understand. Further, since the software is automatically changed with the change of the hardware interface, the change of the hardware interface does not affect the software developer.

Further, when the hardware configuration is changed, the software developer does not have to work with the hardware developer to clarify the software component affected by the change. Know the software components affected by the change. as a result,
Software development time is shortened.

[Brief description of drawings]

FIG. 1 is a diagram showing a configuration of a system according to a first embodiment of the present invention.

FIG. 2 is a configuration of a computer for operating the system of the present invention.

FIG. 3 is a diagram showing an example of register address definition information.

FIG. 4 is a diagram showing an example of register bit configuration information.

FIG. 5 is a diagram showing an example of data value information.

FIG. 6 is a diagram showing an example of external specification information.

FIG. 7 is a diagram showing an example of a state transition table showing hardware operation description information.

FIG. 8 is a diagram showing an example of state contents in a state transition table.

FIG. 9 is a diagram showing an example of event contents in a state transition table.

FIG. 10 is a diagram showing an example of a function-transition correspondence table.

FIG. 11 is a diagram showing an example of a parameter-register bit correspondence table.

FIG. 12 is a diagram showing a flow of macro definition table creation processing.

FIG. 13 is a diagram showing a flow of a structure definition creating process.

FIG. 14 is a first diagram illustrating a flow of a function definition creating process.

FIG. 15 is a second diagram showing the flow of a function definition creating process.

FIG. 16 is a third diagram illustrating the flow of the function definition creating process.

FIG. 17 is a first diagram showing the generated software.

FIG. 18 is a second diagram showing the generated software.

FIG. 19 is a third diagram showing the generated software.

FIG. 20 is a diagram showing a configuration of a system in a second exemplary embodiment of the present invention.

FIG. 21 is a diagram showing an example of hardware component information.

FIG. 22 is a diagram showing an example of change information of a hardware configuration diagram.

FIG. 23 is a diagram illustrating an example of link information of a hardware configuration diagram.

FIG. 24 is a diagram illustrating an example of hardware configuration diagram information.

FIG. 25 is a diagram showing an example of software configuration diagram information.

FIG. 26 is a diagram showing a flow of hardware configuration diagram creation / change / display processing.

FIG. 27 is a diagram showing a flow of software configuration diagram information creation processing.

FIG. 28 is a diagram showing a flow of software configuration diagram / change spread point display processing.

FIG. 29 is a diagram showing an example of a hardware configuration diagram input / change screen.

FIG. 30 is a diagram showing an example of a screen displaying a software configuration diagram / change spread.

[Explanation of symbols]

101 ... Device driver generation processing, 103 ... Hardware component specification information, 122 ... Macro definition information, 104 ... External specification information, 105 ... Hardware operation description information, 106 ...
External specification-behavior description correspondence information, 107 ... Device driver, 108 ... Macro definition, 109 ... Structure definition, 1
10 ... Function definition

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Jun Shimabukuro 1099, Ozenji, Aso-ku, Kawasaki-shi, Kanagawa Inside the Hitachi, Ltd. Systems Development Laboratory Hitachi Systems Development Laboratory

Claims (6)

[Claims] 1. A software generating method for generating software for controlling hardware by a microcomputer system from hardware specification information. 2. In the software generation method, the process of generating software for controlling the hardware from the hardware specification information is performed from macro definition information indicating the meaning of numerical data in the hardware specification information. A step of generating a definition, a step of generating a structure definition from external specification information that is a hardware required specification, and a hardware operation description information that describes the macro definition information, the external specification information, and the operation specification of the hardware And a step of generating a function definition from external specification-behavior description correspondence information describing a correspondence relationship between the external specification information and the hardware behavioral description information. Method. 3. The software generation method, in the process of generating the function definition, generating a return type of a function from the external specification information, the hardware behavioral description information, and the external specification-behavioral description correspondence information. A step of generating a function name from the external specification information; a step of generating a function argument from the external specification information, the hardware behavioral description information, and the external specification-behavioral description correspondence information; Generating an execution statement corresponding to a hardware access process from the external specification information, the hardware operation description information, and the external specification-operation description correspondence information, the hardware operation description information, and the external specification-operation Generating a function conclusion sentence from the description correspondence information. Software generating method of 2, wherein. 4. The software generation method according to claim 1, wherein the software for activating hardware for use in a hardware test is generated. 5. A software development support method for supporting software development for controlling hardware by a microcomputer system, storing a hardware configuration diagram in which hardware components representing hardware parts are combined, Storing a software configuration diagram in which software components that represent software parts are combined, a first identifier that identifies a hardware component in the hardware configuration diagram, and a software component in the software configuration diagram Storing link information indicating correspondence with the second identifier, and obtaining the first identifier corresponding to a hardware component in the hardware configuration diagram indicated via an input device, The first obtained in the step Identifier and, from said link information, software development support method characterized by comprising the step of searching said second identifier. 6. The software development support method, wherein the link information indicating the correspondence between the first identifier and the second identifier is generated from the hardware specification information to generate software for controlling the hardware. The software development support method according to claim 5, wherein the method is generated in the step of performing.