JPH06149621A - Emulator - Google Patents

Abstract

PURPOSE:To attain an emulator capable of emulating the status of the display screen of a handy terminal on a developing machine. CONSTITUTION:At the time of starting the emulator EM constituted of respective function routines defined by the same arguments as that of a program prepared for the handy terminal, the emulator EM emulates the hardware constitution of the handy terminal by an initializing state setting routine and then emulates respective functions respectively corresponding to developing machine side hardware constitution in accordance with the specification of the handy terminal.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an emulator suitable for use in developing an application program for a portable computer called a "handy terminal".

[0002]

2. Description of the Related Art In recent years, various portable computers called "handy terminals" have been put into practical use. This type of computer is portable and
It is used in various fields because it enables various data processing at the carrying destination. FIG. 9 is a plan view showing an external configuration of such a handy terminal 1. On the operation surface of the handy terminal 1, operation keys 1e _{1 including} a numeric keypad and function keys, and a transparent touch panel 1e
A display screen TD of an LCD (liquid crystal display element) having ₂ is provided. The contrast of the LCD is adjustable, and a backlight (not shown) is provided so that the display can be identified even in a dark place. Then, on the display screen TD, for example, as shown in the figure,
A selection menu of various application programs is displayed.

FIG. 10 is a block diagram showing an electrical configuration of the handy terminal 1. In this figure, 1a is a CPU that controls each part of the handy terminal 1.
Reference numeral 1b is a ROM that stores an operating system program (hereinafter, abbreviated as OS) that controls basic operations of the CPU 1a. Reference numeral 1c is a RAM in which an application program for the corresponding business is loaded and various register values are temporarily stored as a work area of the program. 1d is a display circuit of the LCD, which displays various data and the like supplied from the CPU 1a via the internal bus. 1e is a operator for detecting the operation state of the operation keys 1e ₁ and the transparent touch panel 1e _2, generates operator signals corresponding to each operation.

Reference numeral 1f is a memory card which is detachably attached to the back surface of the main body of the handy terminal 1. The memory card 1f stores the above-mentioned application program or various data referred to by the program. The data stored in the memory card 1f is downloaded from a host computer (not shown). Reference numeral 1g is a communication control circuit which is composed of, for example, a modem and controls serial data communication. Although not shown in this figure, the handy terminal 1 emphasizes portability,
A battery is used as the operating power source, and this battery is the main battery and
It is divided into a secondary battery as a backup power source when replacing the main battery. A battery is also used to back up the stored contents in the memory card 1f.

In the handy terminal 1 having such a configuration, the OS is booted from a download or a memory card by resetting. The handy terminal 1 is configured so that it will not be reset even if the power is turned off. Normally, when the power is turned on next time, the power is turned on.
It is designed to restart from the state of FF. Then, after the OS starts up, the corresponding application program for business executes data processing. further,
When a selection menu screen as shown in FIG. 9 is displayed on the display screen TD, the program is executed by touching the display screen TD (transparent touch panel 1e ₂ ) where the program name is displayed. It is supposed to be done.

By the way, an application program operating on the handy terminal 1 is often described in a structured programming language called "C language".
FIG. 11 is a diagram showing a program development procedure in “C language”. As shown in this figure, program development consists of coding, compiling, and linking work, and the operation of the program is verified through actual machine debugging. The coding, compiling, and linking work is usually performed on a development machine (for example, a personal computer).

In coding, a source program is described in C language based on a predetermined system specification. This source program is a source file sf
Is registered on the development machine as. Source file sf
Becomes an input file of the compiler CC. The compiler CC performs a lexical analysis, a structural analysis, and a semantic analysis on a source program described in C language, and converts the result into an object program described by relocatable intermediate code. This object program is registered as an object file of on the development machine.

In the linker LK, the object file o
For f, the standard function library SL and the terminal-specific function library TL are combined to generate an execution file Ef described in machine language. Here, the standard function library SL is composed of various control function routine programs defined in C language. The terminal dedicated function library TL is composed of a dedicated program group defined to operate in the hardware environment of the handy terminal 1.

That is, in the linker LK, various routine programs and dedicated programs called in the object program are the above-mentioned libraries SL,
Quoted from TL, these are bound to the object program. As a result, the program described by the relocatable intermediate code is converted into the execution format and is generated as the execution file Ef. The executable application program generated in this manner is in a form that can be expanded on an absolute address.

Next, the execution file Ef is downloaded DL to the CPU 1a by communication from the development machine, for example.
To be done. As a result, the actual machine debug DG1 is performed on the handy terminal 1. In the actual machine debug DG1, the operation of the application program is verified according to the inspection items that have been established in advance. This real machine debug DG1
If a bug is revealed in, correct the corresponding part of the source program. Then, the modified source program is recompiled and linked to become an execution file, and the actual machine debug DG1 is repeated.

[0011]

In the program development procedure described above, every time a bug is revealed on the handy terminal 1, the source program part corresponding to the bug is corrected and converted into an execution file again. Must be downloaded to Handy Terminal 1.
Therefore, a large number of man-hours are spent on the actual machine debug DG1, resulting in an increase in development cost.

Therefore, in order to solve such an adverse effect, a series of operations including the above-mentioned coding, compiling, linking and debugging are all performed on the development machine, and at the time of debugging, the handy terminal 1 is used especially on the development machine. It is required to be able to comprehend all the operating states of. In other words, if the application program can be executed on the development machine and the operation of the handy terminal 1 can be emulated, the above-mentioned drawbacks can be solved and efficient program development can be performed.

By the way, it goes without saying that the handy terminal 1 and the development machine often have completely different hardware environments. This includes, for example, the capabilities of the display screen and the presence or absence of a mouse. Therefore, there is a problem in that when the emulator is started up, it is necessary to perform initialization settings to match the handy hardware environment.

The present invention has been made in view of the above-mentioned problems, and an object of the present invention is, even on a development machine,
An object of the present invention is to provide an emulator capable of emulating an operation according to an initial setting state of a handy terminal.

[0015]

In order to solve the above problems, the present invention enables a program created for any one of computers having different hardware configurations to operate on the other computer. In the emulator, a function routine defined by the same argument as the program, which is a library formed by a plurality of routines called by the program, corresponds to the hardware configuration of the other computer side. It is characterized by including imitation means for imitating a function and initial setting means for setting information about the hardware configuration of one computer imitated by the imitation means when the imitation means is activated.

[0016]

According to the present invention, the initial setting means sets the information on the hardware configuration of one computer imitated by the imitating means when the imitating means is activated. After that, the imitation means imitates each function corresponding to the hardware configuration of the other computer based on the set information.

[0017]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing an outline of a program development procedure to which an embodiment of the present invention is applied. In this figure, parts common to the parts shown in FIG. 11 are assigned the same reference numerals and explanations thereof are omitted. The procedure shown in FIG. 1 is shown in FIG.
The difference from the conventional example shown in is that the terminal-dedicated function library TL (see FIG. 11) has an emulator EM described later.
In this way, the application program created for the handy terminal 1 is debugged DG2 on the development machine. That is,
The intention of this embodiment is that the execution file E which has been conventionally required is obtained by using the emulator EM.
Download DL of f (see FIG. 11) and the actual debug DG1 on the handy terminal 1 performed in response to the download DL.
The point is that and are omitted.

Next, the functional outline of the emulator EM for realizing the program development procedure of FIG. 1 will be described. First, the emulator EM is made up of a group of programs in which various functions defined to operate in the hardware environment of the handy terminal 1 are redefined to operate in the hardware environment of the development machine.

As shown in FIG. 2, the function of the emulator EM is the same as that of the terminal-dedicated function library TL (see FIG. 11). In other words, in this emulator EM, the external specifications of each function are specified with the same arguments as the terminal dedicated function library TL, and the inside of each function is redefined to emulate the operation of the handy terminal 1 on the development machine. ing.

In FIG. 2, f1 is an emulator initialization function. The emulator initialization function f1 is for initializing the emulator EM when the function "emu_start ()" is described at the beginning of the source program. Therefore, as shown in FIG.
When linking the object file of and the emulator EM, this function "emu_start ()" is required. Note that this function is not affected by execution when linked with the terminal-specific function library TL. Therefore, the source file sf created for the emulator can be directly converted into the execution file for the handy terminal 1. In this case, in handy terminal 1, "emu_star"
Even if the function "t ()" is described, it is ignored and no processing is performed.

Next, f2 is a screen display control function. In the screen display control function f2, each function defined for the handy terminal 1, for example, various functions for setting a display mode, moving a cursor, setting an attribute of a cursor shape or a display character, etc., is executed by a hardware of a development machine. This is a function that operates according to the wear environment. f
Reference numeral 3 denotes a key input control function, which replaces the touch panel input and ten-key input made by the handy terminal 1 with mouse input and key input on the development machine. f4 is an escape sequence control function, and a code output function for designating the cursor position, scrolling up / down, or erasing the entire screen described later,
This is a function that operates according to the hardware environment of the development machine.

The function f5 corresponds to a development machine with a function for acquiring and outputting system information such as main memory capacity, driver registration information, and external character registration information. f6 is a power control function for displaying operations such as main power-on control and low battery state detection on the development machine. f7 is
This is a communication control function that emulates the serial data communication control defined for the handy terminal 1 on the development machine. f8 is a printer control function for controlling the print font, line feed pitch, etc. defined for the handy terminal 1 on the development machine. f9 is an emulator termination function, which is the end of the source program,
Alternatively, when a function "emu_exit (n)" is described in the middle, the function is to terminate the emulator EM.

Next, a program development procedure using the emulator EM and an outline of the emulation operation of the application program created based on this procedure will be described, and further, the escape sequence control in the emulation operation will erase the entire screen. The processing will be described as an example.

When developing an application program, first, at the coding stage, a function "emu_start ()" is described at the beginning of the source program, and "emu_exit (n)" is described at the end of the program.
Describe the function. Then, as shown in FIG.
The source file sf is compiled cc to generate the object file of.

Next, the standard function library SL and the emulator EM are linked to this object file of. As a result, various functions peculiar to the handy terminal that are called by the source program are converted into an executable file so that they will run on the development machine. The application file in the form of an executable file is loaded on the main memory of the development machine to emulate the operation of the handy terminal 1.

Emulation Operation of Application Program When the application program created by the above procedure is activated, the processing of the development machine proceeds to step S1 shown in FIG. In step S1, the emulator initialization function f1 described above performs initialization based on the function "emu_start ()" defined at the beginning of the program. In this initial setting, the initial state set when downloading the handy terminal 1 is set on the development machine side.

Next, the initialization of the emulator will be described. First, the setting contents of initialization will be described with reference to FIG. This setting is for setting the contents set in the handy terminal 1 in the emulator on the development machine side. These include backlight on / off, contrast, speaker volume, APO / ABO.
(Auto power off / Auto backlight off), Number of non-Kanji characters, System display, Key pattern No. , Screen mode, number of console lines, valid / invalid of ^ C, and presence / absence of extended RS232C.

As shown in this figure, each setting content corresponds to a variable name, and the setting value (possible value or range) is defined in the variable name. The setting example is an equation in which a variable name is written on the left side and a setting value is written on the right side and connected by an equal sign. When the emulator is initialized and set with each setting content, the operator creates a setting file in which the equations in which the setting values are set in the variable names of the setting content are itemized. Here, an example of the setting file is shown in FIG. In the setting file SF shown in this figure, the number of non-Kanji characters is 64 and the key pattern N is
o. Corresponds to the key display corresponding to "1", and the screen mode corresponds to the mode corresponding to "2".

Next, the emulator initialization performed in step S1 will be described in detail. 6 and 7 are flowcharts showing this initialization operation. When the emulator EM is activated on the development machine, the initialization routine shown in FIG. 6 is activated first. First, in step SB1, the initialization state of the handy terminal 1 described later is set, and the contents of the setting file are read.

Next, the mouse initialization operation of the input device on the development machine is performed (step SB2). Furthermore, in order to emulate the display mode of the display screen TD (see FIG. 9), the display DS on the development machine TD is displayed.
A display area E1 (described later) is assigned to a part of the display area of P (step SB3), and then the transparent touch panel 1 displayed on the display screen TD of the handy terminal 1 is displayed.
to the key division setting state of e ₂ emulating developed display area E2 (described below) on a part of the display area of the display DSP in machine TD is assigned (step SB4), setting of various flags in the handy terminal 1 In order to display the status, a display area E is provided in a part of the display area of the display DSP in the development machine TD.
3 (described later) is assigned (step SB5).
Then, various flags on the development machine side are initialized (step SB6). After this step ends, this routine ends, and the process proceeds to step S2 in FIG.

Next, the initialization state setting of the handy terminal 1 performed in step SB1 in FIG. 6 will be described with reference to FIG. First, step SC1
Then, all the setting contents shown in FIG. 4 are once set to default values. In the next step SC2, it is detected whether or not the setting file as shown in FIG. 5 is set on the development machine. If the setting file does not exist, the determination result is “NO”, and this routine ends immediately, while if the setting file exists, the determination result is “YE”.
S ”, and the process proceeds to the next step SC3.

At step SC3, it is judged if the record (row) detection of the setting file is completed. If it is finished, the determination result here is “YES”, and while this routine is finished, if it is not finished, the determination result is “NO”, and the next one record is read (step SC4), It is determined whether or not the record is valid (step SC5). That is, in this step, the record read in step SC4 is
It is determined whether or not it is a variable of the setting content shown in FIG. 4 and whether or not it is within the set value. If it is determined that the record is invalid, this routine ends while
If it is determined that the routine is valid, the result of this determination is "YES", and the description content of the record is set as the setting content of the initial state (step SC
6). Then, the process returns to step SC3 again to read the next record. After that, the process is step SC3 → SC4 → SC until all records are read.
When all the lines of the setting file are read and set in the cycle of 5 → SC6 → SC3, the process proceeds to step SB2 in FIG.

As described above, in this routine, the setting contents are once set to the default values, but if the setting file (see FIG. 5) exists, it is rewritten to the contents of this setting file. Then, the setting contents are set as the contents of the initial state of the emulator EM. After that, when each function is executed in step S2 (see FIG. 3), it is executed based on the set contents.

Thus, when the initial state of the handy terminal 1 is emulated on the development machine, for example, as shown in FIG.
As shown in, various emulation states of the handy terminal are displayed on the display DSP. As shown in this figure, the display DSP has a display area E1,
The display area E is divided into three parts, E2 and E3.
1 has the same display as the display screen TD. further,
The display area E2 displays the split state of the touch panel of the handy terminal 1, and the display area E3 displays the operating state of the handy terminal 1.

Next, when such initial settings are made, the processing of the development machine proceeds to step S2. In step S2, the application program executes each function according to the given event. In step S2, the key input control function f3 is operated so as to input the touch panel input of the handy terminal 1 with the mouse, and the interrupt process for moving the mouse cursor is executed correspondingly.

Here, as shown in FIG. 8, when a mouse is input by clicking a predetermined position on the display area E1 emulating an actual touch panel, the application program corresponding to this input event is executed, The function defined in the program is executed. As a result, the operation of the handy terminal 1 is emulated on the development machine. For example, as shown in FIG. 4, when the mouse cursor MC is placed on the display of "print" in the display area E1 and the mouse is clicked, the "print" process is emulated on the computer.

When various processes are emulated and an input indicating that the application program is completed is made, the result of the determination in step S3 is "YES",
The processing of the program proceeds to step S4. Step S
In No. 4, "emu_exi" defined at the end of the program
The emulation operation is terminated based on the function "t (n)".

According to this embodiment, the hardware configuration of the handy terminal is emulated on the development machine side by the initialization state setting shown in FIG. Further, the emulator EM has the same arguments as the dedicated function library TL corresponding to the hardware environment of the handy terminal 1, and also makes the functions f1 to f9 of each dedicated function correspond to the hardware environment of the development machine. Therefore, if the emulator EM is linked to the source program and the generated execution file Ef is loaded on the personal computer, the operation of the handy terminal 1 is emulated on the development machine. Further, in this emulation operation, the operating state of the handy terminal 1 is displayed on the display DSP step by step, so that the debugging work of the application program can be performed very efficiently.

Further, according to the above-mentioned embodiment, the source program developed for the emulator becomes the source file for the handy terminal as it is, and it has complete compatibility. Therefore, it is possible to carry out all program development on the same machine. Become. As a result, it is possible to omit the download DL of the execution file Ef and the actual device debug DG1 that are performed according to this, which are conventionally required.
It enables extremely efficient program development.

[0040]

As described above, according to the present invention, in an emulator that allows a program created for one of computers having different hardware configurations to operate on the other computer. , A library formed by a plurality of routines called by the program, each function routine defined with the same arguments as the program imitating each function corresponding to the hardware configuration of the other computer side. And an initial setting unit that sets information about the hardware configuration of one computer imitated by the imitating unit when the imitating unit is activated. The hardware configuration of one computer imitated by imitation means To set that information. After that, the imitation means can imitate each function corresponding to the hardware configuration of the other computer based on the set information.

[Brief description of drawings]

FIG. 1 is a diagram showing an outline of a program development procedure to which an embodiment of the present invention is applied.

FIG. 2 is a diagram showing a functional configuration of an emulator EM in the embodiment.

FIG. 3 is a flowchart showing a schematic operation of an application program created by the embodiment.

FIG. 4 is a list of initialization conditions in the example.

FIG. 5 is a table showing an example of a setting file in the example.

FIG. 6 is a flowchart showing an operation of an initialization routine in the same embodiment.

FIG. 7 is a flowchart showing an operation of initial state setting of the embodiment.

FIG. 8 shows display areas E1, E2, E in the same embodiment.
It is a figure which shows the example of a display of 3.

FIG. 9 is a plan view showing an external configuration of a handy terminal.

FIG. 10 is a block diagram showing an example of an electrical configuration of the handy terminal 1.

FIG. 11 is a diagram for explaining a conventional program development procedure.

[Explanation of symbols]

sf ... Source file, cc ... Compile, of ... Object file, LK ... Linker, EM ... Emulator (imitation means), SL ... Standard function library, Ef ... Executable file.

─────────────────────────────────────────────────── ───

[Procedure amendment]

[Submission date] August 11, 1993

[Procedure Amendment 1]

[Document name to be amended] Statement

[Name of item to be corrected] Brief description of the drawing

[Correction method] Change

[Correction content]

[Brief description of drawings]

FIG. 1 is a diagram showing an outline of a program development procedure to which an embodiment of the present invention is applied.

FIG. 2 is a diagram showing a functional configuration of an emulator EM in the embodiment.

FIG. 3 is a flowchart showing a schematic operation of an application program created by the embodiment.

4 is a diagram table showing the initialization condition in the same embodiment.

FIG. 5 shows an example of a setting file in the embodiment.
It is a drawing table.

FIG. 6 is a flowchart showing an operation of an initialization routine in the same embodiment.

FIG. 7 is a flowchart showing an operation of initial state setting of the embodiment.

FIG. 8 shows display areas E1, E2, E in the same embodiment.
It is a figure which shows the example of a display of 3.

FIG. 9 is a plan view showing an external configuration of a handy terminal.

FIG. 10 is a block diagram showing an example of an electrical configuration of the handy terminal 1.

FIG. 11 is a diagram for explaining a conventional program development procedure.

[Explanation of Codes] sf ... Source file, cc ... Compile, of ... Object file, LK ... Linker, EM ... Emulator (imitation means), SL ... Standard function library, Ef ... Executable file.

Claims (1)

[Claims] 1. An emulator that allows a program created for any one of computers having different hardware configurations to operate on the other computer is formed from a plurality of routines called by the program. In the library, each function routine defined by the same argument as that of the program is imitated by the imitation means for imitating each function corresponding to the hardware configuration of the other computer side, and the imitation means. An emulator, comprising: initial setting means for setting information about the hardware configuration of one computer when the imitating means is started.