I suspect that we are not looking at the complete picture here. Don't you have some more sensors to add on the I2C? Like accelerometer, magnetometer, maybe light sensor (for auto brigthness) and so on? Maybe battery monitoring?
I see that you are discussing about using I/O expanders and ADC chips. Not to say that IN YOUR CASE you have to use microcontroller - just to show some points that could help you to take the right decision. .
Using I/O expander means that you need several chips - at least two. This will take some board space and pin connections. Don't forget that beside I2C lines (SDA, SCL) you might need some (maybe one, maybe two) interrupt lines. Some clock lines in addition? Also, those simple chips will force you in scanning very often (1ms, 10ms?) about actual data.
Using microcontroller is not easy, that's right. But don't forget that it adds a lot of flexibility. Most modern microcontrollers now have built-in (ROM) bootloader with support for UART, SPI, I2C and so on. I would propose STM32 for example (it is quite well supported by open source tools and code base).
You get low power, low latency processing core - think of filtering, post processing, event detection. Yes, you need to manage firmware update - but this is just because IT IS POSSIBLE to do on the field update (vs fixed function I/O expanders). Some manufacturers (e.g. microchip), and distributors allow ordering chips with pre-programmed user firmware - so no need for programming equipment or JTAG port on the board.
I could imagine that in your case you might even use the microcontroller without precise crystal/ceramic resonator - just with built in RC oscillator (1-2% precision but this does not matter on I2C).
The code itself will not be much of an issue - I suspect that this will be open sourced too so you can get a lot of help on this. So called "sensor fusion" is quite close to your application.
I haven't used yet any of LPC line of Cortex-M microcontrollers from NXP, but I like one of the features - every signal from internal peripheral could be mapped to any microcontroller pin. This means several things:
- you can use all functionalities (internal blocks) without conflicts because of pre-defined "alternative function" mapping - usually this means that you get the smallest possible package to solve your task
- you get the flexibility to change pin mapping later - when the board is ready (but 2 pins were swapped ...)
- you can change pin mapping in runtime - think of using some pins as UART at power on, then switching to I2C
If you have a space USB port on the EOMA, you could put the STM/LPC on the USB. Than use the ready made USB HID examples and feed in your data. Than, use the whole input infrastructure of linux/android and get your events - without coding on the Linux side? (don't know if this is true, just speculating).