[riot-devel] RIoT initialisation
pekka.nikander at iki.fi
Mon Sep 22 20:49:05 CEST 2014
> On 22. September 2014 19:56:04 MESZ, Pekka Nikander <pekka.nikander at iki.fi> wrote:
>>>>>> __attribute__((constructor)) static void startup(int argc, char
>> This is probably a stupid question, but why in the first place are you
>> declaring startup as a constructor? ...
> And finally, because this assumption does not hold:
>> If you want to take care of all initialisations yourself,
> Really, all this is just to allow "main" as the user application name, so I didn't want to add unnecessary complexity.
Well. Hmm. Interesting.
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.
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.
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4827 bytes
Desc: not available
More information about the devel