while loop reboots

[espruino-discuss]

Posted at 2018-01-22 by DanB

ESP8266-12E flashed with espruino_1v95_esp8266_4mb_combined_4096.bin ...

Problem: while loops cause the chip to reboot, even a program as simple as:

---

while(1) {
}

---

Web IDE shows the following:

Flash map 4MB:1024/1024, manuf 0xc8 chip 0x4016
>
 ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8
2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : DIO
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user1 @ 1000

---

Am I doing something wrong here?
Thanks,
Dan

[espruino-discuss]

Posted at 2018-01-22 by DrAzzy

Yes, you are. You can't busy-wait like that on an ESP8266 because it has to periodically let the CPU do the wireless-related stuff, and there's a watchdog timer that resets the chip if it doesn't yield for too long. But in Espruino, you don't have to do things like that, since you're writing JS not C- you can use timeouts/intervals/watch's instead of sitting there spinning.

---

Posted at 2018-01-22 by DanB

Thanks, DrAzzy. That makes sense. That also means I have to be careful about long computations.

Actually, I initially wrote my program (a pulse counter) using watches, but it was missing pulses, which is why I tried the "while" approach. What I just figured out is that the "watch" on ESP8266 needs fast edges, rather than levels to trigger. I sharpened the edge of the input pulses, and now I am not missing pulses.

Thanks again,
Dan

---

Posted at 2018-01-22 by DanB

Make that, "not missing as many pulses." Watch is still missing some pulses.

---

Posted at 2018-01-23 by @allObjects

To count pulses with an mc, usually you connect an internal counter's clock (or timer) to an input pin by timer/counter/gpio configuration. The timer/counter is then configurable in regard of where to start/how much to count, what to do on over or underrun, such as restart, stop, send interrupts, etc. I'm though not aware of any Espruino setup that makes such a basic mc function work. May be @gfwilliams may shed some light on that or make it even happen with for example a pin mode... ;-)

---

Posted at 2018-01-23 by DanB

Hi allObjects, thanks for your comment. I think that my problem was that I didn't completely understand how the "watch" function works, and (so far) my difficulties seem to have been solved by changing the hardware debouncing circuit that sends the pulses to the ESP8266. My diagnosis is that "watch" catches all the transitions of an undebounced switch input and the "debounce" option in "watch" happens in software. Thus, if there are too many inputs from undebounced switches, the "watch" queue becomes overloaded. The other thing I found is that "watch" really needs a fast edge input. The frustrating/fun part of my working with Espruino is that I have relearn to do all the things I used to know how to do in C.

---

Posted at 2018-01-24 by @allObjects

@danb, that's correct... all pulses go to the 8266 into the hardware interrupt that Espruino maintains on said pin. Espruino then looks at the watch debounce options and say: 'hold your horses', until I do not see the logic level 'holding' for the debounce time, I do not consider this a signal and interrupt that is worthy to put into the queue for the JavaScript execution - the invocation of the callback function set with the watch. That's by the way all happen in C... ;-) --- so when then either the internal 8266 communication is done or the current JavaScript section triggered from the last interrupt is completed, Espruiono then checks if there is an entry in the JavaScript event queue and directs its cycles to process the callback. There are basically / logically 3 'queues' or 'logical' cooperating threads - kind of - going on:

1. the ESP8266 firmware/wifi-ware thread with the highest priority, feeding from Espruino / JavaScript issued requests and feeds the Espruino JavaScript queue (for all the on(eventName...
2. the Espruino control thread that bridges the non-JavaScript world (hardware/device firmware) and the JavaScript execution (dealing with capturing interrupts and put them into the queue for the JavaScript side)
3. the JavaScript execution thread that should be done as quickly as possible in order to not choke off / starve the other ongoing things...

It's quite an elaborate coop between the layers / areas of concerns...

Espruino is a highly optimized, thoroughly event driven platform. I like it very much... Thinking is not linear, but that makes it fun.