-
Sat 2020.03.28
post #2 'However, if you have problems even without that and you HAVEN'T seen any MEMORY error on the console, it's not an error to do with memory getting used up'
If I understand the above, I don't appear to have problems as nothing was being displayed, and I 'hadn't' seen a
MEMORY
error while reducing the file size, but I do now see aNew interpreter error: FIFO_FULL
error, so not sure if that is inclusive for the above statement.Okay, worked all day on this. While I have been extra careful over the last two years to make sure all code is inside separate functions so no execution occurs during upload, I've double checked and verified this is the case, along with making sure nothing other than several vars are initialized, only a function call to display a shortcut list of function call names is rendered. I ripped out many tens of lines of code to get the file size waaay down, so that there were around 600-700 JSVARS available, so as not to run into the ~100 JSVAR minimum that I have read elsewhere that must not be exceeded.
I issue a
reset(1)
within the WebIDE. I clear the console, button upper left. Even with now a much smaller code file, now when I just upload that file, a new error appears, but not theMEMORY
error mention in the response above.I even unplugged the MDBT42Q, in case something corrupt remained, but is consistent, despite nothing I am intentionally doing would be causing a 'FIFO_FULL' error:
New interpreter error: FIFO_FULL >
This error is consitent with what I witnessed yesterday, post #3 with the significantly larger file but during runtime. So, maybe that 'FIFO_FULL' flag has always been there, as I wasn't aware to even detect that until the suggestion in post #2. What is really puzzling is the now 'LOW_MEMORY' flag, despite only using 70% of memory. This actually ran several days ago with only ~200 JSVARS remaining, so with an additional 400 free now, shouldn't be an issue.
I upload the code file from the Right-hand editor side, and the following is observed, and entering the command, flags can be seen that are set:
New interpreter error: FIFO_FULL > >E.getErrorFlags() [ "FIFO_FULL", "LOW_MEMORY" ] =undefined >
While creating the content for this post, I entered
dump()
and re-ran a memory check, and now the flags are reset!{ "free": 667, "usage": 1833, "total": 2500, "history": 602, "gc": 0, "gctime": 3.90625, "stackEndAddress": 536928592, "flash_start": 0, "flash_binary_end": 428148, "flash_code_start": 442368, "flash_length": 524288 } =undefined >E.getErrorFlags() [ ] =undefined >
The new question, what is causing theFIFO_FULL
error when just uploading code? I'm not seeing theMEMORY
error and there are 600+ JSVARS available, so there shouldn't be a memory issue, correct?http://www.espruino.com/Reference#l_E_getErrorFlags
'FIFO_FULL': The receive FIFO filled up and data was lost. This could be state transitions for setWatch, or received characters.
'LOW_MEMORY': Memory is running low - Espruino had to run a garbage collection pass or remove some of the command history
'MEMORY': Espruino ran out of memory and was unable to allocate some data that it needed.What is the trip point for low memory as I've stripped 30%+ and still get the flag on upload:
{ "free": 871, "usage": 1629, "total": 2500, "history": 726,
Note that running a forced garbage collection
process.memory
does clear the flag.
I guarantee this is not what's happening in JS.
http://www.espruino.com/Reference#l_E_errorFlag
It'll get called when Espruino's had some difficulty allocating memory. It may not have 100% failed at that point, but it's got close.
However, if you have problems even without that and you HAVEN'T seen any
MEMORY
error on the console, it's not an error to do with memory getting used up