Intel Edison generic calculator shield photo journal

[MarkHaysHarris777]

(03-30-2015 12:38 PM)Claudio L. Wrote:  I don't see how you could justify the complexity and power of an additional MCU only to read a keyboard matrix. Just passing information from one CPU to the other would be more complex than reading the keyboard directly from the main CPU.

Perhaps not. Allow me to explain how the keyboard scan would work in a more classic way with scan lines and input interrupt lines. I'll attempt to do this without a schematic, and if that is not successful I will also provide the schematic as well (I'm just aching to try "Fritzing")

The first way is simpler; uses the MCU (Edison Quark) and an additional 74HC154 4:16 multiplexer|decoder, 4 scan lines, and 3 input interrupt lines (there may be diodes on the switches (also caps) to help with debouncing, but we'll leave that out for now).

The keyboard matrix is a 'logical' 16x3 matrix. The sixteen logical 'rows' are being scanned continuously (twenty times per second) by the MCU 'counting' from 0 to F on the four lines output to the 74HC154 decoder, which in turn pulls one of the 16 logical row lines low. If a switch is pressed on that 'row' line, then an interrupt will trigger on the associated 'column' input line. ( because we are not using any kind of latch on the scan lines, interrupts will need to be disabled while the counter is being setup and re-enabled once the counter is ready)

Because of contact bouncing, the interrupt routine (one for each logical 'column' ) will need to reaffirm that the logical 'row' is correct and that the button presumed is actually the button being held down. This is done with 'counting' and reading (very simple, just processing).

Assuming the interrupts are immediate, that the scanner 'counter' is paused correctly at the 'row' selected, then the interrupt column ID combined with the scanner counter value can be used arithmetically to arrive at a correct unique key code.

All of that is handled in the MCU (its more than you think). The Quark may be able to handle this quite nicely as well as doing the data gathering (it will take some experimenting).

---

A slightly more complicated way is to place a serial shift register with latch enable between the 74HC154 and the key matrix. This reduces the overall lines from the MCU to six... three to talk to the shift register (SPI), and three input interrupt lines. Logically, the idea is still the same; the keyboard is scanned continuously by the MCU until an interrupt fires (the key is affirmed and passed on to the analytics) and the scanning resumes.

One way to handle this is to put the dedicated MCU on the keyboard backplane (atmega328) along with the support chips. Then have the 'keyboard' talk to the Edison via SPI or via I2C. (I really cannot believe someone has not built a generic keyboard for these kinds of purposes yet)

There is definitely more than one way to skin this possum, as it were. Back in the day we used specialized chips like the 8279 and 8250 to handle keyboard matrix scanning|decoding. But, we don't need the 8279 these days because we have our own MCU and we can do it our way... theoretically.



Cheers,
marcus