function tx() {
if (sigLED) sigLED.set();
s = txStr;
txDev.tx(txPin,s, 3, function(){
if (sigLED) sigLED.reset();
});
}
If you add a console.log(s); to see what you're actually trying to send, you get:
function () {var s = "0" + Math.floor(getTime()) % 60;
return s.substr(s.length - 2);}
function () {var s = "0" + Math.floor(getTime()) % 60;
return s.substr(s.length - 2);}
function () {var s = "0" + Math.floor(getTime()) % 60;
return s.substr(s.length - 2);}
function () {var s = "0" + Math.floor(getTime()) % 60;
return s.substr(s.length - 2);}
function () {var s = "0" + Math.floor(getTime()) % 60;
return s.substr(s.length - 2);}
Execution Interrupted during event processing.
function () {var s = "0" + Math.floor(getTime()) % 60;
return s.substr(s.length - 2);}
function () {var s = "0" + Math.floor(getTime()) % 60;
return s.substr(s.length - 2);}
You missed out a () so instead of calling the function to get the data, you're sending the entire function! The 433 module isn't meant for sending lots of data, so the pulse train ends up being really long. While Espruino is sending all the data it's unable to do anything else (including reading data from the input fifo) so that probably explains the FIFO_FULL.
For RX, you'd always have got FIFO_FULL on some modules (because if you get random noise, it comes in so fast that Espruino can't process it all fast enough). It just wouldn't have been reported previously.
It shouldn't be a major issue, since when data starts arriving the noise drops off and Espruino is able to clear the backlog and get all the data that is sent.
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.
You're on the standard 1v99 firmware?
It seems to be that your biggest issue is:
If you add a
console.log(s);
to see what you're actually trying to send, you get:You missed out a
()
so instead of calling the function to get the data, you're sending the entire function! The 433 module isn't meant for sending lots of data, so the pulse train ends up being really long. While Espruino is sending all the data it's unable to do anything else (including reading data from the input fifo) so that probably explains the FIFO_FULL.For RX, you'd always have got FIFO_FULL on some modules (because if you get random noise, it comes in so fast that Espruino can't process it all fast enough). It just wouldn't have been reported previously.
It shouldn't be a major issue, since when data starts arriving the noise drops off and Espruino is able to clear the backlog and get all the data that is sent.
Also, if you want to trap a FIFO_FULL error, see the
errorFlag
event (http://www.espruino.com/Reference#l_E_errorFlag`) andE.getErrorFlags()
.Errors like FIFO_FULL aren't caused by JS execution, so it doesn't make sense having them as exceptions.