JP5666526B2 - Handy terminal device, control method and control program - Google Patents

Description

  Embodiments described herein relate generally to a handy terminal device, a control method, and a control program.

  Conventionally, a handy terminal device has been used as an order processing system for receiving customer orders in restaurants such as restaurants (see, for example, Patent Document 1).

  In other words, hall staff in restaurants and other restaurants use handy terminal devices that go around each table in the hall and include menu data, table numbers, number of people, etc. corresponding to customer orders corresponding to each table. Order data was input sequentially.

  By the way, although such a handy terminal device is equipped with a battery, when it is not in use, the handy terminal device is put into a suspended state in order to make the battery last longer, and when used, it returns from the suspended state. Resume was generally performed.

Here, in the suspended state, to save power, the working state is saved in the memory or cache memory in the power saving mode, and the operation of the handy terminal device is temporarily performed while the data and programs remain in the working state. Is to stop.
In this case, it is desirable that the time required for the resume is shorter, but if there is a large amount of resume processing or if time-consuming processing is included, it will take time to resume and the time until it can actually be used. However, there is a possibility that the operator may wait.

When the handy terminal device embodiment, including a suspension means to shift to the suspended state when not in use, the resume processing of the device driver definitive when using resumed, a plurality of modules resume processing target device driver can process in parallel, And resume means for proceeding in parallel with the processing of the plurality of modules.

FIG. 1 is an external front view of a handy terminal device according to an embodiment. FIG. 2 is a schematic configuration block diagram of the handy terminal device. FIG. 3 is a diagram illustrating an example of a flowchart of device driver activation processing. FIG. 4 is an explanatory diagram of the processing procedure.

FIG. 1 is an external front view of a handy terminal device according to an embodiment.
The handy terminal device 10 is used for receiving customer orders in restaurants and the like, and a main body case 11 and a door case 12 are connected to each other by a hinge 13 so as to be freely opened and closed.

  The main body case 11 has a backlight (not shown), displays a variety of information, has a size larger than the display 14, is placed on the surface side of the display 14, and the display 14 is not located. A fixed key portion 15 having a plurality of fixed keys arranged therein is provided, and a touch panel 16 for inputting various data is provided, and a portion corresponding to the display 14 of the touch panel 16 functions as a touch panel display.

  The door case 12 has a touch panel 17 having a plurality of operation sections 17A for inputting various data, and an operation area of the touch panel placed on the surface of the touch panel 17 so that menu items can be easily changed. Various menus are displayed in association with each other, and a menu sheet 18 detachably attached to the door case 12 and a menu sheet cover 19 detachably attached to the door case 12 for protecting the menu sheet 18 are provided. ing.

FIG. 2 is a schematic configuration block diagram of the handy terminal device.
The handy terminal device 10 includes a display 14, a touch panel 16, a touch panel 17, a wireless communication interface (I / F) 21 that performs a wireless communication interface operation, an MPU 22 that controls the entire handy terminal device 10, a control program, and the like. ROM 23 that stores various data in a nonvolatile manner, RAM 24 that is used as a working area and temporarily stores various data, and flash ROM 25 that stores firmware and various setting data in a nonvolatile manner and in an updatable manner And an input / output interface (I / F) 26 that performs an interface operation with the display 14, the touch panel 16, and the touch panel 17.

Here, the MPU 22, the ROM 23, the RAM 24, the flash ROM 25, and the input / output interface (I / F) 26 are connected via a bus 27.
In the above-described configuration, the flash ROM 25 stores in advance a device driver startup procedure when performing a resume process for returning from the suspended state. Here, the activation procedure also stores task distribution when the resume process is performed by multitasking.

Next, the operation of the embodiment will be described.
In the following description, a device driver activation process for controlling various devices (display, touch panel, communication interface, etc.) constituting the handy terminal device 10 under the control of the operating system will be described as an example of the resume process.

  In this case, when dividing the device driver as a plurality of resume processes, each resume process does not affect each other (does not interfere with each other) and can be activated independently into a plurality of modules (or module groups). It is assumed that information for specifying each module (or module group) is stored (described) in the flash ROM 25.

FIG. 3 is a diagram illustrating an example of a flowchart of device driver activation processing.
First, the MPU 22 determines whether or not a condition for shifting to the suspend state is satisfied (step S11).
Here, the conditions for shifting to the suspend state include a case where the user gives an instruction to shift to the suspend state, a case where a predetermined time has elapsed since the handy terminal device 10 was last operated, and the like.

If it is determined in step S11 that the conditions for shifting to the suspend state are not yet satisfied (step S11; No), the MPU 22 enters a standby state.
If the condition for shifting to the suspend state is satisfied in the determination in step S11 (step S11; Yes), the MPU 22 performs the suspend transition process, saves the work state in the memory or cache memory in the power saving mode, The program shifts to a suspend state in which the program is saved in the working state and enters a power saving state (step S12).

Next, the MPU 22 determines whether or not the resume processing condition is satisfied, that is, whether or not an instruction to shift to the normal operation state has been given (step S13).
Specifically, when a side key (not shown) of the handy terminal device 10 is operated, the touch panels 16 and 17 are operated, or the door case 12 is opened (for example, detected by a magnetic sensor), the resume is performed. Assume that the processing conditions are satisfied.

If it is determined in step S13 that the resume processing condition is not yet satisfied (step S13; No), the standby state is entered again to maintain the suspended state.
If the resume processing condition is satisfied in the determination of step S13, that is, if an operation satisfying the resume processing condition is performed (step S13; Yes), the MPU 22 stores the processing procedure (startup processing procedure) stored in advance in the flash ROM 25. ) Is read (step S14).

FIG. 4 is an explanatory diagram of the processing procedure.
First, a conventional processing procedure will be described.
Conventionally, when the first device driver to the sixth device driver are incorporated, they are started in order as shown in FIG.

For this reason, the time required for the device driver activation processing is the sum of the time required for the activation processing of each of the device drivers D1 to D6 (= t2-t0).
By the way, in the device driver activation process, there is no possibility of conflict even if a plurality of device drivers are activated in parallel, or when a device driver is composed of a plurality of parts (modules). Alternatively, there may be no risk of conflict even if the module group) and another module (or other module group) are activated in parallel.

In such a case, for example, as shown in FIG. 4B, the third device driver D3 includes a first module group D3M1 and a second module group D3M2, and the first module group D3M1 If there is no risk of conflict even if the second module group D3M2 is activated in parallel at the same time (there is no risk of logical contradiction), these are divided into two and activated simultaneously. Can be performed.
An example of such a module group is a liquid crystal display (LCD) ON sequence in a display device driver when the display 14 is a liquid crystal display.

  As a result, when the activation process of the second module group D3M2 takes the most time in the third device driver D3, the two module tasks D3M2 are activated when two tasks are performed simultaneously as multitasking. The start process of the third device driver D3 is completed in time (start process time = T2).

That is, the entire device driver activation processing time is equal to the time (= T1-T2) obtained by subtracting the time (= T2) required for the activation processing of the second module group D3M2 from the activation processing time (= T1) of the third device driver D3. Thus, the activation process that has conventionally ended at time t2 can be ended at time t1 expressed by the following equation.
t1 = t2- (T1-T2)
Therefore, it becomes possible to start the handy terminal device 10 at high speed.

  Therefore, in this embodiment, the MPU 22 assigns the next device driver to be processed (or a group of modules constituting the device driver) according to the processing procedure read in step S14 during the activation processing of the device drivers D1 to D6. On the other hand, it is determined whether or not there is a device driver or a group of modules that can perform startup processing in parallel, that is, whether or not multitask processing is possible (step S15).

  If it is determined in step S15 that multitask processing is possible (step S15; Yes), the MPU 22 performs processing in parallel with the next device driver to be processed (or a module group constituting the device driver). One or a plurality of possible device drivers or one or a plurality of module groups are read out as a plurality of tasks (step S16), and multitask processing is performed (step S17).

  More specifically, in the case of the example of FIG. 4, the MPU 22 configures the device driver D3 and, when the next processing target device driver is the device driver D3, Module groups D3M1 and D3M2 are read as a plurality of tasks (step S16), and multitask processing is performed (step S17).

  On the other hand, when the multitask processing cannot be performed in the determination in step S15 (step S15; No), the MPU 22 reads the task with the next processing target device driver as a single task (step S18), and performs the single task processing. (Step S19).

  More specifically, in the case of the example of FIG. 4, the MPU 22 determines that the next processing target device is the device driver D1, D2, D4, D5, D6 when the next processing target device driver is one of the device drivers D1, D2, D4, D5, and D6. Task reading is performed with each of the drivers D1, D2, D4, D5, and D6 as a single task (step S18), and single task processing is performed (step S19).

Next, the MPU 22 determines whether or not all tasks corresponding to the processing procedure read in step S14 have been completed (step S20).
If it is determined in step S20 that all tasks corresponding to the read processing procedure have not yet been completed (step S20; No), the MPU 22 proceeds to step S15 again, and thereafter performs the same processing. repeat.

  If it is determined in step S20 that all tasks corresponding to the read processing procedure have been completed (step S20; Yes), the MPU 22 proceeds to normal processing in the handy terminal device 10 (step S21).

  As described above, according to the present embodiment, it is possible to start up the handy terminal terminal at a high speed (reduce the time required for the resume process).

  In the above description, an example in which two tasks are processed in parallel in multitask processing has been described, but it is also possible to configure to process three or more tasks in parallel.

  In the above description, the case where two device driver module groups are processed in parallel in multitask processing has been described. However, the device drivers are configured to be processed in parallel instead of module groups. It is also possible.

  The control program executed by the handy terminal device of the present embodiment is a file in an installable or executable format, such as a CD-ROM, a flexible disk (FD), a CD-R, a DVD (Digital Versatile Disk) or the like. Recorded on a readable recording medium.

In addition, the control program executed by the handy terminal device of the present embodiment may be provided by being stored on a computer connected to a network such as the Internet and downloaded via the network. Further, the control program executed by the handy terminal device of the present embodiment may be provided or distributed via a network such as the Internet.
Further, the control program of the present embodiment may be provided by being incorporated in advance in a ROM or the like.

  Although several embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

DESCRIPTION OF SYMBOLS 10 Handy terminal apparatus 11 Main body case 12 Door case 13 Hinge 14 Display 15 Fixed key part 16, 17 Touch panel 22 MPU
23 ROM
24 RAM
25 Flash ROM
27 bus D1-D6 device driver D3M1 first module group D3M2 second module group

JP 2004-220505 A

Claims (3)

A suspend means for shifting to a suspend state when not in use ;
In the resume processing of the device driver definitive when used for resuming, when having a plurality of modules resume processing target device driver can process in parallel, and resume means for traveling in parallel processing of the plurality of modules,
Handy terminal device equipped with. In the control method executed in the handy terminal device,
Suspend transition process that transitions to the suspended state when not in use,
In the resume processing of definitive device drivers when using resumed, the case where a plurality of modules resume processing target device driver can process in parallel, the resume process which proceeds in parallel processing of the plurality of modules,
Control method with. Control Gyosu Turkey computer the Ha emissions Di terminal equipment,
A suspend means for shifting to a suspend state when not in use;
In the resume processing of the device driver at the time of resuming use, when the device driver to be resumed has a plurality of modules that can be processed in parallel, resume means for proceeding in parallel with the processing of the plurality of modules;
Control program to function as.

Images