- **uint8_t keyscan(void)** scans the keyboard once and return result. The keyscan() function cannot detect multiple keys.
**displayRaw()** can display multiple decimal points, by setting the high bit (0x80) in each character for which you wish to have a decimal lit. Or you can use the pointPos argument to light just one decimal at that position.
**displayRaw()** can display some of the alphabet as follows:
- space (blank) is 0x10
- - (blank) is 0x11
- a-f are coded as 0x0a-0x0f
- g-z are coded as 0x12-0x25
So "hello " is coded as 0x13, 0x0e, 0x17, 0x17, 0x1a, 0x10
Calling keyscan() returns a uint8_t, whose value is 0xff if no keys are being pressed at the time. The TM1637 can only see one key press at a time, and there is no "rollover". If a key is pressed, then the values are as follows:
<CENTER>
<TABLE>
<TR>
<TDcolspan =10align="center">
keyscan results are reversed left for right from the data sheet.
To modify a "generic" TM1637 board for use with a keyboard, you must add connections to either or both of pins 19 and 20 (these are the "row" selects) and then to as many of pins 2 through 9 (the "columns") as needed. It is easiest to connect to the "column pins" (2-9) by picking them up where they connect to the LED displays (see second photo). Generic keyboards that are a 4x4 matrix won't work; the TM1637 can only scan a 2x8 matrix. Of course, fewer keys are acceptable; I use a 1x4 keyboard in my projects.
</P>
<P>
Further, the TM1637 chip needs a fairly hefty pull-up on the DIO pin for the keyscan() routine to work. There is no pull-up in the TM1637 itself, and the clone boards don't seem to have one either, despite the data sheet calling for 10K ohms pull-ups on DIO and CLOCK. 10K is too weak anyway. The slow rise-time of the DIO signal means that the "true/high" value isn't reached fast enough and reliably enough for the processor to read it correctly. The new pull-up reduces the rise time of the signal, so that true/high values are achieved in a few microseconds. I find that a 1K (1000) ohm resistor from DIO to 3.3 v works well. This is perfect with a 3.3 volt processor like the ESP8266 or ESP32, and a 5V Atmega 328 ("Arduino UNO") family processor is happy with that as well.
</P>
<P>
The TM1637 boards want to be run off of 5 volts, regardless of what the processor voltage is. Their logic levels are compatible with 3.3 volt processors, and they need 5 volts to make sure the LEDs light up.
</P>
The unmodified generic TM1637 board (front and back).</br>
<IMGsrc="images/unmodified.jpg">
</br>
The modified generic TM1637 board with connector for 1x4 keyboard. The blue wire is bringing out pin 19 (k1). Four segments/columns are picked up from the LEDs.</br>
<IMGsrc="images/modified.jpg">
</br>
The 4 button keyboard plugged into the TM1637 board.</br>
<IMGsrc="images/disp_plus_kbd.jpg"></br>
</br>
Scope photo showing slow rise time of DIO pin (upper trace) on the unmodified TM1637. The lower trace is the CLK. The 8 fast CLK pulses on the left represent the 0x42 command to read keyboard being sent to the TM1637.</br>
<IMGsrc="images/slow_rise.jpg"></br>
</br>
Scope photo showing faster rise time of DIO pin (upper trace) with 1000 ohm pull-up on DIO. In both scope photos, the F5 key is pressed; the bits are least significant bit (LSB) first, so read as 10101111 left to right.</br>
<IMGsrc="images/fast_rise.jpg"></br>
The scope photos were taken using the TM1637_keyscan_raw example, with the scope trigger hooked to the TRIGGER pin, and the two channel probes hooked to DIO and CLK. Vertical sensitivity is 2v/division, horizontal timebase is 20usec/division.
## Keyscan
Implemented in version 0.3.0 Please read the datasheet to understand the limitations.
```
// NOTE:
// on the TM1637 boards tested by @wfdudley, keyscan() works well
// if you add a 910 ohm or 1 Kohm pull-up resistor from DIO to 3.3v
// This reduces the rise time of the DIO signal when reading the key info.
// If one only uses the pull-up inside the microcontroller,
// the rise time is too long for the data to be read reliably.
