AT - Wifi - ESP8266

Some irregular behavior: why can it not find the "AT" module (anymore) and gets (completely) lost - even though the submit to the board made no complaint what so ever...

 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v81 Copyright 2015 G.Williams
>echo(0);
=undefined
>onInit();
=undefined
is[0]Seq: ok
is[1]DSP: ok
ERROR: SD card must be setup with E.connectSDCard first
WARNING: Module "AT" not found
Uncaught Error: Field or method "connect" does not already exist, and can't create it on undefined
 at line 1 col 22
{l.at=g=require("AT").connect(a);require­("NetworkJS").create...
                     ^
in function "connect" called from line 6 col 4
  }); }
   ^

No matter how many times I retry initialization, still cannot find the "AT" module.

Resending the software helps to get over 'missing "AT" module' but gets stuck and keeps showing this:

|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v81 Copyright 2015 G.Williams
>echo(0);
=undefined
>onInit()
=undefined
is[0]Seq: ok
is[1]wifi.reset: No 'ready' after AT+RST: failed
>
Disconnected
> 

Disconnected means: power off... not very helpful...

I triet to power cycle just ESP8266, but noticed a different special effect: even though having a 4.7uF capacitor across the ESP8266 ground and power pins, the ESP8266 shocks Espruino on a regular base into 'reset' by short power fail...

Adding an additional 10uF capacitor maes it possible to power cycle ESP8266 without 'resetting' Espruino.

But it is not all that reliable: power cycle bot at the same time creates some timing issues and makes ESP8266 mess with Espruino so badly, that the IDE - though saying connected - cannot or does not upload code...

It let me conclude that some ESP8266s are better than average working behavior, and more are worse.

The complete code is shown in the next post. The code has some nice layering features:

1. Separation of configuration and module loading from (re)initializing
   
2. initialization/callback helper
   
3. sequencer/callback helper
   
   

Separation of configuration and module lodading defines clearly what is code-upload and what is going on on onInit(), especially after save() and re-powering.

Since all things work event driven with simple to complex, nested callbacks, I built the two helpers that deal with the callback maze, especially when:

1. Multiple devices are involved - for example: ILI9341 or a-like controlled displays, serially connected ESP8266, serially connected sensors,...

2. Sequence of calls to one and the same device have to be serialized the way that the next call has to wait until the callback of the previous one has 'finished' - for example: get version info, access point, and IP address from ESP8266 and display them, all bundled in a function.

So much so far about the sequencer (gSeq - g(lobal variable for) Seq(uencer) for commands.

Starting with the command:

1. Each command is a function that accepts a callback function from the sequencer on invocation and executes that callback function at last (after completion). The inovcaton makes the sequencer handle the next command in sequence.

2. It is a FIFO - commands/functions added first is executed first - which needs not much explaining: a new command goes on the top of a pile and command by command is pulled from the bottom of the pile until pile is gone.

3. It is a LIFO - commands/functions that have to be executed right after a result comes back BUT or AND before the next command waiting in FIFO - which needs a bit more explaining:

If such a command returns the result it - logically - may need to be callback-style processed before the next invocation happens, and can therefore be inserted at the bottom of the command pile.

A picture of the hardware setup was already part of a separate post.