KR20020033224A - Method for software pre-test using device emulator - Google Patents

Abstract

PURPOSE: A method for previously checking a software using a device emulator is provided to enable an application program developer to check the operation of a virtual device by emulating an undeveloped device, by enabling an emulator to monitor a register area in case that the virtual device and the register area are generated, and by outputting messages to a display. CONSTITUTION: All sorts of modules are generated and initialized(ST11). In case that each module is initialized, an application module calls a device driver for checking the operation of the device driver and requests the access to the device(ST12). The device driver calls a register reading function or a register writing function instead of returning error values(ST13). The register reading function and the register writing function access to a virtual device control register instead of a real control register(ST14). Each function stores an address value in case of accessing to the virtual register(ST15). In case that the address value is received, an area of the virtual register relevant to the address value is read(ST16). In case that an operation the device emulator will perform is determined, a routine for the operation is called(ST17). The routine outputs fixed messages to a display(ST18). It is judged whether the device driver is normally operated(S19).

Description

Method for software pre-test using device emulator

BACKGROUND OF THE INVENTION 1. Field of the Invention [0001] The present invention relates to a software test performed in a device driver of an input / output device and its application program. In particular, an operating state of an application program on a host computer before hardware development is completed in an embedded system for communication In the case of checking, by emulating an undeveloped device to generate a virtual device and a register area for controlling the device, the emulator monitors the area and outputs a message to a display device rather than an actual input / output device. The present invention relates to a method for pre-inspecting software using a device emulator suitable for allowing a developer of an application to examine the operation of a current virtual device.

In general, developing a system for a certain function requires a lot of time and effort. In particular, there are cases where both the development of hardware and the development of software necessary for operating the developed hardware are required.

If the development of hardware and software is carried out at the same time, the development period of the system can be shortened. Therefore, each development is carried out in a specialized area so that system development can be completed early.

By the way, the hardware and software to be developed must operate in conjunction with each other, as described above, it is not easy to check the interworking state between each other while the study is progressing through separate paths.

For example, if the software for operation is developed before the hardware, it is common to wait for the development of the hardware to be completed to diagnose the operation state of the software.

In this case, if the test target software is provided with the same condition as the hardware, the operating state of the software may be diagnosed even without the hardware of the entity.

Thus, an emulator is a software module that gives software programmed to access the hardware in spite of the absence of a module for a specific hardware or a specific function.

The present invention is intended to enable the operation diagnosis of the software even in the environment where the hardware does not exist using such an emulator.

First, Fig. 1 is a conceptual diagram of software precheck using a device emulator according to the prior art.

As shown in FIG. 1, when a plurality of application modules are provided in an application program, not only data exchange between the modules is performed but also data exchange between the application modules and the device driver is performed.

In this case, when the development of the device is not completed or when there is no device under a specific condition and wants to diagnose the operation state of each of the application modules, an emulator of the device driver is used.

More specifically, in the case of an application program requiring access to an I / O device, an application module independent of the I / O device and a device driver for direct driving of the device are developed separately.

Under these circumstances, integration testing of existing software may be performed before hardware development is completed. In the integrated test of the software, a dummy device driver is used separately from the developed device driver, and thus the integrated test of each module is performed within a limited range without accessing the actual hardware.

The pseudo device driver is used for software integration test in place of the actual device driver. At this point, the pseudo device driver becomes an emulator of the device driver.

The reason for using an emulator is that when an application program directly calls a device driver to access an input / output device, the device driver only returns an error value due to the absence of the target device and does not perform the expected operation.

Thus, there is an application program developed on a host computer, and when the application program accesses a device, it calls a device driver application program interface (API) written as a dummy function.

The dummy functions either do nothing or return a dummy return code if necessary. The return value may be a reference value for determining whether the function normally operates when each function calls another function in the application program.

By the above operation, it is possible to diagnose various errors that may occur when connecting the application modules together and to diagnose the overall operating state of the integrated program. According to the above diagnosis, additional measures, such as debugging of a module in which an error occurs, are further performed.

As such, prior to device development, an integrated test of an application program is performed by using a pseudo device driver, thereby preventing referencing errors between each application module and performing diagnosis on interaction between modules depending on the device. You can do it.

However, in the above-described prior art, an application program using an input / output device can only perform diagnosis within a limited range until the development of hardware is completed.

In other words, in performing the integrated test of the application program, the pseudo device driver is used without the actual device driver. Since the pseudo device driver is implemented with only a dummy function, the device driver module can operate the device properly. Diagnosis of whether it could be done was impossible.

This disadvantage of not being able to diagnose the actual device driver API could be a cause of lowering the consistency and efficiency of the overall system development process.

Accordingly, the present invention has been proposed to solve the conventional problems as described above, and an object of the present invention is to check the operation state of an application program on a host computer before the development of hardware is completed in an embedded system for communication. By emulating an undeveloped device, when a virtual device and a register area for controlling the device are generated, the emulator monitors the area and outputs a message to a display device rather than an actual input / output device, thereby allowing the developer of the application program to The present invention provides a method for pre-inspecting software using a device emulator suitable for checking the operation of a virtual device.

In order to achieve the above object, the software pre-checking method using the device emulator according to the present invention includes the steps of: an application module calling a device driver after generation and initialization of each module for the integrated test of the software; A device driver called to an application module, calling a function to access a virtual register area, and storing the address of the accessed virtual register in a queue; The technical configuration is characterized in that the device emulator reads the accessed virtual register and calls a routine for performing the operation requested by the device driver to perform the operation.

1 is a conceptual diagram of a software pretest using a device emulator according to the prior art,

2 is a software block diagram of a software pre-checking method using a device emulator according to an embodiment of the present invention.

3 is a flowchart of an inspection method applied to FIG. 2.

Hereinafter, the configuration and operation of the present invention will be described based on embodiments according to the technical idea of the software pre-checking method using the device emulator as described above.

First, FIG. 2 is a software block diagram illustrating a software pretest method using a device emulator according to an embodiment of the present invention, and FIG. 3 is a flowchart of a test method applied to FIG.

As shown in FIG. 3, a suitable embodiment of the present invention includes generating and initializing respective application modules, registers, and device emulators for the integrated test of software, and then calling the device drivers with the device modules (ST11 to ST12). Wow; When the application module calls the device driver, calling a read / write function for the virtual device control register to access the register and storing the address of the corresponding virtual register in a queue (ST13 to ST15); If the device emulator reads the address information of the virtual register accessed by the device driver from the queue, accesses the corresponding region of the virtual register indicated by the address, checks the requested operation, and calls a routine to perform the operation. The specified routine performs the steps ST16 to ST19 of displaying a constant message on the host computer.

The operation of the method configured as described above is as follows.

The method proposed in the present invention uses an emulator of a device rather than an emulator of the device driver in order to be able to diagnose an operating state of the device driver in a software integration test.

Therefore, in the present invention, it is possible to proceed the software integration test in the state of including the device driver without exclusion.

Figure 2 shows the overall software block of the present invention for the implementation of the functionality.

As shown in Fig. 2, the present invention provides a deviceEmulateTask () which is a module that emulates an actual device; A Virtual Device Control Register, which resides in memory on the host computer and serves as a register of the actual device; The module consists of readRegister and writeRegister, routines that are called by the device driver to access virtual device control registers.

Inside the device emulator, the module is composed of variousRoutines () that emulates the actual device operation according to the change of the virtual device control register and selectAction () which is responsible for branching to each routine.

It also includes a separate message queue called TO_DEVICE_Q for communication between the device emulator and the routine for access to the device.

Referring to the method according to the present invention in more detail with reference to Figure 3, when the integrated test of the application program in the development stage, it is necessary to generate a variety of modules for the integrated test and initialize appropriately (ST1).

First, a message queue is created using the system calls of the operating system. It creates a deviceEmulatorTask (), which is a device emulator that acts as a virtual device.

In addition, a virtual device control register area is allocated to the memory area of the host computer to replace the actual device register. The virtual device registers provide the device driver with an environment as if the device is being accessed.

In this case, when writing a new device driver, all the parts that access the internal control register of the device are implemented by using the readRegister () and writeRegister () functions. On the other hand, in the case of the device driver provided by the chip manufacturer, the part that accesses the virtual register may be modified by the above two functions.

In order to diagnose the operation state of the device driver while the initialization of each module is performed for the integrated test, the application module calls the device driver and requests access to the device (ST12). This is a constant read or write request to the device.

A device driver that is requested to access a device should call the register read function (readRegister ()) or register write function (writeRegister ()), rather than returning an error value due to the absence of the device due to the uniqueness of the test environment. (ST13).

That is, when a device driver is requested to read a device, the device driver calls readRegister (), a register read function, and writeRegister (), a register write function, when a device write is requested.

When the device driver calls each of these functions, they access the virtual registers in memory instead of the actual control registers, while at the same time posting the address of the virtual register that accessed the previously created queue.

That is, the readRegister () and writeRegister () access a virtual device control register on a host computer, not an actual device (ST14).

Each function stores its address value in TO_DEVICE_Q corresponding to the message queue when accessing the virtual register (ST15).

The address value stored in TO_DEVICE_Q is read by the device emulator (deviceEmulatorTask ()). Thus, the device emulator pending to the queue receives a message, accesses the virtual register area, reads the value of the accessed register area, and branches to each routine that emulates the operation according to this value.

That is, the device emulator monitors TO_DEVICE_Q using the pendQueue () function after the first startup, and when an address value is received in the queue, the device emulator reads the area of the virtual register indicated by the address value and selects an operation to be performed (ST16). ).

The action selection is performed by a function such as selectAction (), where the action selected should be one of a number of actions required for the emulating device. The criterion of the selection is a message for the device driver to access the virtual register.

When an action to be performed by the device emulator is determined by the selectAction () function, a routine for performing the specific action is called. As many routines as necessary for the operation required by the device emulator are required, and the functions for processing the routines are the same as those of variousRoutines () (ST17).

Since each of the above routines is implemented for testing purposes, the appropriate processing is performed. An example of the operation of the called routine is to output a constant message to the display device on the host computer (ST18).

In the above example, the routine is terminated with the output of the message. The output can be analyzed to determine whether the corresponding device driver is operating normally.

After this series of steps is performed, the test can be continued or stopped.

As such, in the present invention, by implementing a device emulator that emulates a device during software integration test, each emulation routine included in the device emulator takes the role of the actual device in such a manner as to output a message to the display device of the host computer. In other words, the developer can monitor the operation status of the device driver.

Although the preferred embodiment of the present invention has been described above, the present invention may use various changes, modifications, and equivalents. It is clear that the present invention can be applied in the same manner by appropriately modifying the above embodiments. Accordingly, the above description does not limit the scope of the invention as defined by the limitations of the following claims.

As described above, the software pre-inspection method using the device emulator according to the present invention has an advantage of enabling an integrated test for an application program that accesses an input / output device in a test environment as close as possible before the actual hardware development is completed. have.

In the absence of an actual device, device drivers can be developed and diagnosed under the same conditions as in an actual operating environment, and a device driver provided by a chip manufacturer can be tested.

In addition, by allowing the device emulator to loop back packet data, it is possible to test packet transmission and reception at the input / output device.

Claims (6)

Invoking the device driver by the application module after the generation and initialization of each module for the integrated test of the software is performed; A device driver called to an application module, calling a function for accessing a virtual register area, and storing an address of the accessed virtual register; And a step of causing a device emulator to read the accessed virtual register to call a routine for performing an operation required by the device driver to perform a corresponding operation. The method of claim 1, wherein the generating and initializing of each module comprises: Allocates a virtual device control register in memory on the host computer to be a virtual register area accessed by the device driver, Create a message queue with a system call so that the address of the accessed virtual register can be stored, And initializing a device emulator to monitor whether an address of a virtual register is stored in the message queue. The method of claim 1, wherein the function called by the device driver is A function for reading a message by accessing a virtual register area allocated on the host computer in place of the register area of the actual device; And a function for writing data in the accessed area. The device of claim 1, wherein the device emulator comprises: A function for monitoring the space in which the access address for the virtual register of the device driver is stored at startup upon initialization; If the function detects the arrival of an address value, reads a value from a virtual register at a location indicated by the address to determine what operation is required; And a function of calling a plurality of routines for reading the virtual register to perform a checked operation. The routine of claim 1 wherein the routine called by the device emulator comprises: And outputting a predetermined message to a display device of a host computer to monitor an operation state of a corresponding device driver by analyzing the output result of the message. The method of claim 1, When the device driver transmits certain data and receives the data again, the device emulator starts a routine for echoing and writing data written to the virtual register area to perform packet transmission / reception test of the input / output device. Software pre-testing method using a device emulator.