Espruino not executing parts of code

Hi all,

I'm working on a project involving communication via RS485. I use a MAX485 board to convert it all and it works fine up to a certain point.

A while ago, I installed one of @DrAzzy 's builds to get more RAM, since we needed that in the project. The thing is, since the new firmware install, the serial communication seems to have stopped working.

The code below works on the newest 'normal' firmware, but somehow the value of reply is still 0 when we run the code on one of Drazzy's builds.

digitalWrite(B8, 0);
Serial1.setup(9600, {tx:B6,rx:B7,bytesize:8,parity:'none',st­opbits:1});
var reply = 0;

function sSend(command){
  reply = 0;
  print("Command: "+command);
  digitalWrite(B8, 1); 
  setTimeout(function(){Serial1.print(comm­and);}, 5);
  setTimeout(function(){digitalWrite(B8, 0);}, command.length/0.96+6.53);
  setTimeout(function(){
    reply = Serial1.read();
    print("Reply: "+reply);
    if(reply === ""){
      setTimeout(function(){sSend(command);},1­000);
    }
  }, 50);
}

sSend("@01EO=1\r") is the command we send to turn on the power for one of our connected devices and it should return "#01OK". If there is no reply (when the supply power is turned off for example), Serial1.read() should return "".
However, I noticed that when I run the code under Drazzy's firmware, Serial1.read() indeed returns "", but the actual value of reply is still 0, so sSend isn't called for a second time. It seems as if the code just stops there.

I have a feeling it either has to do something with timing (although I tried a lot of different timings supported by my oscilloscope), or with the firmware not working well with Serial1.

Any thoughts and advices are welcome :)

There were a few bigram builds that may have had problems with serial 1, but they should be fixed now (should be fixed as of 3 weeks or so ago). The way I make those builds is I clone the repo, replace ESPRUINOBOARD.py with a modified version, and then start the build.

The only modification made to the ESPRUINOBOARD.py is changing lines 23, 32, and 33 to 3250, 64, and 512 respectively.

Ok, thanks for the reply! Any other thoughts as to what it could be? It only happens when I use a bigram build, I tried most of the new builds and several old ones now.

Thanks again in advance :)

Weird. I've got nothin'

If I have a chance I'll see if I can check if serial works on my boards with bigram build; it's easy enough to test.

Do other serial ports work?

I cannot reproduce this on my boards...

Have you tried one of the 'latest' normal builds, like this one

It might be that something has changed in the repository, and that is why you're having troubles with @DrAzzy's build...

Also, you could try:

print("Reply "+(typeof reply)+": "+JSON.stringify(reply));

which might help you narrow down what is actually getting returned.

Hi again guys, sorry for the late reply, I've been pretty busy last week, so I didn't have time to reply.

I tried Gordon's build, which worked for me. I've moved to pins A9 and A10 now. Communication is stable with this build.

Then I tried Drazzy's bigram build, version "espruino_1v72_12-17_espruino_1r3_bigram­", which also worked, but only after I changed the timings a bit.

So instead of reading the buffer after 50ms, I had to do it after 150ms, or else it seemed the buffer wasn't "ready" yet (I would get random characters or only part of the reply string).

The program is stable with this timing, so my problem is solved, but maybe you guys know what could have caused the timing difference. Just letting you know :)

Thanks for the help and suggestions!

Different versions of the firmware do execute code at different speeds - I'm trying to make it faster and more efficient all the time :)

I guess if the timing was close already then just minor changes would cause problems.

If you checked the buffer too early, I guess it's possible that the next time around the buffer ended up full of data from the last iteration - which might explain some of the random characters?

Yeah, that's the case then. If the serial buffer misses 1 bit of data, the whole string is shifted, so you get random characters.

The difference between 50 and 150ms is pretty big to be a minor change though, but it's no big deal to implement.

Thanks again :)