48 karma · joined January 16, 2016
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!
For others, having a simple way to prototype fast on the target hardware is a big benefit.
https://github.com/cesanta/mongoose - that's the project from which Mongoose OS stems.
To be honest, we do not think that JS is a good language for embedded. Like any other existing popular scripting language. Perhaps scripted Go would be a better choice.
The point is that in many, many cases scripting brings a lot of benefits to the embedded environment. It all depends on a specific tasks - for some tasks, scripting will never be appropriate.
V7 uses hand-written recursive-descent parser. Initially, it was using ordinary C functions, and that created a problem on systems with low stack size. E.g. each '(' starts statement parsing from the top, so 1 + (2 + (3 + (4 + 5))) consumed stack, and sometimes resulted in stack overflow in e.g. interrupt handlers or network callbacks.
Therefore we have rewritten recursive descent using C coroutines, and that is extremely sophisticated piece of work. See https://raw.githubusercontent.com/cesanta/v7/master/v7.c , search for #line 1 "v7/src/parser.c"
mJS on the other hand uses lemon parser generator - the one from sqlite project. It generates a LALR parser which is quite efficient in terms of memory.
https://github.com/cesanta/mongoose-os/blob/master/fw/exampl...
On how to access memory from mJS: write an accessor function!
// C
void setmem(uint8_t *ptr, int index, int value) {
ptr[index] = value;
}
// mJS
let setmem = ffi('void setmem(void *, int, int)');
let malloc = ffi('void *malloc(int)');
let mem = malloc(10);
setmem(mem, 3, 5);