Exploring adding setWatch/clearWatch (interrupt handling) to MCP23017 (MCP2308) Portexpander Ports #1007
Replies: 17 comments
-
Posted at 2017-10-30 by @allObjects @gordon, a quick thought for a - first minimal, but quite useful - setWatch enhancement is:
In other words: provide a hook for the application to contribute to the event payload... by extending the existing option with a custom interrupt handler function property. The existing Espruino interrupt handling would - in addition what it already does - invoke the function and stick its return value/object with the other stuff in the JS event/interrupt queue and deliver it as payload to the setWatch callback. I understand your 'voiced' concern about '...it could make Espruino instable...' (as any JS - I do not know the struct of the Js event/interrupt queue entries, but I'm sure that it can hold a reference to an object... This object would then include all what is needed as payload when invoking the setWatch callback. (If it is just one object, then this object would include the current information plus the reference to the additional object. I appreciate if it also includes the setWatch handle and the options object, because it comes handy for the application in the setWatch callback (no extra - globals / variables would then have to hang around). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-10-31 by @gfwilliams
If you're executing an arbitrary JS function for the interrupt itself then surely there's no need to use the setWatch event queue? You could just emit an event, or do any number of other things.
It's worse than that - the interpreter wasn't designed for reentrancy. While I'm allocating variables in IRQs for the nRF52, it's something I'm actually considering taking out. The issue is that occasionally the interpreter will have to do a GC pass - and it'll do that outside of an IRQ. During that time, any IRQs that fires won't be able to allocate variables. But all this seems needlessly complicated - if Espruino isn't too busy, any function supplied to |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-10-31 by @allObjects 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
With these two extensions it is possible to make any watch operation absolutely transparent - for the pin:
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:
The alternative does not support
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 For alternative it works also that the portextender object is passed rather than a pin. The portextender object has then to understand |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-10-31 by @gfwilliams Thanks - I've just filed an issue for that here: espruino/Espruino#1268 I think holding on to a reference to the pin could be a bit painful - however your idea of |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-10-31 by @allObjects That's cool - thank you. In the meantime I use a setWatchX / clearWatchX as stand-in for the respective future implementations. It allows me moving on with the exploration. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-11-01 by @gfwilliams Great - you know you can also do stuff like:
To fix up the existing setWatch implementation to how you want it. Any modules should then use your new setWatch. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-11-01 by @allObjects ...yes, but I didn't want to get into the business of having to determine whether the passed pin is a 'real' / built-in pin or an 'imaginary' / portexpander pin... when I can get it 'for free' from you... ;)... last but not least also because |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-11-01 by @gfwilliams I think Although perhaps checking |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-11-01 by PaddeK Instanceof does work. I would advice against typeof because its not precise enough. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-11-01 by @gfwilliams Ahh - A bit like:
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-11-01 by @allObjects |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-11-05 by @allObjects
And here it is this ... (from post #7):
Espruino (you?) is(are) are not so happy with it - understandably:
If If
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-11-05 by @gfwilliams Try |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-01-16 by @allObjects ... did not share the code I used... let me do it in the state when I hit the wall with the spike caused by Espriuno pin mode change. It is now - 1v95 - fixed. Did not have the time to resume... :( ...yet... :]. Note the rewrite of the rewrite of the MCP23017 module... with the new name MCP23017i2c16w - MCP2317 in i2c 16 bit (default) mode and w atch-able interrupts.
Still to be retested w/ 1v95 |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-11-13 by barbiani Hello @allObjects, Is it useable as it is? It is certainly cool to use signaling from external chips. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-11-15 by @allObjects @barbiani, yes, it should work now. - There was an issue I ran into: the pin mode change produced a spike that erroneously triggered an interrupt. This was mended w/ release of 1v95 as I recall. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-11-16 by @allObjects @barbiani, upadted post #15 with some more comments and consistent namings. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-10-30 by @allObjects
While exploring MCP23017 PortExpander driving 4x4 KeyPad w/ interrupt / setWatch for 'keyDown' detection @gordon posed the question in post #3
This conversation is about exploring the options of that.
As first thing I made a deep dive into the current MCP12017.sjs I2C module and built a test bed - wiring and code - as a solid regression base for adding things and not breaking things (the current code though already breaks things a bit by its different naming... mainly to support my thought process), but that can be reversed.
Test wiring is for 3 ports - for now - involving these Portexpander and Espruino(-Wifi) pins (as taken from the code. -
x.A0
referring Port A0 of Portexpander;var d=...
is there only for high lighting the usually very dim and illegible code comments by this forum's css settings --- fine for focus on code, but not so useful when trying to explain code through 'inline' comments):The breadboard setup is shown in attached screen shot.
Related test output in console looks like this (example: testing digital input):
T## identify Tests, S## identify Setups. Setups are small pieces of code that configure and re/set the ports. They are combined to build a complete setup as part of a test.
...to be continued...
Attachments:
Beta Was this translation helpful? Give feedback.
All reactions