Native Port

[nashif]

Reported by Gajinder Vij:

Simulator to improve testability

A native port to Host Operating Systems (Windos and UNIX) would greatly simplify a series of tasks that are currently burdensome, since running natively as an Operating System process has a lot of advantages when developing high-level code:

• Very fast turnaround build and test time (native compilation and execution of a native executable)
• Tight coupling with the Host OS' TCP/IP stack for networking tests
• Full integration with Desktop-grade IDEs (Microsoft Visual Studio for example)
• Suitability for simple CI and regression testing
• Ability to use Valgrind and other Desktop tools to profile the RTOS
• Integration with libraries like SDL for simulated input and GUI design and testing
• Direct access to the native filesystem for on-the-fly replacement of files

Other IoT RTOSs already have support for this:

• RIOT OS: https://github.com/RIOT-OS/RIOT/tree/master/cpu/native
• Mynewt: https://github.com/apache/incubator-mynewt-core/tree/master/hw/mcu/native/src
• Contiki: https://github.com/contiki-os/contiki/tree/master/platform/native

This feature has been requested by a company evaluating Zephyr RTOS, as it is critical to their testing infrastructure and development model.

Customer story:

"Our testing/CI system requires that the code under test can be built into an OS native application currently. Zephyr however does not support "native" ports, or ports on top of other scheduling APIs. We would have to make a port of Zephyr on top of Win32/pthreads which is an significant effort. We cannot readily use the existing Zephyr simulation model (QEMU/instruction set simulation based). "

(Imported from Jira ZEP-332)

[nashif]

by Carles Cufi:

A native port of Zephyr to Windows and Linux would be of great interest to us. Being able to debug using native tools (since the image would simply be a normal OS process) for high-level development has a lot of good benefits.