Exploring adding setWatch/clearWatch (interrupt handling) to MCP23017 (MCP2308) Portexpander Ports

I guess I understand what your are saying about reentrance...

I also conclude that the process is to complex and variable to be implemented without memory resources that are exposed to potential GC.

I though still expect/require a modification to existing setWatch() and clearWatch() functions in order to make it transparent for the application whether it is a built-in pin or or an extension-pin (a pin of any sort of portextender):

• a) setWatch() has to:
  
  1. invoke .setWatch() method on passed the extender pin and pass the callback and options object.
     
  2. hold on to passed portextender pin object in the internal watch object (for any clearWatch() down the line).
     
• b) clearWatch() has to:
  
  1. invoke .clearWatch() method on the held-on portextender pin object(s - plural, when clearWatch is called without arguments).
     
     

With these two extensions it is possible to make any watch operation absolutely transparent - for the pin:

• setWatch()
  
• clearWatch() with watch ID / handle as argument
  
• clearWatch() without argument
  
  

Should a)2. - holding on to passed portextender pin object in the internal watch object for any reasons - such as potential memory leak - not be possible, then this alternative is good enough:

• setWatch has to:
  
  1. ONLY return the passed portextender pin object reference as the watch ID (rather than just an integer number) and nothin else.
     
• clearWatch has to:
  
  1. detect that the passed-in watch ID is a portextender pin
     
  2. invoke .clearWatch on the portextender pin
     
  3. nothing else since there exists no internal watch info
     
     

The alternative does not support clearWatch() with no arguments, and - from my point of view - this is acceptable, because using clearWatch() with no arguments has anyway its challenges. Still transparent to the pin are:

• setWatch()
  
• clearWatch() with watch ID / handle as argument
  
  

With the alternative, Espruino has to store nothing about the watch. Non-built-in, portextender pins trigger the redirect of the argument(s) for both .setWatch() and .clearWatch().

For alternative it works also that the portextender object is passed rather than a pin. The portextender object has then to understand .setWatch() and .clearWatch, which could set interrupts for groups of pins. The implementations can even go that far, that .setWatch() can return any custom object deemed useful in the watch life cycle, as long as built-in clearWatch() can detect that passed in 'pin' object is not a built-in pin.