Generic Calculator Shield for Arduino Photo-journal

[matthiaspaul]

Well, Marcus, there are some rather "unorthodox" design decisions in your proposed solution... Since you mentioned that you intend to use this as an educational project not just for yourself but also as an example to be taught to others, I assume you are posting this here in order to get some review and constructive feedback. That's why I'd like to comment on some aspects of your design.

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. 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.
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.
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. That is, with four I/Os and four diodes you can already decode twelve keys (instead of four), with six I/Os and diodes thirty keys (instead of nine), and with eight I/Os and diodes 56 keys (instead of sixteen). So, for a keyboard with 35 keys, you'd need seven I/Os and diodes, just two more I/Os than in your current solution, and depending on what else you need, it might be possible to use some of these I/Os for other purposes as well.
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.

On the software side, you should better draw a clear line between code executed inside and outside of interrupt context. As a general rule, reduce the time spent in interrupt context to the absolute minimum possible and don't use expensive or even blocking resources, because this is affecting your real-time performance and if there is more than one interrupt to be processed, there may be race conditions and dead locks resulting in sluggish or erratic behaviour up to crashes. Also, consider the stack load of subroutines called in your interrupt service routine. So, avoid those delays and time-consuming decoding and printing and just 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. While you may not have noticed the ill effects of the current implementation so far, you almost certainly will when things get more complex in the future, and it will be very difficult to track down the actual causes of the problems then.

Hope it helps,

Matthias