You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
I took a deep dive into the MCP23017 (I2C) Portexpander module (and rebuilt - no offense to be taken here) to understand it's wokings and prepare a test bed with full regression. So fare, regression includes validating reset and input only (activities are jotted down separate conversation: Exploring adding setWatch/clearWatch (inerrupt handling) to MCP23017 (MCP2308) Portexpander Ports).
While working through the code, I rethought the interrupt story... to the point where I'm thinking to add watch function to the portexpander pins and hide the fact that this makes only one watch in Espruino. The part from JS IRQs would only be for putting the application service request into the queue instead of calling the watch callbacks 'myself' (in a setTimeout to defer), in order to make the interrupt service routine to behave more like a hardware interrupt than a software interrupt... and achieve in shorter handling. I'm worried about loosing interrupts/events. This is anyway something that has to be looked into because while I2C communication with the portexpander goes on to deal with an interrupt, interrupt is disabled until port register or interrupt capture register is read. Port register may already be different from interrupt register because port register - as by definition - delivers the pin states when read, interrupt capture register - as by definition - captures/latches the pin states when the interrupt happened. In 8 bit portexpander (23008) and 16 in portexpander (23017) in 8-bit mode with separate, non-mirrored AB interrupt pins, the register latch 8 bit at once. In 16 bit / mirrored mode (AB interrupt pins), the registers latch 16 bit at once. Teasing out the details - which pin caused the interrupt from flag register(s() and what was its state at interrupt time from capture register(s) - by parsing the 8/16 bits and invoking (or placing into a queue) the application interrupt/watch callback for the related pins is an interrupt service routine by itself... like a service to the service...
As said, still in the phase of completing the test bed for current functionality. After that I will venture into adding watch capabilities in one or the other ways to the Portexpander Ports.
In respect to a Keypad solution, it could be just one dedicated keypad module specific to the use of a Portexpander rather than two modules - a module for a keypad using a module for interrupt enabled Portexpander...