all have a consistent API and provided pin objects with read/write/set/reset/mode methods so they worked with the standard functions
is coming from.
For enhanced functionality though, I cannot really go for it, because having hardware moved out into a chip, and try in the module to ignore that make the module completely inflated and cumbersome. It is a pain to impose an architecture on an a different one - structurally and behaviorally.
Said so does not include having both: support the expander efficiently in its architecture and to support Pin behavior for simple input and output as Espruino does it.
I can see my position revised when the portexpander ins integrated natively where things such as digital read and write to pin arrays and clear/setWatch are handled with the knowledge of these capabilities. Why? If you have to setup a complete serial communication multiple times when you can do it in one makes not much sense and worsens the performance experience.
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.
I can understand where
is coming from.
For enhanced functionality though, I cannot really go for it, because having hardware moved out into a chip, and try in the module to ignore that make the module completely inflated and cumbersome. It is a pain to impose an architecture on an a different one - structurally and behaviorally.
Said so does not include having both: support the expander efficiently in its architecture and to support Pin behavior for simple input and output as Espruino does it.
I can see my position revised when the portexpander ins integrated natively where things such as digital read and write to pin arrays and clear/setWatch are handled with the knowledge of these capabilities. Why? If you have to setup a complete serial communication multiple times when you can do it in one makes not much sense and worsens the performance experience.