@profra
Good post. I am not familiar with Lua which I think is the language that I think is used in this binding. NodeMCU has two stories ... one is an ESP8266 board (which should be able to run the Espruino port) and the other is their IDE/Lua language. The APIs that you listed match almost exactly the "C" language bindings supplied by the ESP8266 SDK. (The ESP8266 is made by a company called Espressif ... this is the raw IC that IS the ESP8266 which board makers then include in their boards. Espressif provides a C language set of libraries that can be linked with a C application to achieve WiFi, network, GPIO, timers etc etc ... it is this SDK API that is being leveraged by the Espruino support for the board specific capabilities).
I had assumed that we had walked this space before and there would have been a prescribed strategy that the ESP8266 support would simply "follow" ... however, I'm starting to get the impression that this may be "relatively" new ground. What I think I'll do is do the deep research and make up a "report" on the different APIs that are being used now for networking in Espruino today as well as the APIs being used by ESP8266. However, I believe I want to stay away from anything that would smell of ESP8266 specific ... the goal should be that the ESP8266 should be "just another board" and even if I arrive at Espruino as a skilled ESP8266 kind of guy ... the story should be that this is an Espruino story. To make progress and allow testing, I'm thinking of continuing design and implementation with a class name that may be "EXPRIMENTAL_ESP8266.". Obviously that will not be the final method name or structure but changing names and parameters will be simple once we figure out the API structure we want while at the same time not blocking anyone who wants to continue with the board support. I don't want to stall through analysis paralysis and as long as the method names have no ambiguity that they have not been finalized, we should be ok and not accidentally make something that would lock us in ...
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.
@profra
Good post. I am not familiar with Lua which I think is the language that I think is used in this binding. NodeMCU has two stories ... one is an ESP8266 board (which should be able to run the Espruino port) and the other is their IDE/Lua language. The APIs that you listed match almost exactly the "C" language bindings supplied by the ESP8266 SDK. (The ESP8266 is made by a company called Espressif ... this is the raw IC that IS the ESP8266 which board makers then include in their boards. Espressif provides a C language set of libraries that can be linked with a C application to achieve WiFi, network, GPIO, timers etc etc ... it is this SDK API that is being leveraged by the Espruino support for the board specific capabilities).
I had assumed that we had walked this space before and there would have been a prescribed strategy that the ESP8266 support would simply "follow" ... however, I'm starting to get the impression that this may be "relatively" new ground. What I think I'll do is do the deep research and make up a "report" on the different APIs that are being used now for networking in Espruino today as well as the APIs being used by ESP8266. However, I believe I want to stay away from anything that would smell of ESP8266 specific ... the goal should be that the ESP8266 should be "just another board" and even if I arrive at Espruino as a skilled ESP8266 kind of guy ... the story should be that this is an Espruino story. To make progress and allow testing, I'm thinking of continuing design and implementation with a class name that may be "EXPRIMENTAL_ESP8266.". Obviously that will not be the final method name or structure but changing names and parameters will be simple once we figure out the API structure we want while at the same time not blocking anyone who wants to continue with the board support. I don't want to stall through analysis paralysis and as long as the method names have no ambiguity that they have not been finalized, we should be ok and not accidentally make something that would lock us in ...