Patent Description:
The development of information and communication technology (ICT) has been remarkable in recent years, and devices connected to a network, such as the Internet, are not limited to information processing devices, such as conventional personal computers or smartphones, and are spreading to various things. Such a technology trend is called "IoT (Internet of Things)", and various technologies and services have been proposed and put into practical use. In the future, a world is envisioned in which billions of people on Earth and tens of billions or trillions of devices are connected at the same time. In order to realize such a networked world, it is necessary to provide a solution that is simpler, safer, and more freely connected.

Even in a device used in IoT (also referred to as an "edge device"), various programs are executed using a semiconductor device. Regarding the relationship between such a semiconductor device and software, for example, <CIT> discloses a mechanism for sharing software between a plurality of specifications, in which designated terminal pins are different, by using the same ECU in terms of hardware.

"<NPL>et al, describes a way to program and configure the operation of each built-in peripheral of an IoT platform using a web-based software framework. <CIT> describes a single application source code that may be targeted on demand for a variety of execution platforms without knowledge of the execution platform(s) on which the application will ultimately be implemented.

The progress of semiconductor devices that make up edge devices is also remarkable. With the improvement of such semiconductor devices, the specifications may be changed, and problems such as how to maintain and manage the software may arise.

The mechanism disclosed in Patent Document <NUM> described above is intended to realize a plurality of functions having different specifications with single software by using the same hardware, but does not solve sharing the same software between a plurality of semiconductor devices having different specifications.

One object of the present disclosure is to provide a solution that enables software to be shared between controllers using semiconductor devices having different specifications.

According to an aspect of the present disclosure, there is provided a software development device according to claim <NUM>. This generates an execution code executed by a controller having one or more pads from a source code. The software development device includes: an analysis means for analyzing the source code to extract a designation for the one or more pads; and a generation means for generating an execution code including a code corresponding to the extracted designation for the pads with reference to hardware of a target controller.

The pad is a physical interface between the controller and arbitrary hardware.

The hardware information includes information for specifying a connection relationship between a pin of a semiconductor device mounted on the controller and the pad.

The designation for the one or more pads may include identification information for specifying a pad to be used among the one or more pads.

The generation means may generate the execution code by using a code unique to the target controller instead of a library module commonly used between controllers.

According to other forms of the present disclosure, there is provided a software development method for generating an execution code executed by a controller having one or more pads from a source code according to claim <NUM> and a software development program for generating an execution code executed by a controller having one or more pads from a source code according to claim <NUM>.

According to the present disclosure, it is possible to share software between controllers using semiconductor devices having different specifications.

An embodiment according to the present disclosure will be described in detail with reference to the diagrams. In addition, the same or corresponding portions in the diagrams are denoted by the same reference numerals, and the description thereof will not be repeated.

In the following description, as a typical example, a case where a software development device <NUM> according to the present embodiment is applied to an IoT system will be described. However, the present disclosure can be applied to any system and any controller without being limited to the IoT system.

First, the overall configuration of an IoT system <NUM> including the software development device <NUM> according to the present embodiment and an edge device <NUM> will be described.

<FIG> is a schematic diagram showing an example of the overall configuration of the IoT system <NUM> according to the present embodiment. Referring to <FIG>, in the IoT system <NUM>, typically, a program (execution code) executed by the edge device <NUM> is generated by the software development device <NUM>. The generated program is transferred from the software development device <NUM> to a controller <NUM> included in the edge device <NUM>.

An integrated development environment (IDE) is provided for the software development device <NUM>, so that the user can create an arbitrary program in the integrated development environment.

The edge device <NUM> may be any device, but typically, factory facilities, various devices in the home, social infrastructure equipment, movable bodies such as vehicles, arbitrary portable devices, and the like are assumed. More specifically, the edge device <NUM> includes the controller <NUM> including a processor and one or more hardware devices <NUM>. The hardware device <NUM> includes any sensor, actuator, communication device, and the like that make up the edge device <NUM>.

The controller <NUM> and the hardware device <NUM> are electrically connected to each other by wiring (hardwired).

As a typical processing procedure in the IoT system <NUM> shown in <FIG>, first, the user creates a source code by using the software development device <NUM> ((<NUM>) source code creation). Then, the created source code is compiled in the software development device <NUM> to generate an execution code ((<NUM>) execution code generation). The generated execution code is transferred to the controller <NUM> of the edge device <NUM> ((<NUM>) execution code transfer). The transferred execution code is executed by the controller <NUM> ((<NUM>) execution of execution code). Any signal may be transmitted to and received from the hardware device <NUM> by executing the execution code on the controller <NUM>.

In this manner, the software development device <NUM> generates an execution code executed by the controller <NUM> from the source code.

Next, a hardware configuration example of a device included in the IoT system <NUM> according to the present embodiment will be described.

The software development device <NUM> is typically realized by a general-purpose computer.

<FIG> is a schematic diagram showing a hardware configuration example of the software development device <NUM> according to the present embodiment. Referring to <FIG>, the software development device <NUM> includes a processor <NUM>, a main memory <NUM>, an input unit <NUM>, a display <NUM>, a hard disk <NUM>, and a communication interface <NUM> as main components. These components are connected to each other through an internal bus <NUM>.

The processor <NUM> may be, for example, a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit). A plurality of processors <NUM> may be disposed, or the processor <NUM> having a plurality of cores may be adopted.

The main memory <NUM> is a volatile storage device, such as a DRAM (Dynamic Random Access Memory) or a SRAM (Static Random Access Memory). The hard disk <NUM> holds various programs executed by the processor <NUM> or various kinds of data. In addition, instead of the hard disk <NUM>, a non-volatile storage device such as an SSD (Solid State Drive) or a flash memory may be adopted. Among the programs stored in the hard disk <NUM>, a designated program is loaded to the main memory <NUM>, and the processor <NUM> sequentially executes computer-readable instructions included in the program loaded to the main memory <NUM> to realize various functions described later.

Typically, the hard disk <NUM> stores a source code <NUM> arbitrarily created by the user, a software development program <NUM> for realizing an integrated development environment, and an execution code <NUM> generated from the source code <NUM>. The software development program <NUM> generates the execution code <NUM> from the source code <NUM> arbitrarily created by the user, and includes a module that provides a program development environment.

The input unit <NUM> receives an input operation of the user who operates the software development device <NUM>. The input unit <NUM> may be, for example, a keyboard, a mouse, a touch panel disposed on a display device, or an operation button disposed on the housing of the software development device <NUM>.

The display <NUM> displays the processing result of the processor <NUM> and the like. The display <NUM> may be, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display.

The communication interface <NUM> is in charge of data exchange with the controller <NUM>. Examples of the communication interface <NUM> include wired connection terminals, such as serial ports including a USB (Universal Serial Bus) port and an IEEE1394 and a legacy parallel port. Alternatively, the communication interface <NUM> may include an Ethernet (registered trademark) port.

In addition, the entirety or part of the software development device <NUM> may be realized by using a hardwired circuit such as an ASIC (Application Specific Integrated Circuit) in which a circuit corresponding to computer-readable instructions is provided. In addition, the entirety or part of the software development device <NUM> may be realized by using a circuit corresponding to computer-readable instructions on an FPGA (field-programmable gate array). In addition, the entirety or part of the software development device <NUM> may be realized by appropriately combining the processor <NUM>, a main memory, an ASIC, an FPGA, and the like.

The software development device <NUM> may further include a component for reading the stored program or the like from the non-transitory media that stores the software development program <NUM> including computer-readable instructions. The media may be, for example, an optical medium, such as a DVD (Digital Versatile Disc), or a semiconductor medium, such as a USB memory.

In addition, the software development program <NUM> may not only be installed on the software development device <NUM> through the media, but also be provided from a distribution server on the network.

The controller <NUM> may be realized by using a general-purpose computer, or may be realized by using a semiconductor substrate including components necessary for realizing processing.

<FIG> is a schematic diagram showing a hardware configuration example of the controller <NUM> according to the present embodiment. Referring to <FIG>, the controller <NUM> includes, as main components, an arithmetic processing unit <NUM>, a wireless communication module <NUM>, a USB controller <NUM>, a communication controller <NUM>, and a microcomputer <NUM> including an IO driver electrically connected to one or more pads <NUM>.

The arithmetic processing unit <NUM> is a calculation unit that executes a program, and includes a processor <NUM>, a main memory <NUM>, and a flash memory <NUM> as main components. The processor <NUM> is, for example, a CPU or a GPU. A plurality of processors <NUM> may be disposed, or the processor <NUM> having a plurality of cores may be adopted. The main memory <NUM> is a volatile storage device, such as a DRAM or an SRAM. The flash memory <NUM> is a non-volatile storage device that holds a program executed by the processor <NUM> or necessary data. Among the programs stored in the flash memory <NUM>, a designated program is loaded to the main memory <NUM> and executed by the processor <NUM> to realize various functions.

The wireless communication module <NUM> is in charge of wireless data exchange with any other device. The wireless communication module <NUM> may include processing circuits and antennas for wireless communication with devices, routers, mobile base stations, and the like. The wireless communication supported by the wireless communication module <NUM> may be any of Wi-Fi (registered trademark), Bluetooth (registered trademark), ZigBee (registered trademark), LPWA (Low Power Wide Area), GSM (registered trademark), W-CDMA, CDMA200, LTE (Long Term Evolution), and 5th generation mobile communication system (<NUM>), for example.

The USB controller <NUM> is in charge of data exchange with the software development device <NUM>. The communication controller <NUM> is in charge of wired data exchange with any other device. The communication controller <NUM> may be compatible with known data exchange methods, such as serial communication, parallel communication, and GPIO (General-purpose input/output).

The microcomputer <NUM> is in charge of transmitting and receiving electrical signals to and from an arbitrary device electrically connected through the pad <NUM>. The microcomputer <NUM> outputs an electrical signal according to a command from the arithmetic processing unit <NUM>. In addition, the microcomputer <NUM> detects an electrical signal given through the pad <NUM> and outputs the detection result to the arithmetic processing unit <NUM>. More specifically, the microcomputer <NUM> is configured to include a signal generation circuit, a signal detection circuit, a buffer circuit, and the like.

The pad <NUM> has a conductor disposed so as to be exposed, and corresponds to a physical interface between the controller <NUM> and various kinds of hardware.

The controller <NUM> may be driven by electric power from a battery (not shown).

Next, a problem to be solved by the software development device <NUM> according to the present embodiment will be described.

<FIG> is a diagram for describing the microcomputer <NUM> used in the controller <NUM> connected to the software development device <NUM> according to the present embodiment. <FIG> exemplify a case where a microcomputer 218A is adopted and a case where a microcomputer 218B is adopted, respectively.

As shown in <FIG>, even if the microcomputer <NUM> provides substantially the same function, the specifications (size or the number of pins) of the microcomputer <NUM> itself and the pin positions to which the respective functions are assigned may be different.

For example, in the microcomputer 218A shown in <FIG>, pins of numbers "<NUM>", "<NUM>", "<NUM>", "<NUM>", "<NUM>", and "<NUM>" are used as terminals for I/O. In addition, in the microcomputer 218B shown in <FIG>, pins of numbers "<NUM>", "<NUM>", "<NUM>", "<NUM>", "<NUM>", and "<NUM>" are used as terminals for I/O.

<FIG> is a diagram for describing the pad <NUM> provided in the controller <NUM> connected to the software development device <NUM> according to the present embodiment. As shown in <FIG>, the terminal of the microcomputer <NUM> and the pad <NUM> are electrically connected to each other. Any combination is possible depending on the positional relationship between the terminal of the microcomputer <NUM> and the pad <NUM>.

<FIG> shows a configuration example using the microcomputer 218A shown in <FIG>. In this configuration example, the pads <NUM> of numbers "<NUM>" to "<NUM>" are electrically connected to the pins of numbers "<NUM>", "<NUM>", "<NUM>", "<NUM>", "<NUM>", and "<NUM>", respectively. In addition, <FIG> shows a configuration example using the microcomputer 218B shown in <FIG>. In this configuration example, the pads <NUM> of numbers "<NUM>" to "<NUM>" are electrically connected to the pins of numbers "<NUM>", "<NUM>", "<NUM>", "<NUM>", "<NUM>", and "<NUM>", respectively.

<FIG> is a diagram showing a connection relationship between the microcomputer and the pad shown in <FIG>. <FIG> shows the connection relationship shown in <FIG>, and <FIG> shows the connection relationship shown in <FIG>.

As can be seen by comparing <FIG> with <FIG>, between the microcomputer 218A and the microcomputer 218B, both the pin numbers and the logical ports connected to the pads <NUM> of numbers "<NUM>" to "<NUM>" are different.

Due to such a difference in hardware, it has been difficult to standardize the software executed by the controller <NUM> in the known art.

<FIG> is a diagram showing an example of the source code <NUM> directed to the controller <NUM> shown in <FIG> and <FIG>. Source codes 112A and 112B shown in <FIG> define processing when a signal indicating a predetermined message is output through the pads <NUM> of numbers "<NUM>" and "<NUM>".

More specifically, the source code 112A shown in <FIG> includes a definition <NUM> of a variable indicating a message and a definition <NUM> of a variable (OutPort1 and OutPort2) indicating an output port. The value of the message is set by a function getText() (instruction <NUM>).

In addition, a port connected to the pad <NUM> used to transmit a signal indicating the message is enabled (instruction 1124A). The instruction 1124A sets the logical ports "IO_05" (OutPort1: pin number "<NUM>") and "IO_04" (OutPort2: pin number "<NUM>") of the microcomputer 218A to "Out" (output) (see <FIG>).

Then, by executing an instruction <NUM>, a signal indicating a message is transmitted from the two set logical ports.

On the other hand, in the configuration using the microcomputer 218B, the pads <NUM> of numbers "<NUM>" and "<NUM>" are electrically connected to the logical ports "IO_02" (pin number "<NUM>") and "IO_01" (pin number "<NUM>") of the microcomputer 218B. Therefore, it is necessary to reflect this configuration difference in the source code <NUM>.

Specifically, the instruction 1124B shown in <FIG> enables a logical port different from the instruction 1124A shown in <FIG>. The instruction 1124B sets the logical ports "IO_02" (OutPort1: pin number "<NUM>") and "IO_01" (OutPort2: pin number "<NUM>") of the microcomputer 218B to "Out" (output) (see <FIG>).

Thus, it may be necessary to modify the source code <NUM> each time the specifications of the microcomputer <NUM> used in the controller <NUM> are changed.

For such a problem, in the software development device <NUM> according to the present embodiment, it is possible to directly specify the pad <NUM> electrically connected to an arbitrary device.

<FIG> is a diagram showing an example of the source code <NUM> that can be input to the software development device <NUM> according to the present embodiment. The source code <NUM> shown in <FIG> defines processing when a signal indicating a predetermined message is output through the pads <NUM> of numbers "<NUM>" and "<NUM>", similarly to the source codes 112A and 112B shown in <FIG>.

More specifically, the source code <NUM> shown in <FIG> includes a definition <NUM> of a variable indicating a message and a definition <NUM> of a variable (ActivePad1 and ActivePad2) indicating a pad to be used. The definition <NUM> corresponds to the designation of the controller <NUM> for the pad <NUM>, and includes identification information (in this example, a pad number) for specifying a pad to be used among one or more pads <NUM>.

The value of the message is set by a function getText () (instruction <NUM>).

In addition, information that specifies the pad <NUM> used to transmit a signal indicating a message is set (instruction <NUM>). The instruction <NUM> sets "<NUM>" and "<NUM>", which are identification information of the pad <NUM> to be used, in variables ActivePad1 and ActivePad2, respectively.

Then, by executing an instruction <NUM>, a signal indicating a message is transmitted from the two set pads <NUM>.

Thus, in the software development device <NUM> according to the present embodiment, it is possible to create the source code <NUM> that specifies a pad that is actually connected to the device, and by specifying the pad in this manner, it is possible to abstract the difference in specifications of the microcomputer and the like mounted on the controller <NUM>. That is, even if the specifications of the microcomputer and the like mounted on the controller <NUM> are changed, the same software can be used as it is.

By adopting such a programming configuration, there is an advantage that the user of the controller <NUM> can use the software assets continuously without being aware of the hardware specifications and the like. In addition, even if the specifications of the microcomputer and the like to be used are changed, as long as the manufacturer or vendor of the controller <NUM> designs the internal wiring so as to satisfy the requirements set in advance for each pad, no changes or modifications to the source code will occur.

Next, the functional configuration of the software according to the present embodiment will be described.

<FIG> is a block diagram showing a functional configuration example of the software development device <NUM> according to the present embodiment. Each function shown in <FIG> is typically realized when the processor <NUM> of the software development device <NUM> executes the software development program <NUM>.

Referring to <FIG>, the software development program <NUM> receives an input of the source code <NUM> and generates the execution code <NUM> (assembler code). More specifically, the software development program <NUM> includes a preprocessor <NUM>, a compiler <NUM>, an optimizer <NUM>, and a code generator <NUM>.

The preprocessor <NUM> performs lexical analysis and syntactic analysis on the source code <NUM>, and controls the operations of the compiler <NUM>, the optimizer <NUM>, and the code generator <NUM>. The preprocessor <NUM> corresponds to an analysis means and analyzes the source code <NUM> to extract a designation for one or more pads <NUM>.

The compiler <NUM> generates an object code based on the results of lexical analysis and syntactic analysis on the source code <NUM>. The optimizer <NUM> optimizes the generated object code. The code generator <NUM> outputs the final execution code <NUM> based on the result of optimization by the optimizer <NUM>.

The compiler <NUM>, the optimizer <NUM>, and the code generator <NUM> correspond to a generation means, and generate an execution code including a code corresponding to the extracted designation for the pad <NUM> with reference to the hardware information of the target controller <NUM>.

The software development device <NUM> has a configuration <NUM> including the hardware information of the controller <NUM> on which the execution code <NUM> is executed. The configuration <NUM> is prepared for each controller <NUM>, and the configuration <NUM> corresponding to the target controller <NUM> is selected.

Typically, the configuration <NUM> includes information for specifying a pin-pad connection relationship in a semiconductor device (typically, a microcontroller) mounted as shown in <FIG>. The software development device <NUM> selects the corresponding configuration <NUM> according to the type of the controller <NUM> on which the execution code <NUM> is executed, and determines route information and the like required to use the pad <NUM> specified in the source code <NUM> with reference to the content of the selected configuration <NUM>. That is, the configuration <NUM> includes setting information for absorbing the difference in the hardware that makes up the controller <NUM>.

The type of the controller <NUM> may be manually selected by the user, or may be automatically acquired by connecting the software development device <NUM> and the controller <NUM> to each other. The configuration <NUM> may be additionally acquired by the software development program <NUM> from a server designated in advance, or may be stored in advance in a storage of the controller <NUM> or the like so that the software development device <NUM> reads the configuration <NUM> when necessary.

In addition, the execution code <NUM> may be generated so as to match the target controller <NUM>.

<FIG> is a diagram for describing the data structure of the execution code <NUM> generated by the software development device <NUM> according to the present embodiment. Referring to <FIG>, the execution code 116A includes one or more object codes (in the example of <FIG>, object codes <NUM> and <NUM>) and a required library module <NUM>. The library module <NUM> is a part of an object code referenced by the object codes <NUM> and <NUM>. Typically, necessary data is passed from the object code <NUM> or <NUM> to the library module <NUM> to perform processing, and the result is returned to the object code <NUM> or <NUM>.

On the other hand, in the example shown in <FIG>, codes in charge of the library module <NUM> in the execution code 116A shown in <FIG> are included in object codes <NUM> and <NUM> as unique codes <NUM> and <NUM>. That is, the object codes <NUM> and <NUM> include the unique codes <NUM> and <NUM> for executing the processing specific to the target controller <NUM>.

Thus, the object codes <NUM> and <NUM> may include instructions (object codes) generated in accordance with the target controller <NUM>. That is, the software development device <NUM> may generate the execution code <NUM> by using the code unique to the target controller <NUM> instead of the library module <NUM> that is commonly used between controllers. By adopting such a configuration, the possibility of the occurrence of an execution error in the controller <NUM> can be reduced, and an increase in the processing speed can be expected.

Next, an application example of the pad <NUM> provided by the controller <NUM> according to the present embodiment will be described. As described above, in the present embodiment, it is possible to specify one or more pads <NUM> provided in the controller <NUM> and execute various processes. By using such a pad <NUM>, it is possible to realize physical interface with various kinds of hardware.

<FIG> is a diagram for describing an application example of the pad <NUM> provided by the controller <NUM> according to the present embodiment. Referring to <FIG>, the controller <NUM> has a plurality of pads <NUM> arranged in a matrix, and an adapter <NUM> that can be electrically connected to these pads <NUM> is prepared. In a state in which the adapter <NUM> is mounted, terminals can be arranged at positions that can be electrically connected to the respective pads <NUM>.

A function may be defined in advance for each of the plurality of pads <NUM> arranged in a matrix.

<FIG> shows an example in which only some pads (numbers "<NUM>" to "<NUM>" and numbers "<NUM>" to "<NUM>") among the plurality of pads <NUM> are used. Any device connected to the adapter <NUM> transmits and receives signals to and from the specific pad <NUM> of the controller <NUM>.

As described above, even if the specifications of the microcomputer <NUM> provided in the controller <NUM> are changed and a new hardware configuration for maintaining the layout of the pad <NUM> and the provided functions is adopted, the source code <NUM> can be used as it is as long as the configuration <NUM> that defines the hardware configuration is prepared. That is, changes in the hardware configuration of the controller <NUM> can be absorbed by software.

In this manner, even if semiconductor devices such as a microcomputer progress, the physical interface (pad <NUM>) of the controller <NUM> can be maintained and the software assets can be used as they are. As a result, the interface with the controller <NUM> is immutable when viewed from any device connected to the controller <NUM> through the adapter <NUM>, and accordingly the system can be maintained permanently.

Next, a processing procedure for generating the execution code <NUM> from the source code <NUM> in the software development device <NUM> according to the present embodiment will be described.

<FIG> is a flowchart showing a processing procedure for generating the execution code <NUM> from the source code <NUM> in the software development device <NUM> according to the present embodiment. Each step shown in <FIG> is typically realized when the processor <NUM> executes the software development program <NUM>.

Referring to <FIG>, the software development device <NUM> performs lexical analysis and syntactic analysis on the input source code <NUM> (step S100). The software development device <NUM> determines whether or not any of the pads <NUM> is designated based on the analysis results (step S102). That is, the software development device <NUM> analyzes the source code <NUM> to extract a designation for one or more pads <NUM>.

If none of the pads <NUM> is designated (NO in step S102), the processing of steps S104 and S106 is skipped.

If any of the pads <NUM> is designated (YES in step S102), the software development device <NUM> acquires the configuration <NUM> corresponding to the controller <NUM> to which the execution code <NUM> is transferred (step S104), and determines route information required to use the designated pad <NUM> with reference to the acquired configuration <NUM> (step S106). This route information includes information for resolving the pin number, the logical port, and the like of the microcomputer connected to the designated pad <NUM>.

Then, the software development device <NUM> generates object codes in units of modules included in the source code <NUM> (step S108), combines the object codes, and outputs a result of the combination as the execution code <NUM> (step S110). Then, the process ends.

In this manner, the software development device <NUM> generates an execution code including a code corresponding to the extracted designation for the pad <NUM> with reference to the hardware information (as an example, the configuration <NUM>) of the target controller <NUM>.

In the above description, for convenience of explanation, a pad has been described as a typical example of a physical interface, but the present disclosure can also be similarly applied to one or more arbitrary physical interfaces (parts of circuits that can transmit and receive signals) without being limited to the term "pad".

According to the present embodiment, the interface to be used among the physical interfaces provided by the controller <NUM> can be defined in the source code <NUM>, and a mechanism capable of absorbing the difference in the hardware configuration of the controller <NUM> can be provided. As a result, from the viewpoint of the device connected to the controller <NUM>, the same interface can be maintained regardless of the type of the controller <NUM>, and the software can be used as it is regardless of the change of the controller <NUM>.

Claim 1:
A software development device (<NUM>) for generating, from a source code (<NUM>), an execution code (<NUM>) executed by a target controller (<NUM>) having one or more pads (<NUM>), comprising:
an analysis means (<NUM>) for analyzing the source code to extract a designation for the one or more pads, wherein each of the one or more pads (<NUM>) is a physical interface between the target controller (<NUM>) and a respective hardware device (<NUM>) external the target controller (<NUM>);
an acquirement means (<NUM>, <NUM>, <NUM>) for acquiring hardware information of the target controller (<NUM>), wherein the hardware information includes information (<NUM>) for specifying a relationship between a pin of the target controller (<NUM>) and a pad of the one or more pads (<NUM>); and
a generation means (<NUM>, <NUM>, <NUM>) for determining, with reference to the acquired hardware information, a connection between one or more pins of the target controller (<NUM>) and the designated one or more pads and generating an execution code including a code corresponding to the determined connection.