• I'm hitting more than one issue trying to make "large" output work on the esp8266. For example, I can't get trace() to work if there is some real stuff loaded in memory. The problems I'm encountering are two-fold: output is not event driven, and character devices are too slow.

    When trace() produces its output, it expects to be able to sit in a loop and just keep writing without ever yielding to let some other code actually send what it's writing. Because trace() will often produce many KB of text, this can't be buffered and either large portions of output have to be dropped on the floor or the system deadlocks. The net result is that I can't figure out what consumes my memory on my esp8266. Similar problems can be seen with other functions that output lots of stuff as well as with Espruino code that sits in a loop writing stuff.

    Even when dropping output, trace() still crashes the esp8266 because the character devices (such as the console) are very slow. Looking at the code, there are many, many nested function calls for each character. If trace() outputs 10KB of text and each character takes a good number of microseconds to output (or drop), then the net result is still a loop that keeps the processor busy for >10ms with the result that the watchdog timer resets everything.

    I'm not sure what to think about all the above. trace() could be refactored to be event-driven and suspend in the middle of its execution to let output drain. But this affects other things as well. Basically any piece of code that outputs more than the size of the output buffer (e.g. network buffer) will face this issue. An option for addressing the first issue would be to use an RTOS with suspendable threads.

    Other ideas?

About

Avatar for tve @tve started