Avatar for user76715


Member since May 2017 • Last active Jun 2017
  • 1 conversations

Most recent activity

  • in Pico / Wifi / Original Espruino
    Avatar for user76715

    Firstly huge kudos to the developers of Espruino; it's fairly mind blowing being to able to easily and quickly prototype systems on fast hardware with such a simple and well thought development process.

    I have come across issues trying to get a reliable send / receive system using MQTT. The problems do not come from the MQTT libraries themselves and I think I have tracked the issues to the EspruinoWifi module which is causing the socket to close during a 'send' cycle.

    The following code

    send : function(sckt, data) {
        if (at.isBusy() || socks[sckt]=="Wait") return 0;
        if (socks[sckt]<0) return socks[sckt]; // report an error 
        if (!socks[sckt]) return -1; // close it
        var cmd = 'AT+CIPSEND='+sckt+','+data.length+'\r\n­';
        at.cmd(cmd, 10000, function cb(d) {       
          if (d=="OK") {
            at.register('> ', function() {
              at.unregister('> ');
              return "";
            return cb;
          } else if (d=="Recv "+data.length+" bytes") {
            // all good, we expect this 
            return cb;
          } else if (d=="SEND OK") {
            // we're ready for more data now
            if (socks[sckt]=="WaitClose") netCallbacks.close(sckt);
          } else {
            socks[sckt]=undefined; // uh-oh. Error.      
            at.unregister('> '); 
        // if we obey the above, we shouldn't get the 'busy p...' prompt
        socks[sckt]="Wait"; // wait for data to be sent
        return data.length;

    attempts to send data using the well known CIPSEND, OK>, sendMyData, SEND OK pattern of the ESP8266 and if there is no incoming data during the send period then everything works fine.

    The issue comes in that the callback data will sometimes contain other incoming data (say from an +IPD call) from the RX buffer in which case the final else clause (line 24) determines there has been an error.

    I have tried various attempts to better synchronize calls to the SEND function and 'lock' any receive events but haven't been successful.

    What does anyone think about simply returning the callback in any situation that is outside the normal flow ?

    I have tried it as follows

    } else {
      //socks[sckt] = undefined; // uh-oh. Error.      
      at.unregister('> ');
      return cb;

    and it allows the socket to stay running but it still doesn't feel quite right. With a more explicit error clause (not sure what that looks like from the ESP2866 when it fails to send) it seems a workable solution and has allowed me to send and receive asynchronous (publish and subscribe independently) with decent size messages at upwards to 10Hz.

    Any thoughts on whether it's a valid fix or whether there are better solutions ??

    Thanks and regards,