for me it looks like it'll block the while loop. You said the C could would be sending just a very short pulse instead, it's only a minor bug.
Just to expain my understanding of the code I've attached a simplified JavaScript program emulating the code:
A while loop that doesn't contain any code itself (just assume it would transmit a bit)
Said while loop shall complete after 10 ticks (t=10)
The program would repeat forever (as it was transmitting an infinite number of bits)
The program works fine, until ccount is reset back to 0. At this point the while loop hangs, it never quits. This would crash the ESP8266 (reset triggered by wifi/watchdog).
A fix for the JavaScript program would be to uncomment line 17 ("ccountChk = 255-t-5;", with "t" being the waiting time and "5" being an estimated amount of ticks needed to run the program code itself, with good margin). Since the fix itself takes some time to process it might be ok to change the while loop counter "t" from "10" to "9" (in this example it doesn't makes sense. But in the original code you can reduce the while counter due to the delay introduced by a similar fix).
Anyway, before writing a fix I think it's best to get a common understanding if there's a bug, and what the best fix would be. I wouldn't want to add a speculative fix for a potential bug that isn't fully understood.
//
//step debugger
//
//init variables
var t="na";
var start="na";
var pc = 0; //program counter
var ccount = 0; //a 8 bit ccount implementaton
var ccountMax = 255; //a 8 bit ccount implementaton
var program = []; //program code, addressed by program counter
var ccountChk = 255-10-5;
//program code
program[0] = "t = 10;";
program[1] = "start = ccount;"; //start=_getCycleCount();
//program[1] = "if (ccount>ccountChk) { pc--; start =-1; } else { start = ccount; };";
program[2] = "if (ccount-start < t) { pc--; } //while(_getCycleCount()-start < t);";
program[3] = "pc=0; //while loop completed, repeat the program (to send next bit)";
//step debugger, executes one line of the program code each call
stepDebugger = function() {
console.log("A PC=" + pc + ", ccount=" + ccount + ", t=" + t + ", start=" + start + ", program: " + program[pc]);
eval(program[pc]); //execute one line of code
pc++; //set pc to next line
if (pc > program.length) { console.log('program ended'); }
ccount++; //increase ccount, reset to zero if it's countMax
if (ccount>ccountMax) { ccount=0; }
console.log("B PC=" + pc + ", ccount=" + ccount + ", t=" + t);
}
//automatically call the debugger every 500ms
stop = setInterval(stepDebugger, 500);
//clearInterval(stop)
//the while loop (program[2]) exits every 10 ticks.
//bug: once ccount==start=253 the while loop "hangs" forever
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.
Hi Robin
for me it looks like it'll block the while loop. You said the C could would be sending just a very short pulse instead, it's only a minor bug.
Just to expain my understanding of the code I've attached a simplified JavaScript program emulating the code:
The program works fine, until ccount is reset back to 0. At this point the while loop hangs, it never quits. This would crash the ESP8266 (reset triggered by wifi/watchdog).
A fix for the JavaScript program would be to uncomment line 17 ("ccountChk = 255-t-5;", with "t" being the waiting time and "5" being an estimated amount of ticks needed to run the program code itself, with good margin). Since the fix itself takes some time to process it might be ok to change the while loop counter "t" from "10" to "9" (in this example it doesn't makes sense. But in the original code you can reduce the while counter due to the delay introduced by a similar fix).
Anyway, before writing a fix I think it's best to get a common understanding if there's a bug, and what the best fix would be. I wouldn't want to add a speculative fix for a potential bug that isn't fully understood.