As was mentioned, in a Virtuoso solution the variable bindings are intrinsically transparent to the target application build, in other words the target is executed like a normal C/C++ application, without any knowledge that it is being bound to. The C/C++ target application that is hosted by Virtuoso is typically a variant of the application being developed for a physical hardware target, and the application hosting in Virtuoso is intended to provide a drastically more efficient workflow for the development of the application.

In these cases, we refer to the two variants as the Virtuoso (or virtual device) variant and the application variant (also referred to as the “embedded variant” or “target variant”, with the target indicating the hardware that the embedded application will ultimately run on). These variants are two different targets of the same application source code, but with the majority of the application code identically cross-compiled in each of the variant builds.

The image below shows an example C/C++ application with two cross-compiled variants. In this case, one variant is an embedded target variant (left) and compiles the Hardware.c source file to satisfy the Hardware.h hardware abstraction layer API. It runs only on the embedded hardware and isn’t hosted in a Virtuoso application. The other variant (right) is hosted as a local Virtuoso target, thus it is executed on the PC in Visual Studio. The bulk of the application code in Application.c is shared between both variants, thus changes made to Application.c while developing in the virtual device are translated to the embedded variant, and vice versa. However for the embedded target the application hardware drivers in Hardware.c are used, whereas for the Virtuoso target the Virtuoso drivers in SIM_Hardware.c are used. The interface between the common application code and the variant-specific drivers is a hardware abstraction layer (“HAL”) defined in this case by Hardware.h. The application interfaces to drivers using function calls, while having no knowledge of which variant it is running. As a local virtual target running locally on the PC, the virtual device variant allows the embedded application code to be developed and tested on the PC without the embedded hardware. Typically, the host application and the local target are in the same solution, allowing both applications to be debugged simultaneously.

It is possible, and in fact even common, for variables defined for binding with Virtuoso in the simulated drivers to not exist in the embedded drivers, but simply to be there as a state representation to be exposed to C#.

As the state of the art workflow for embedded systems design, Virtuoso is engineered to promote carefully selected design patterns at every level to maximize product development efficiency and productivity. The above description demonstrates the first such design pattern which Virtuoso enforces, which is clear abstraction of the hardware interface. In order for the virtual device and embedded device to function identically, the application must run identically and interface identically to a hardware abstraction layer. Once this is accomplished, there is more clarity about the implementation of the embedded system. The goal of any design pattern is to make an initial investment in rote memorization of the pattern, in order to produce a faster and more sophisticated conceptual framework for breaking a problem down.

With a clear hardware abstraction layer in place, consideration of any particular aspect of the embedded solution can quickly be first identified as an aspect of the application level or an aspect of the hardware driver level. As an added benefit for embedded systems developers, when the application is cross-compiling to an embedded device and a virtual device, hardware portability is guaranteed. Thus an added benefit of the hardware abstraction design pattern is a more portable solution that can be retargeted to the lowest-cost processor that meets the resource requirements that were discovered while developing and testing the virtual device.