You are reading a single comment by @rj and its replies. Click here to read the full conversation.
  • do you know whats going on with the code being there twice?

    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.setBootCode and dumps that.

    Imagine what happens if you upload function f() { print("bar"); } setInterval(f,1000) to flash and then when its running you type function 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

  • 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

    1. "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.
    2. "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.

About

Avatar for rj @rj started