MCP23017 PortExpander driving 4x4 KeyPad w/ interrupt / setWatch for 'keyDown' detection

...@Gordon, you go my 6AM brain going with your #3 post...

After a while thinking about what components - hw side / js side - and lifecycle events current setWatch() / clearWatch() entails and what the watch using application needs to contribute - I could see some optional additions in the watch options doing the job. These additions would mirror or replicate in a way all the kind of things you already do for the current 'plain' watches.

For example, there must 'things' that:

• know to pull the data from the interruptor and create payload for downstream
  
• stick the payload into the JS queue for processing by callback in watch
  
• knows when and how to clear and re-setup interrupt depending on watch's repeat option
  
• provide means to detect loss and possibly prevent loosing interrupts
  
• provide access to the watch object (including its option object).
  
  

I'm sure that current STM MC / Espruino interrupt mechanism - including the event queue - is not a trivial thing... and going now through additional 'unpredictable' / semi-robust communication to perform the handling does not make it easier. Yes, it makes it simpler for the application / user, but the easier it is for the user the more complex it is for the system. A If we can find a robust solution along the 80/20 rule, that will be really great.

I said

'unpredictable' / semi-robust communication

because if I2C has an internal error, the whole application crashes... all is dead... a watch dog would have to restart the app, and the app would also have to 'feed' the watch dog properly so that it would not inadvertently restart. There is so much intertwined / layered / micro I2C calls that I have 'no clue' how I could 'easily'/not heavy handed catch internal errors / timeouts / exceptions... it just seems to be messy to me until now.

clearWatch() logically 'maps' to 'disable interrupt'. Therefore it is crucial that the watch object can be accessed by the handle and also options object with it's extension in order to handle things that are not easy to generalize / automate / require user/application involvement at particular life cycle events...

...all sounds... and is still very fuzzy...

I have to gain a bit more experience with the current all-in-application setup and let it mature before making specific suggestions / state requirements. I was also looking into the key matrix module how I could make a leaner version and from that derive change requests for the current setWatch() / clearWatch() / set/clear interrupts via I2c.