Generic Calculator Shield for Arduino Photo-journal

[MarkHaysHarris777]

(03-23-2015 05:29 PM)matthiaspaul Wrote:  Well, Marcus, there are some rather "unorthodox" design decisions in your proposed solution...

hi matthias, good to hear from you... thank you for your ideas! The idea for this 'unorthodox' design is the kiss principle; keep it simple sweetheart!

(03-23-2015 05:29 PM)matthiaspaul Wrote:  The first is your choice of an analog readout of the keyboard. While this may work for a few keys, it would become unreliable if you'd need to work with more keys per row. Also, it needs hardware or software calibration or active compensation to make it work over a large batch and long time frame and with different voltages.

Not really. True, there needs to be enough resolution on the analog input, which of course the edison and the arduino do brilliantly. Mathematics (simple arithmetic) handles the callibration... even between 1v8, 3v3, and 5v. It works famously.

(03-23-2015 05:29 PM)matthiaspaul Wrote:  It is prone to EMI problems (you will get misreadings near EMI sources), is slow compared to a digital readout and it consumes more energy. All this would make it unsuitable for "commercial grade" applications in mobile devices like calculators, I'm afraid.

As I stated earlier, its is VERY unreliable (that's a given). This is a 'little' like TCP/IP... which is by definition a VERY unreliable protocol (that's the beauty of it). We compensate for the inherent flaws of the hardware (kiss principle) by creating quality firmware to handle the eventual and predictable failures... works famously, and keeps things very simple and easy to build (for DIY community).

(03-23-2015 05:29 PM)matthiaspaul Wrote:  I understand that you need to save I/Os, however, if the current board does not have enough I/Os, perhaps it's not the best possible choice for the job - after all, there are controllers with lots of I/Os.

Saving I|O lines on the Due or the Edison is not an issue... the issue is that this calculator shield is generic and general purpose... is being designed to run on multiple boards, with multiple firmwares (from 4 banger to programmable plotter).

(03-23-2015 05:29 PM)matthiaspaul Wrote:  While a typical keyboard matrix reduces the number of necessary I/Os for (N/2)^2 keys to N already, using some diode tricks you can increase the number of necessary keys to N^2-N.

Interesting idea. I am using four I|O lines and one interrupt line. Polling is not an option. Do you have a proposed schematic; more details would be good.

(03-23-2015 05:29 PM)matthiaspaul Wrote:  Since you are following a distributed controller paradigm anyway, you might also have a look at dedicated keyboard matrix scanner ICs to reduce the number of necessary I/Os on your main controller.

This is a good idea... a dedicated AVR for keyboard handling is essentially the way all PC keyboards work...

(03-23-2015 05:29 PM)matthiaspaul Wrote:  On the software side, you should better draw a clear line between code executed inside and outside of interrupt context. . . stuff the read values into a circular buffer and leave the evaluation and interpretation of the values in the ring buffer to code executed outside interrupt context, so it won't block anything.

Yup. The actual interrupt routines are far from 'ready'. My simple 'driver' code is meant only as proof of concept on a very simple, if 'unorthodox' approach to click-button key encoding. There will be scads of revisions along the way, I'm sure of that.

Thanks again, I'll keep all of this in mind... and I'm gonna want to investigate the diode idea. Thanks.

Cheers,
marcus