JPH0221318A - Key input device - Google Patents

Abstract

PURPOSE:To realize a high-speed key input operation and to avoid the omission of the key input data by setting a buffer between a key input data processing part and a key input data conversion processing part. CONSTITUTION:A buffer 31 is set between a key input data processing part 3A which processes the input data and a key input data conversion processing part 4 which converts the input data. In the case the part 4 is not working at a key input time point, the key input data are not stored temporarily in the buffer 31 but given instantaneously to the part 3A. Thus the key input data are stored in the buffer 31 only when the key input data cannot be processed owing to a fact that the part 4 is working at the key input time point. Then the next key input data or the data stored in the buffer 31 are given to the part 3A in the case the part 3A is not working. Thus the high response is secured with no omission of the key input data.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a key input device for a computer, and more particularly to a key input device with a processing method suitable for an input device in which data is input discontinuously and asynchronously.

[Conventional technology]

Conventional key input devices temporarily store data input from the keyboard in a buffer, and then transfer the data stored in the buffer to the key input data conversion processing section, which is a kana-kanji conversion processing section, where the conversion processing is performed. Ta.

There was also an event-driven key input device that passed the key input directly to the application at the same time. Note that related devices of this type include 1, for example, Japanese Patent Application Laid-open No. 61-7
No. 5914, JP-A-61-86830, JP-A-61-
86826 and the like.

FIG. 7 is a functional block diagram illustrating a conventional event-driven key input device. In FIG.

1 is the keyboard, 2 is the keyboard controller.

3 is a keyboard driver (key input data processing unit);
4 is an application (key input data conversion processing section).

FIG. 8 is a flow chart of the keyboard controller 2 of FIG. In FIG. 8, the keyboard controller 2 constantly monitors the state of the keys on the keyboard 1 to see if any key operations have been performed (Process 2a), and when a key operation has been performed, an interrupt is generated and information regarding the position of the operated key is generated. Notify the data to the keyboard driver 3 (processing 2b
).

FIG. 9 is a flowchart of the keyboard driver 3 of FIG. In FIG. 9, keyboard driver 3
is stored in the RAM as a part of the operating system O8, and receives data regarding the position of the operated key from the keyboard controller 2 and converts the data into internal data. 3a) Then transfers it to the application 4. Check whether the permission flag is ON or not and process 3.
b), if ON, transfer to application 4; process 3c), OFF, end.

FIG. 1O is a flowchart of application 4 of FIG. In FIG. 10, the event-driven application 4 has a transfer permission flag, and receives and receives key data transferred from the keyboard driver 3 (processing 4).
a) After turning off the transfer permission flag (processing 4b)
, the receiver performs processing on the received key data. For example, if the application (key input data conversion processing unit) 4 is a Japanese word processor, the processing involves converting it into kanji and displaying it on the screen ( Process 4c), after completing this process, turn on the transfer permission flag (process 4d)
).

The reason why the transfer permission flag is required here is that even though the application 4 is processing the received key data, there is a key input and the key data is transferred from the keyboard driver 3 to the application 4. This is because if the key data is transferred to the application 4, the key data currently being processed by the application 4 will be overwritten and destroyed by the key data to be processed next. Therefore, a transfer permission flag is provided to indicate whether or not the application 4 allows transfer to the keyboard driver 3, and the application 4 turns the transfer permission flag OFF during processing to prohibit transfer from the keyboard driver 3. ing. However, if there is a key input when the transfer permission flag is OFF, the keyboard driver 3 ends the process, so even though the key input should have been made, the application 4
A phenomenon occurs in which key input data is not received.

In other words, with event-driven key input devices, if the processing time for application 4's key input data is longer than the interval between the user's keystrokes, a problem occurs in which the key input data is lost. It is.

FIG. 11 is an explanatory diagram of a specific execution progress of the key input process of FIG. 7. In Figure 11, time is plotted on the horizontal axis,
The vertical axis shows the processing content of the application 4, the state of the transfer permission flag, the key data transferred by the keyboard driver 3, the key interrupt timing (arrow), and The contents of the typed keys are illustrated in the form of a table. In this specific example, for the sake of simplicity, it is assumed that the application 4 is a program that displays key input data as it is, and that key inputs are made using the A key, B key, and C key at high speed. Here, when the A key is input, the transfer permission flag is ON, so the transfer from keyboard driver 3 to application 4 is successful, and application 4
J is displayed, but when the B key is subsequently input, application 4 is in the process of displaying rAJ and the transfer permission flag is OFF, so the transfer from keyboard driver 3 fails and is not transferred. If data is missing and the C and D keys are input, do the same thing.
The data transfer for the key is successful and "C" is displayed, but then the data transfer for the D key fails. Even though I entered the A key, B key, C key, and D key as a result,
This causes a problem where only two characters, "A" and rCJ, are displayed on the screen.

[Problem to be solved by the invention]

In the above conventional technology, in the key input method of an application of a key input device that stores data in a buffer, a key input interrupt is first generated when a key on the keyboard is pressed, and then a key input interrupt process is performed to process the key input data. After being activated and converted into a key code corresponding to the input key, it is temporarily stored in the key input data buffer.

Next, when the application program requires key input data, it requests the key input data from the ``key input data processing'', and the ``key input data processing'' uses the key input data stored in the key input side input processing as the key input data. If it exists in the input data buffer, that data is passed to the key input data conversion processing section.

If it does not exist, only the information that there is no key input data is returned.This prevents key input data from being lost when the application issues an input request and processes that data.

However, when using this key input method, multiple application programs operate on a time-sharing basis.

For example, if there are two programs, application A and B, on the screen of application A, for example 1, 2
．． When the time has elapsed after you keyed in 3, control is transferred to B, and if you keyed in 4.5, 6 on B's screen, 1, 2.3, 4.5, 6 are stored in the key input data buffer. Because it's in.

There is a problem in that when application B makes an input request at step 22, the key input data 1, 2, 3 that should have been input at A is taken into B.

Further, in a key input method for an application of an event-driven key input device, the above-mentioned problem of the key input method that is temporarily stored in a buffer is solved.

In applications that operate on a time-sharing basis.

It is event-driven in that the data is passed directly to the application as soon as a key is entered. However, there has been a problem in that during key input processing, key input data input during that time cannot be processed, and key input data is likely to be lost.

An object of the present invention is to provide a key input device that can prevent key input data from being lost in event-driven applications.

[Means to solve the problem]

The above purpose is to convert the key input data at the time of key input by providing a buffer between the key input data processing section that processes input data and the key input data conversion processing section that converts the input data. If the processing unit is not processing the key input data, it is immediately passed to the key input data conversion processing unit without storing it in the buffer, and when the key input data is input, the key input data conversion processing unit Therefore, only if the key input data cannot be processed, it is stored in the buffer, and then when the key input data conversion processing section is not processing, the next key input data or the data stored in the buffer is used as the key input data. This is achieved by a key input device that is passed to the conversion processing section.

[Effect]

The key input data processing section of the key input device has a function of converting the data input through the key t into a unique code and sending it to the key input data conversion processing section. During processing, it returns information that "data can be received" to the key input data processing section, converts the key input sent from the key input data processing section, and also returns the key input data to the key input data processing section. The key input data processing unit returns the information "data cannot be received" to the data processing unit and continues the conversion process of the data currently being processed in the TIL, while the key input data processing unit returns the information "data cannot be received" from the key input data conversion processing unit. If "not possible", the key input data is temporarily stored in the buffer, and if "r data can be received", the key input data or the data temporarily stored in the buffer is sent to the key input data conversion processing section, and such The operations of the key input data processing section and the key input data conversion processing section can ensure high responsiveness from key input to input data conversion without missing any key input data.

〔Example〕

An embodiment of the present invention will be described below with reference to FIGS. 1 to 6.

FIG. 5 is a block diagram of a personal computer showing an embodiment of the key input device according to the present invention. FIG. 6 is an external view of FIG. 1. 1 in Figures 5 and 6
The overall configuration of a personal computer to which the present invention is applied is shown, in which 1 is a keyboard, 20 is a main body of a processing device,
30 is a display device. 21 is the processing department! 20 microprocessors (MPU), 22 a read-only storage device (ROM), and 23 a readable/writable storage device!
(RAM), and SC is the display screen of the display device 30. The keyboard 1 has a large number of keys arranged, and by pressing each key, predetermined character data is input to the processing device 20. The processing device 1120 includes MPU21 and R
Equipped with OM22 and RAM23, MPU21 is RO
A display device 30 that reads a program stored in M22 or RAM 23 and executes predetermined processing specified by the corresponding program displays the results of these processings, input results from the keyboard 1, etc. on its display screen SC.

FIG. 1 is a functional block diagram showing an embodiment of a key input device according to the present invention. In FIG.

The same symbols as in FIG. 7 indicate corresponding parts, 1 is the keyboard;
Reference numeral 2 denotes a keyboard controller 3A, which is a keyboard driver (key input data processing section) according to the present invention, 31 a buffer according to the present invention, 4 an application (key input data conversion processing section), and 5 a timer according to the present invention. In the embodiment shown in FIG. 1, according to the present invention, a buffer 31 is provided in the keyboard driver 3A between the keyboard driver 3A and the application 4, and when the transfer permission flag is OFF, some key data is transferred to the buffer 31. , and the timing of occurrence of a keyboard interrupt from the keyboard controller 2 or a timer interrupt from the timer 5 makes it possible to reduce data loss without changing the structure of the event-driven application 4. . Note that the functions of the keyboard 1, keyboard controller 2, and application 4 are similar to those of the conventional event-driven key input device shown in FIG. In this embodiment, the timer 5 is for example 500 m.
It is assumed that a timer interrupt is generated every sec.

The functions of the keyboard controller 2 of FIG. 1 are similar to the flowchart of the conventional keyboard controller 2 of FIG. 8. The keyboard controller 2 constantly monitors the state of the keys on the keyboard 1 to see if any key operations have been performed (process 2a), and when a key operation has been performed, generates a keyboard interrupt, and generates data regarding the position of the operated key. to the keyboard driver 3 (processing 2b).

FIG. 2 is a flowchart of the keyboard driver 3A shown in FIG. In FIG. 2, a keyboard driver 3A according to the present invention is stored in the RAM 23 as a part of the operating system O8, as in the conventional case, and receives data regarding the position of an operated key from the keyboard controller 2. Process 3a) to convert the data to internal data, then check whether the transfer permission flag of application 4 is ON or not and process 3b). If the transfer permission flag is ON, apply 4 as before.
(Processing 3c), but in the case of OFF, the data is stored in the buffer 31 provided in the keyboard driver 3A according to the present invention without ending as in the conventional method shown in FIG. 9 (Processing 3d). .

FIG. 3 is a detailed flowchart after the storage process in the process 3d of storing in the buffer 31 of FIG.

In FIG. 3, the key input data stored in the buffer 31 in the buffer storage process 3d is set to the transfer permission flag of the application 4 at the timing when a keyboard interrupt of the keyboard controller 2 or a timer interrupt of the timer 5 occurs. Please refer to Process 3e
), the process ends if it is OFF. If it is ON, check whether there is transfer data in the buffer 31 (processing 3f), and if there is no transfer data, end, and if there is transfer data in the buffer 31, transfer the data to the application 4 (processing 3g), after that, the same process is repeated at the timing of the keyboard interrupt of the keyboard controller 2 or the timing of the timer interrupt of the timer 5, for example, every 500 m5ec.The buffer 31 has a ring counter structure and is a first-in, first-out type. shall be.

The functions of the application 4 in FIG. 1 are similar to the flowchart of the conventional application 4 in the 10th issue. The event-driven application 4 has a transfer permission flag, and receives key data immediately transferred from the keyboard driver 3A without being stored in the buffer 31, and key data transferred from the buffer 31 at the timing of a keyboard interrupt or timer interrupt. Peeling (processing 4a
), and after turning off the transfer permission flag (processing 4b),
The receiver performs processing on the received key data (processing 4)
c), Turn on the transfer permission flag after this process is completed (
Process 4d).

FIG. 4 is an explanatory diagram of a specific execution progress of the key input device of FIG. 1. In FIG. 4, the horizontal axis shows time, and the vertical axis shows the processing content of application 4, the state of the transfer permission flag, and the keys transferred by keyboard driver 3A. - The data and the timing of key interrupts (arrows) and the contents of the keys typed and the timing of timer interrupts (arrows) are illustrated in the form of a table. Furthermore, in this specific example, for the sake of simplicity of explanation, application 4 is a program that displays key input data as is, similar to the conventional example shown in FIG. Assume that it was done at high speed. Here, when the A key is input, the transfer permission flag is ON, so the transfer from the keyboard driver 3A to the application 4 is successful, as in the conventional example shown in FIG. 11, and the application 4 displays "A". However, when the B key is subsequently input, the application 4 is in the process of displaying rAJ and the transfer permission flag is OFF. According to the present invention, part of the key data is stored in the buffer 31, and the C key of The B key was successfully transferred and rB was retrieved by the key interrupt when .
J is displayed. In addition, a part of the C key and the next D key are also stored in the buffer 731, but the key data of the C key and D key stored in this buffer is set to the transfer permission flag when the timer interrupt occurs. In each case, the transfer to application 4 is successful, and rB
J is displayed, and then rDJ is displayed. In this way, if there is no key interrupt for a while after the D key is input due to a key interrupt, and the time interval until the next key input is long, the key data temporarily stored in the buffer 31 is stored at the timing when the timer interrupt occurs. Can be transferred to application 4. As a result, the key input data is transferred to the application 4 without missing, and the application 4 displays the event-driven key input data as "A", "rBJ", and "C" rDJ, respectively. It is possible to reduce the loss of key input data during input.

〔Effect of the invention〕

According to the present invention, key input data is converted without interruption, enabling high-speed key input with high responsiveness, and eliminating the possibility of missing key input data in event-driven applications.

[Brief explanation of the drawing]

FIG. 1 is a functional block diagram showing an embodiment of the key input device according to the present invention, FIG. 2 is a flowchart of the keyboard driver shown in FIG. 1, and FIG. 3 is a detailed flowchart of the keyboard driver shown in FIG. Figure 4 is an explanatory diagram of the execution progress of the key input in Figure 1, Figure 5 is a block diagram of the personal computer in Figure 1, Figure 6 is an external view of Figure 5, and Figure 7 is the conventional key input. 8 is a flowchart of the keyboard controller of FIG. 7, FIG. 9 is a flowchart of the keyboard driver of FIG. 7, FIG. 10 is a flowchart of the application of FIG. 7, and FIG. 11 is a functional block diagram illustrating the device. The figure is an explanatory diagram of the execution progress of the key input in FIG. 7. DESCRIPTION OF SYMBOLS 1... Keyboard, 2... Keyboard controller, 3A... Keyboard driver (key input data processing section), 31... Buffer, 4... Application (key input data conversion processing section), 5 ...Timer 20--Processing device, 21.MPU, 22.ROM. 23...RAM, 30...Display device. Diagram: Diagram: Diagram: Diagram: Diagram: Fuzu: Dormitory diagram: Diagram: Diagram

Claims (1)

[Claims] 1. A key input device consisting of a key for data input, a device for processing key input data, a storage device for storing key input data and data necessary for processing, and a display device for displaying key input data and processing results. The key input data is temporarily stored between the key input data processing unit that processes the key input data and the key input data conversion processing unit that converts the key input data when the key input data conversion processing unit is in process. A key input device characterized by being provided with a buffer.