[riot-devel] RIoT initialisation

Ludwig Ortmann ludwig.ortmann at fu-berlin.de
Mon Sep 22 22:04:21 CEST 2014

Hi Pekka,

On Mon, Sep 22, 2014 at 09:49:05PM +0300, Pekka Nikander wrote:
> As a reference point, after a few iterations, we at Ell-i ended up compiling our emulator binaries (which AFAIK correspond to the RIoT native binaries) into shared libraries instead of executables.  That allows us to load the shared library into a controlled execution space, where we can emulate the hardware and control the emulated binary execution.  While that is very much work in progress still, it seems promising.

> At the native side we simply control everything from the reset vector on, having our own startup routines.  I presume you have the same.
> At the moment, for the emulator we compile the application into a native, 32-bit library, and use a 32-bit python executable and a python script to load it.  At the moment, we merely run individual functions out of the library, for unit testing.  If we wanted to run a full app, we would simply dig up the entry point from the vector table and call the reset vector.  In that way the emulated binary execution would correspond almost 100% to the actual native binary on an MCU.
> At the "hardware" side of the emulator, we use simple C++ wrappers to emulate the MCU hardware registers, basically meaning that all direct reads and writes to them are "trapped" with C++ syntactic sugar.  Indirect reads and writes kind-of work, as the C++ wrapper objects do not have any virtual tables and hold the register value as their first member variable.  Of course, indirect access does not work fully, as we cannot emulate hardware register side effects on indirect reads or writes.

OK, lets see if my tired head got that right:
What you are doing is writing a hardware emulator/simulator.
What I am doing is writing a call level emulator.

My decision to not to write a hardware emulator was to reduced overhead and complexity.
One of the goals is to support large virtual networks, so reducing overhead seemed important.

I always thought that, if I had enough time, adding hardware emulation would be a "nice to have" to allow testing of drivers.
But then, parsing the memory and emulating the actual hardware also looked like it would become kind of tedious.
In any case, now I tend to think that dummy interfaces for unittests would pose a more rewarding approach than having them actually do something (like for example native's interfaces) if testing drivers was the goal.

> As some next point, my plan is to install also signal handlers for trapping bad memory access and other common bugs in a controlled manner, but we are not there yet.

I am integrating existing tools that do that instead ;)

> Now, for RIoT, maybe using the current native HAL that you have but compiling the applications into shared libraries instead of binaries might help.  You could then have an explicit "launcher" that would load the shared library, and call whatever initial functions you need to call there.  IIRC, by default the dynamic loader executes any constructors in the binary, so that would happen automatically.  After that, you could then call "startup" which in duly manner could then call main.

Sounds interesting, but I am not entirely sure of the consequences and benefits (despite promising to solve the "main" problem).
One of the advantages of the current approach is that the native platform is treated exactly like any other platform by the build system.

> A benefit of such a launcher would be that it would allow you to include there additional, debugger like functionality in the future, such as allowing CTRL+C to be used to stop execution, and having some kind of monitor for inspecting the program state.

Trapping of signals already works in RIOT native as it is.
For example ctrl+c is used to gracefully exit the process.

Also, I was planning to add additional signal handlers for debugging (maybe USR1 already does something which I forgot to take out again..), and a separate socket interface for state setting/getting and event triggering (buttons/GPIO/..).

Looking forward to thinking more about this and discussing a bit in person when you're here =)


More information about the devel mailing list