JPS6217247B2 - - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION Description of the technical field to which the invention pertains The present invention relates to keyboard control that allows key attributes to be set arbitrarily.

Description of the Prior Art A conventional keyboard device is composed of a key matrix, a key control section, and a ROM as shown in Fig. 1. When a key is pressed, the key control section and the ROM control the key matrix. It is determined whether the pressed key is valid or invalid, and if it is valid, the character code corresponding to the pressed key is transferred to the master side. In the above operation, the determination of whether each key is valid or invalid and the character code are fixed corresponding to the key. Therefore, there was a drawback that a new keyboard device had to be created every time there was a change in the key arrangement on the keyboard or a change in the meaning of the keys.

Purpose of the Invention The present invention is characterized in that the attributes of the keys on the keyboard can be arbitrarily set, and its purpose is that even if the key arrangement or the meaning of the keys is changed, there is no need to create a new keyboard control device. The purpose of this invention is to provide a keyboard device, which will be described in detail below.

Explanation of the structure, operation, and effect of the first embodiment FIG. 2 shows the first embodiment of the present invention, and shows
is a keyboard matrix, and each key is arranged on the matrix. 22 is slave
This is the CPU and samples the key matrix code and performs various controls for the keyboard device. Reference numeral 23 denotes a slave memory, in which operating programs for the slave CPU and various tables are stored.

24 is the TRC on the keyboard side. Key matrix 21, slave CPU, slave memory 23,
The TRCs 24 are connected to each other by bus lines 10.

25 is a master side TRC, and the master side TRC and the keyboard side TRC are connected to each other by four wires in this example to control data transmission and reception.

26 is a master side control CPU, and 27 is a master side program memory and memory for various tables.

Master side TRC25, master side control CPU2
6. The master side memories 27 are connected to each other by the bus line 11. Details inside the slave memory will be explained with reference to FIGS. 3, 4, and 5.

Figure 3 shows the details of the attribute table, and shows which character or symbol of each shift the key placed at each position is assigned to or not (hereinafter sometimes referred to as the attribute of that key). .)
decide.

In this example, 2 bytes are allocated to each key. The first byte of the two bytes assigned to each key is a position table, which indicates which byte and bit in the lock release table (described later) the key assigned to these two bytes corresponds to. .

That is, the lower three bits of this position table indicate the bit position, and the upper five bits indicate the byte position. For example, if the position table contains "00011100", the upper 5 bits are 3, indicating the 3rd byte of the lock/release table, and the lower 3 bits are 4.
Therefore, this shows that it corresponds to the fourth bit _b3 of that byte.

Therefore, the correspondence relationship can be changed arbitrarily by rewriting the contents of the position table.

The second byte is a table indicating the shift status, for example, the fourth bit _b3 , the sixth bit _b5 , and the seventh bit
If the three bits of bit _b6 are 1 (or 0), this indicates that the kana symbol, alphanumeric character, and kana are displayed on the key top of the key.

FIG. 4 shows the details of the lock/release table, which consists of, for example, 32 bytes (the maximum that can be represented by the above-mentioned byte positions). As mentioned above, each bit corresponds to what that bit represents in the position table described above.

For example, if a certain bit is 1, it indicates the locked or released state of the key corresponding to that bit, and even if the corresponding key is pressed while in the locked state, it will be invalid. This lock/release table is sequentially rewritten by commands from the master side in accordance with the progress of transactions and the progress of input into formats such as forms. That is, the currently pressed key is a key that should not have been pressed at that time, and is determined to be an operation error. If it is "1", the pressed key is in a released state, indicating that there is a possibility that it will be pressed.

For example, in a certain transaction, in the process of inputting an amount of money, the numeric key group becomes "1".

If the bit in the lock/release table corresponding to the pressed key is in the released state, then the shift stored in the second byte of the corresponding address in the attribute table and the shift in the shift mode table shown in FIG. It matches the state, and if it does not match, it is invalidated as a key press error.

For example, when kana is to be input now, kana shift b ₆ is set to "1" in the shift mode table according to an instruction from the master side. However,
If kana is not assigned to the pressed key, 2 in the attribute table corresponding to that key
Since the kana shift bit of the byte is "0", there is a mismatch and the data is determined to be invalid. Also, if they match, the pressed key is judged to be valid,
The key matrix code is transferred from the TRC 24 to the mask side.

To explain this according to FIG. 6, when the slave CPU detects a key press, the slave CPU refers to the attribute table on the slave memory. b ₇ to _{b 3} of the position table on the attribute table specify the byte position on the lock/release table,
_b2 to _b0 specify bit positions on the lock/release table. This determines the position on the lock/release table for the pressed key, and if the content of the bit position is ``0'', the pressed key is determined to be invalid, and if it is ``1'', the pressed key is determined to be in the released state. Ru. If it is in the released state, then check the shift on the attribute table and the shift on the shift mode table, and if they do not match, the key press is invalid, and if they match, the press is valid and the key matrix code is transferred to the master side. do.

Explanation of effects of the first embodiment As explained above, in the first embodiment, the attributes of the keys arranged on the keyboard can be changed arbitrarily by the attribute table transferred from the master side to the slave memory. Therefore, when designing a keyboard with a different key arrangement or key attributes, there is no need to change the matrix decoder ROM or to design a new keyboard circuit.

In addition, in this example, there is a slave CPU on the keyboard side.
Since the keyboard is provided with a slave memory and connected to the master side via the TRC, the keyboard side and the master side can be installed in separate locations.

Explanation of the second and subsequent embodiments In the first embodiment, the key matrix was converted to an arbitrary code on the master side, but on the seventh
By providing an encode table in the slave memory as shown in the figure, any code can be transferred to the master side. Next, FIG. 8 shows the operation flow after pressing the key in FIG. 7.

The operation will be explained below according to the flow shown in FIG. When the slave CPU detects a key press, the slave CPU refers to the attribute table on the slave memory. _B7 to _b3 of the position table on the attribute table specify byte positions on the lock/release table, and _b2 to _b0 specify bit positions on the lock/release table. This determines the position on the lock/release table for the pressed key, so if the content of the position is "0", the pressed key is invalid, and if it is "1", the pressed key is determined to be in the released state. If it is in the released state, then the shift on the attribute table and the shift on the shift mode table are matched, and if they do not match, the key press is invalid, and if they match, the key press is valid. Next, the encode table is referred to and the code corresponding to the pressed key is transferred to the master side.

As explained above, in the second embodiment, the attributes of the keys arranged on the keyboard can be arbitrarily changed using the attribute table, release table, shift mode table, and encode table transferred from the master side to the slave memory. Therefore, when designing a keyboard with a different key arrangement or key attributes, there is no need to change the matrix decoder ROM, and there is no need to design a new keyboard circuit.

In the first and second embodiments, the keyboard side and the master side were connected via TRC, but as shown in Fig. 9, the connection between the keyboard side and the master side was changed.
It is also possible to connect via parallel bus without using TRC. In FIG. 9, the encode table, attribute table, lock/release table, and shift mode table on the slave memory are transferred from the master side.

The third embodiment has the same table configuration on the slave memory as the second embodiment, but since the keyboard side and the master side are connected in parallel without going through the TRC, there is no need for TRC line control, and the program This results in a reduction in overhead.

Explanation of effects of the invention and description of the field of application The present invention provides an attribute table corresponding to the keys arranged on the keyboard in a rewritable memory, so that the attribute table can be arbitrarily rewritten from the master side. Since the attributes of each key can be made variable, it can be used to create different keyboards for different users of bank teller terminals and the like.

[Brief explanation of the drawing]

Fig. 1 is a block diagram of a conventional keyboard device, Fig. 2 is a block diagram of a first embodiment of the present invention, Fig. 3 is a key attribute table, Fig. 4 is a lock/release table,
5 is a shift mode table, FIG. 6 is an operation flow of the first embodiment, FIG. 7 is a configuration diagram of the second embodiment, FIG. 8 is an operation flow of the second embodiment, and FIG.
The figure is a configuration diagram of the third embodiment. 21...Key matrix, 22...Slave
CPU, 23...Slave memory, 24, 25...
...TRC, 26...Master CPU, 27...Master memory.

Claims (1)

[Claims] 1 The keyboard side includes a key matrix that sends out a predetermined signal when specified, and at least
A control program, an attribute table consisting of a position table in which each address corresponds to each key on the key matrix and specifies the position of that key, and a shift table indicating the shift state assigned to the key top, and an attribute table corresponding to a certain key. A lock/release table that stores whether or not the corresponding key can be pressed now according to the bit specified in the position table of the address to be pressed, and a shift mode that indicates the shift mode of the key that should be pressed now. a slave memory having a table;
The master side is equipped with a CPU that performs processing according to the program stored in the slave memory.
A master memory that stores at least a control program, and the contents of the position table, lock/release table, and shift mode table on the slave side can be rewritten and controlled according to the program stored in the master memory. What is claimed is: 1. A keyboard device comprising: a master side CPV; and by arbitrarily rewriting the contents of the slave memory by the master CPU, attributes corresponding to each key on the keyboard are made variable.