You are reading a single comment by @rj and its replies.
Click here to read the full conversation.
-
When you type dump() it dumps the current state of code in RAM (plus the hardware state), then if there's code saved in flash it writes // Code saved with E.setBootCode and dumps that.
That explains it completely, thanks 👌!
I think what confused me was the two statements in the docs
- "Output current interpreter state in a text form" -- made me think "why would the interpreter keep the same code twice" and made me question what the interpreter even was then.
- "such that it can be copied to a new device" -- made me think "why would one paste a bunch of code with repeated code blocks into a new device"
Nevertheless; case closed, thanks for your help and patience 🙂.
edit: BTW, may I suggest adding the quoted text to the docs (or is it something anyone can do via a PR on github?) 🙂? It's a very clear explanation IMO.
- "Output current interpreter state in a text form" -- made me think "why would the interpreter keep the same code twice" and made me question what the interpreter even was then.
rj
Espruino keeps its current state in RAM (even if the function code is stored in Flash). When you type
dump()it dumps the current state of code in RAM (plus the hardware state), then if there's code saved in flash it writes// Code saved with E.setBootCodeand dumps that.Imagine what happens if you upload
function f() { print("bar"); } setInterval(f,1000)to flash and then when its running you typefunction f() { print("foo"); }in the REPL.It looks more complicated on ESP32 than it should because there hasn't been any work put in to exclude any pins that are in their normal bootup state - hence the pullup lines. On official boards
dump()only writes pin states if the pins have actually had their states changed from the default