JPH06149622A - Emulator - Google Patents

Abstract

PURPOSE:To attain an emulator capable of simulating the status of the display screen of a handy terminal on a developing machine. CONSTITUTION:A source file (sf) is compiled by a compiler CC to generate an object file (of). A reference function library SL and the emulator EM are linked with the object file (of). Thereby various functions inherent in the handy terminal which are called by a source program are filed in an execution file Ef so as to be driven by the developing machine. An application program filed in the execution file Ef is loaded to a main memory in the developing machine to emulate the operation 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. 8 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. Then, on the display screen TD, a selection menu of various application programs is displayed as shown in the figure.

FIG. 9 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. 1
b is an operating system program (hereinafter, abbreviated as OS) that controls basic operations of the CPU 1a.
Is a ROM in which is stored. 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. 10 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.

In the handy terminal 1, the power may be turned off by the upper right end key of the operation key 1e ₁ in FIG. 8 or by an application program. In the latter case, a low voltage state is required because it is automatically performed by a dedicated program for turning off the power (for example, auto power off), or it is necessary to prevent abnormal operation that occurs due to a low voltage state (low battery state) of the battery. There is a case where it is detected by itself.

However, unlike the battery, the commercial power source used for the development machine does not enter the low battery state, and therefore the power off of the handy terminal 1 in the low battery state cannot be imitated on the development machine. . Therefore, conventionally, a method has been adopted in which the handy terminal 1 waits for a low battery state and then the handy terminal 1 itself confirms the operation. With this method, the low battery state cannot be generated at a desired time, so there is a problem that the development efficiency of the program for the handy terminal 1, particularly the program that operates in the low battery state, is extremely low.

The present invention has been made in view of the above-described circumstances, and an object thereof is to emulate the power ON / OFF operation together with the low battery state of the handy terminal 1 on the development machine. It is to provide an emulator that can.

[0016]

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 includes imitation means for imitating a function and detection means for detecting a predetermined input operation, and when the detection means detects the predetermined input operation, the imitation means imitates an end operation in the one computer. It is characterized by doing.

[0017]

According to the present invention, between computers having different hardware configurations, the mimicking means that enables a program created for one computer to operate on the other computer is used to perform a predetermined input operation by the detecting means. The detection mimics the power-off operation in one computer on the other computer.

[0018]

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. 10 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. 10) is an emulator EM described later.
In this way, the debug DG 2 of the application program created for the handy terminal 1 is performed on the development machine (personal computer). In other words, the intention of this embodiment is to use the emulator EM to download the download file Ef of the execution file Ef that has been conventionally required.
The actual machine debug DG1 on the handy terminal 1 which is made in response to this is omitted, and the low battery state of the handy terminal 1 is simulated on the development machine.

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.

The function of the emulator EM is the same as that of the terminal-dedicated function library TL (see FIG. 10), as shown in FIG. 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.

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 is a function for operating a code output function for designating a cursor position, erasing the entire screen, scrolling up / down, etc. in correspondence with 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 supply control function for displaying operations such as main power-off 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, an outline of an emulation operation of an application program created based on this procedure, and the emulation operation will be described. When developing an application program, first add "emu_sta" to the beginning of the source program at the coding stage.
The function "rt ()" is described, and the function "emu_exit (n)" is described at the end of the program. Then, as shown in FIG. 1, the source file sf is subjected to compilation cc to generate an 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. This initial setting emulates the startup state of the handy terminal 1, and sets, for example, the on / off state of the backlight, the contrast state of the liquid crystal panel, or the speaker volume.

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 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.

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

In this way, various processes are emulated,
As will be described later, when the power OFF processing routine is started and the restart is not designated, the emulation operation ends based on the function "emu_exit (n)" defined at the end of the program.

Next, with reference to FIG. 5, the low battery state generation processing, which is one of the functions executed in step S2, will be described. In the explanation of this operation, the key input control function f3 described above is activated and is ready for key input, and the character string in which this function f3 is set in the key buffer is passed to the low battery state generation routine described later. Shall be handed over. here,
When the application program is in the key input state in step S2, the low battery state generation routine shown in FIG. 5 is activated by the interrupt process at every predetermined cycle and always checks the key input state.

First, in step SP1, it is determined whether or not there is data in the key buffer at the present time.
When there is no data, that is, when no key operation is performed, the determination result is “NO”, and the processing immediately ends without executing the subsequent processing in this routine, while the data is processed. Is present, the determination result is “YES”, the process proceeds to step SP2, the data in the key buffer is scanned, and further the process proceeds to step SP3, where the scanned data causes a low battery state. It is determined whether or not the operation corresponds to the key operation to the effect.

Here, the key operation to generate the low battery state means a predetermined specific key operation method. In this embodiment, for example, "CTR
L ”+“ O ”,“ CTRL ”+“ B ”,“ CTRL ”+
Corresponds to either "L". Among these key operations, “CTRL” + “O” is used to emulate the low battery state of the main battery in the handy terminal 1, and “CTRL” + “L” is the low battery state of the sub battery. , And “CTRL” + “B” are used to emulate the low battery state of the memory card 1f. Note that "CTRL" + "O" means an operation of pressing the "CTRL" (control) key and the "O" key at the same time, and these operations are not supported on the handy terminal 1 side. Used.

If the determination result of step SP3 is "NO", the process proceeds to step SP6, and step SP6
Return the scanned data in 2 to the key buffer,
While this routine ends in order to use this data in another process, if the determination result is "YES", the process proceeds to step SP4 to turn on the state flags LB1 to LB3 in response to the key operation. To do. That is, if the pressed key is "CTRL" + "O", the state flag LB1 is turned on, and if it is "CTRL" + "L", the state flag LB2 is turned on, and "CTR" is turned on.
If "L" + "B", the state flag LB3 is turned on.

Then, the status display of the "power status" in the display area E3 shown in FIG. 4 is changed from "normal" to any of "LB1", "LB2", and "LB3" corresponding to the key operation, The display indicates that the low battery state is being emulated, and this routine ends. As described above, in the low battery state generation routine, any of the state flags LB1 to LB3 is turned on in response to a predetermined key operation performed in the key input enabled state of step S2 in FIG. 3, and correspondingly, The state of the state flag is displayed in the display area E3.

Next, an example of a function using the state flags LB1 to LB3 set in the above routine will be described with reference to FIG. The routine shown in FIG. 7 is an example of a low battery state acquisition function, and is executed by a predetermined key operation or interrupt processing. First, when this routine is started, the state flags LB1 to LB3 set by the routine shown in FIG. 5 are read in step SB1, and the contents of the read flags are returned to the operator in step SB2. When the power supply control function f6 (see FIG. 3) operates such a function corresponding to the development machine, operations such as low battery state detection can be displayed on the development machine. by this,
Conventionally, the operation state of the handy terminal 1 in a low battery state, which cannot be directly verified or visually confirmed, becomes apparent on the development machine.

When the state flag LB1 is turned on, if an application program for turning off the power is created, the power off processing routine shown in FIG. 7 is executed. First, when this routine is executed, the process proceeds to step SC1, and the display area E1 displays "Power is turned off". Then, in step SC2, it is determined whether or not this operation is a restart designation. Here, the restart designation is
This is the designation of a function to resume the program immediately from the state immediately before this operation, that is, a so-called resume function. If this designation is not made, the determination result is "NO".
Therefore, while the process proceeds to step SC5 described later, if the restart is designated, the determination result is "Y.
ES ”, and the process proceeds to the next step SC3.

Next, in step SC3, the display area E is displayed.
The message "Return to emulation with space key" is displayed in 1, and in this state, in the next step SC4, it is detected whether or not there is a space key input. At this time, if the space key is not input, the determination result is “NO”, and the process returns to step SC4, while if the space key is input, the determination result is “YES”. Then, this routine ends, and the process of step S2 (see FIG. 3) is performed again. As a result, when the restart is designated and the power OFF routine is activated, the execution of each function in step S2 shown in FIG. 3 is suspended.

On the other hand, in step SC2, when the restart is not designated, the determination result is "NO".
Then, the process proceeds to step SC5 to display area E1.
Is displayed on the screen, "End with space key" is displayed. In this state, in the next step SC6,
It is detected whether or not there is a space key input.
At this time, if the space key is not input, the determination result is “NO”, the process returns to step SC4, and the process is cycled until the space key is input. Then, when the space key is input, the determination result is “YES”, the power OFF processing routine is ended, and the execution of each function in step S2 (see FIG. 3) is also ended. The rate operation ends.

In this way, when the application program for turning off the power is created, the status flag LB1
When is turned on, a function for emulating power off is executed, and a message "power is turned off" is displayed. After this, depending on the restart designation,
Power off is emulated. At this time, if restart is specified, the process is interrupted until the space key is input, and the power-off operation of the handy terminal on the development machine is emulated, while restart is specified. If not, the space key input terminates the emulation operation of the handy terminal on the development machine.

In this way, the emulator EM has the same arguments as the dedicated function library TL corresponding to the hardware environment of the handy terminal 1, and the functions f1 to f9 of each dedicated function are set in the hardware environment of the development machine. Corresponding. Therefore, when the emulator EM is linked to the source program and the generated execution file Ef is loaded on the development machine, 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, all the program development can be performed on the same machine. Become. As a result, it is possible to omit the download DL of the execution file Ef, which is conventionally required, and the actual machine debug DG1 that is performed in response to the download DL. Furthermore, in the development machine, it is possible to emulate a low battery state, which is not normally possible, by a predetermined operation at any time. These enable extremely efficient program development. As a result, the power-off operation in the handy terminal 1 can be imitated on the development machine, and the operation of the handy terminal 1 becomes obvious on the development machine.

The emulator EM has the same arguments as the dedicated function library TL corresponding to the hardware environment of the handy terminal 1 and has the functions f1 to f9 of each dedicated function as hardware of the development machine (personal computer). It corresponds to the environment. Therefore, when 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 computer. 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 embodiment, the source program developed for the emulator becomes the source file for the handy terminal as it is, and it has complete compatibility, so that the program development can be performed on the same machine. Become. As a result, it is possible to omit the download DL of the execution file Ef, which is conventionally required, and the actual machine debug DG1 that is performed in response to the download DL. Furthermore, in a personal computer, it is possible to emulate a low battery state, which is not normally possible, at any time by a predetermined operation. These enable extremely efficient program development.

[0045]

As described above, according to the present invention, the mimicking means composed of each function routine defined with the same arguments as the program created for one computer is preliminarily specified for one computer. Since it operates based on a dedicated function created in accordance with, it is possible to emulate the operation of the other computer on one computer.

[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 shows display areas E1, E2, E in the embodiment.
It is a figure which shows the example of a display of 3.

FIG. 5 is a flowchart showing an operation of a low battery state generation routine in the embodiment.

FIG. 6 is a flowchart showing the operation of a low battery state acquisition function in the same example.

FIG. 7 is a flowchart showing an operation of a power OFF processing routine in the embodiment.

FIG. 8 is a plan view showing an external configuration of the handy terminal 1.

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

FIG. 10 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 (mimicking means), SL ... standard function library, Ef ... execution 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. Function library defined by the same arguments as the program, and imitating means for imitating each function corresponding to the hardware configuration of the other computer side, and detecting a predetermined input operation. An emulator comprising: a detecting unit, wherein the imitating unit imitates a termination operation in the one computer when a predetermined input operation is detected by the detecting unit.