Preconfiguring Wifi

I like to think of the ESP8266 as "bundling" WiFi and TCP/IP libraries as part of an executable and those libraries having "reserved" flash areas into which they save their configuration for subsequent restart and operation. This area of flash is private to those libraries. While in principle if we "poked" those addresses with values, they would be honored, I'd suggest avoiding that. Those are not what are considered "clearly defined programming interfaces" and there would be nothing to prevent the library authors from changing their content, location or even existence from one SDK release to another. The expected mechanism is to invoke the ESP8266 APIs and have them perform their saves and restores.

As such, I'd suggest that we not try poke to their storage. Can we take a step back. What is the puzzle we are trying to examine?

I am imagining it is that we have a standard Espruino binary that we flash to an ESP8266. When the ESP8266 then boots, it doesn't know which access point to connect to nor what password to use to connect to it.

A couple of thoughts on that puzzle.

The first is that the ESP8266 can be an "access point" ... meaning that it can listen for incoming WiFi station connections. We could have a virgin loaded Espruino know that it is first boot and set itself up as an access point that could then be connected to from a WiFi station (eg your cell phone) and configured with the identity of the desired target "real" access point. At that point it would be bootstrapped.

A second thought would be that on first boot, there is a piece of logic that we embed in Espruino that has the semantics:

if (first Espruino boot) {
   retrieve data from an area of user program flash;
   use that data to configure WiFi station access;
}
// Normal Espruino boot ...

By the inclusion of this logic, we CAN then provide legal/clean command line options to set the desired station access configuration ... we would load that data into "user code" flash space during the upload of Espruino into the ESP8266. This would appear to solve the puzzle without internal knowledge of ESP8266 mechanics that are "forbidden" to us.

Again ... just musings ... hope this helps some.