Anyone ever tried to compile RIOT OS to WebAssembly with ecmascripten? Kind of interesting, because it would make it possible to run code in a web browser. Simple way to get people into RIOT OS. Ecmascripten even has a porting guide. (https://emscripten.org/docs/introducing_emscripten/about_emscripten.html#porting-code-to-use-emscripten)
Hi Philipp,
this is a nice idea.
But it might not just be as easy as copling with emscripten, since RIOT manages and schedules its own threads. Even though WASM is a kind of near system intermediate Bytecode it is restricted (even inside its sandbox). Especially you are not able to jump through the Bytecode since it is kept structured and has no GOTO (jmp / br). I think you are also not supposed to edit the stack (rewriting return addresses).
* Nevertheless I would like to see this.*
A second option would be to emulate a CPU/MCU in WASM an run RIOT on this.
btw.: I am currently working on running WASM inside RIOT.
best regards Karl
IT"S TURTLES ALL THE WAY DOWN!!!!
Hi Philipp,
this is a nice idea.
But it might not just be as easy as copling with emscripten, since RIOT manages and schedules its own threads. Even though WASM is a kind of near system intermediate Bytecode it is restricted (even inside its sandbox). Especially you are not able to jump through the Bytecode since it is kept structured and has no GOTO (jmp / br). I think you are also not supposed to edit the stack (rewriting return addresses).
* Nevertheless I would like to see this.*
A second option would be to emulate a CPU/MCU in WASM an run RIOT on this.
That is actually a quite interesting option to evaluate. There are already a couple of projects for that:
Of course this will be very inefficient, but this wouldn't be a productive dev environment. Just for people playing with RIOT OS. For that purpose it should be good enough.
btw.: I am currently working on running WASM inside RIOT.
I don't get why you should want to run wasm inside RIOT, when you can just compile the source code for the desired architecture. What is the use-case for this?
It means that we can have a sensor/device with all sorts of nice onboarding, security, and sane stack, which is upgraded/patched on a long-cycle.
But the actual application code can be downloaded on a much shorter cycle, and can be authored by far less capable (and far less trusted) people. [See RUST talk at last summit]
Could also have a different license.
Whether this will really work given the battery optimization concerns is something we'll have to learn.
Thank you Michael, this is a very nice explanation.
I tock a short look at the two emulators,
> https://github.com/takahirox/riscv-rust > https://github.com/d0iasm/rvemu
they seem to be target towards emulating bigger systems (able to run Linux) than RIOT targets. Afaik RIOT is aiming at microcontrollers.
I found https://github.com/renode/renode as a MCU emulator but it is written in C# (which i don't know much about) and i found no WASM Version.
Maybe someone know about a WASM MCU emulator or the two from above maybe configurable or stripdownable to be MCU emulators. If one wants to emulate MCU it would also be nice to emulate some peripherals integrated and external.
Hi
Just some side-notes:
I found GitHub - renode/renode: Renode - Antmicro's open source simulation and virtual development framework for complex embedded systems as a MCU emulator but it is written in C# (which i don't know much about) and i found no WASM Version.
We actually already support renode 
RIOT/dist/tools/renode/README.md at 870c8920bd1b9125f2807c58a5e963fb4b0c6bce · RIOT-OS/RIOT · GitHub.
There is also https://www.msp430emulator.com/ (pretty sure it isn't WASM
either though). Given that real MSP430 hardware seems to get rarer,
maybe support for that one has also its advantages for our testing efforts.
Best, Martine