The linker script specifies that .data section starts where 192k RAM region starts - in other words, addresses of all variables, etc, are in the RAM memory range.

But the firmware image (that resides on flash), which has .text and .data concatenated, has that .data section in Flash region, obviously. So we have .data section residing in Flash region, but all its addresses in the RAM memory range. That's why it is necessary to copy it over manually.

Hope this is clear... Let me know if not!

I understand now, thanks for clarifying!

Fast prototyping is the answer. If you or some others are skilled in C/C++, you don't need JS.

For others, having a simple way to prototype fast on the target hardware is a big benefit.

mJS allows you to use C/C++ SDK functions directly without writing a glue code - basically, you can prototype things quite fast with the libraries/drivers that do not have any scripting support yet.

But why not make that for micropython instead of making a whole new language?

Ideally you don't want to port the C/C++ over to Python: that's the value proposition of mJS, I think.

JS is for prototyping.

Sure, try to run those on e.g. TI CC3200 microcontroller.

Yocto does not seem to support CC3200.

That's right, cause Linux cannot run on the large class of microcontrollers - particularly, those with less than 4M of RAM. Mongoose OS is targeting that category.

Zephyr is an open source OS that targets smaller microcontrollers.

I think Mongoose was called mongoose before mongo db plugin existed.

https://github.com/cesanta/mongoose - that's the project from which Mongoose OS stems.

Hi Gordon! Nice to meet you :) I am the author of the article, and I am quite fond of Espruino, it's a great project. Wasn't aware that Espruino has FFI API!

Hi! Thanks, v7 looked great too. mJS looks like a good idea - IMO it'd be nice to standardise a sane, minimal subset of JS that can be easily implemented - it'd be a huge help for all the developers of embedded JS interpreters, and could potentially be targeted by transpilers too.

Yes. Closures add quite a bit of complexity and footprint. Anticipated use case was a short script that orchestrates the device logic, calling existing SDK functions.

Nice! I wasn't aware of lua ffi api, thank you!

Embedded environment in this context means hardware low on resources, e.g. microcontrollers. Your perception of that word is "embedded into the C/C++ program". These are two different things. I agree that Lua (like some other languages) were designed to be embedded into C/C++ apps.

Something like this? http://www.nodemcu.com/index_en.html