## 5 Discussion  
Proposed virtual-simulator architecture, with a limited but most desirable simulation capability and running an embedded application as a part of the virtual simulator, is a straight way to rapid development of virtual simulator for custom embedded system. The proposed solution enables remote work on most time-consuming embedded-software parts implementation. Prepared source codes for the simulator are ready to be compiled and run on a real embedded system platform. This is possible because the real and virtual platforms use the SOL, which is reduced and has made it easy to implement and simulate embedded-system components. Despite the high compatibility of a properly designed SOL with both platforms (real and virtual), there can be some issues that will be related to:  
* basic data types that can vary for used platform compilers: a safe approach should consider using types defined in _stdint_ header;
* memory layout, which is typically one continuous space for simulator and for embedded system can be fragmented among many blocks; this issue can be solved using a proper linker script;
* timings of peripherals operation and program execution in the target platform; this will be different on both platforms, so properly designed software cannot rely on this behavior directly in the Application Layer;
* a lack of common synchronization mechanism for both platforms, between the main program and timer handlers, so for simplicity and rapid development of the simulator, there is no synchronization provided, and to avoid inconsistent access to shared resources, they should be accessed atomically;
* a risk of using libraries on a virtual simulator platform that are not supported in the embedded system, which can be a serious mistake and force a redesign of software developed purely in the virtual simulator;  
Figure 16: Results of unit tests (**a**,**b**) and functional tests (**c**,**d**) performed using RPILAB real device (**a**,**c**) and its virtual simulator (**b**,**d**): (**a**) photograph of real LCD during framebuffer test; (**b**) screenshot of virtual-simulator framebuffer test; (**c**) photograph of real LCD for functional test using demo application; (**d**) screenshot of virtual-simulator functional test using demo application.  
Non-typical behavior of an embedded application running in a virtual simulator that is forced to close, so this should be covered by the software to make a clean exit from an application that will be unnecessary in a real device; using Microsoft Windows as a platform for a virtual simulator can lead to potential issues with constant time-period requirements for embedded-timer implementation; this is caused by the non-deterministic nature of the Microsoft Windows operation system.  
Despite the limitations listed above the properly designed applications work well using the virtual simulators that were proven in Figures 15 and 16. The results of unit (static) and functional (dynamic) tests show high compatibility between the virtual and real embedded systems for TMSLAB and RPILAB cases using chosen peripherals such as an LCD, keyboard, led bar, gamepad, and video framebuffer.  
To accelerate the process of application development for students, special demo programs were created. They are shown in Figures 12 and 14. The purpose of this programs is the functional demonstration of the usage of Simulated-Oriented Layer classes and limitations. Besides this, each laboratory class is accompanied by a lecture on which important theoretical issues and SOL limitations are discussed.  
Taking into account the limitations listed above, we have to emphasize that the proposed approach in the paper was intentionally simplified.