• I am not seeing any obvious modification needed to the library as is .... here is my thinking. SPI hardware support is indeed a lot of register poking. Quite a bit of it in fact. The complexity of decoding the registers and making the correct sequence of register pokes is complex. This library has done the hard work of that. It exposes "high level" APIs for driving hardware SPI. For example, it has an API to set the clock speed, it has an API to send/receive bits and to specify the bit length ... and it has an API to determine if an SPI request is currently in progress.

    By treating these capabilities as "black box" then the jsSPISend and related Espruino interfaces become controllers for the black-box capability of the MetalPhreak library.

    If my thinking is sound, then the ESP8266 SPI hardware library would be leveraged "as-is" without any modification upon it. So ... there will be jshardware changes needed ... but these will drive MetalPhreak without ever having to "look inside" the register poking complexities.

    Is this your thinking too?

About

Avatar for Kolban @Kolban started