Many embedded systems must communicate with programs running on a computer. Normally, the code running on the computer and the embedded firmware are written separately. Debugging communication problems occurs on two completely disparate platforms. Using Virtuoso, the virtual device project can be included in the same solution as the PC application projects in a completely integrated development system. If for example the embedded system communicates to a computer over USB, in Virtuoso the virtual device and the PC application communicate over a virtual USB connection. Code in the firmware and the PC application that communicates can be debugged simultaneously: when a single byte is transmitted by the firmware, the debugging could then continue to see the PC application receive and process the byte.

This methodology was used in a research project where an embedded sensor that acquires streaming analog data connects to a PC as a USB device and transmits the analog data to the PC where it is recorded. Once the data was collected, which took approximately a solid week of setting up operating points and acquiring data, the data was played back into the virtual device, and the development of the analog processing algorithms could be done by streaming the data into the virtual device, and the sensor research could be performed completely in Visual Studio, making the research process incomprehensibly more efficient. The simulation engine that streamed the data to the virtual device used the same protocol as what was used to communicate with the actual device, so the algorithm being developed had no idea if it was in a virtual device or actual hardware. After being acclimated to the higher development productivity, when the algorithm was complete and the project was run on the hardware, the developers were shocked at how inefficient and crude it felt having to work on the target in hardware with the PC application now communicating with the real hardware. Regardless, the algorithm ported over to the embedded target perfectly seamlessly, and the project was complete.

Just as the virtual device can be combined with a PC application in a single Visual Studio solution, multiple embedded virtual devices can be instantiated and run to communicate with each other over virtualized busses. Virtuoso includes a suite of virtual communication bus controls such as CAN and RS-485 that can be added to automatically patch into the low-level drivers of the virtual devices. This creates a seamless and integrated platform for multi-component development, while creating a fully functional system-level simulation as a bonus deliverable.

Virtuoso brings clarity to troubleshooting issues. The virtual device by its nature requires a clear logical delineation between the high level application and the low level drivers that interact with hardware. This abstraction level is typically defined to be at the lowest level that is practical, so that the virtual device encapsulates as much code coverage as possible. When the virtual device has been tested and verified to be correct, this isolates hardware driver bugs and makes them easier to find. Conversely, anomalous behavior that is seen in both the virtual device and the actual firmware running on hardware clearly indicates that the problem lies in the application firmware. Virtuoso not only enforces proper hardware abstraction in the firmware implementation, but also provides valuable troubleshooting context.

With the Windows Presentation Foundation’s built-in 3D capabilities, Virtuoso can be used for both 2-D and 3D virtualization. A complete 3D model of the product concept drawings can be imported directly into visual studio and integrated into the virtual device, so that a completely interactive 3D virtual device can be evaluated. This can bridge the gap between concept and experience early on in the project, possibly saving significant money as mechanical design changes that improve the user experience can be flushed out by the virtual device, before a mechanical design is released for tooling or PCBs are fabricated.

Virtuoso facilitates rapid evaluation of the firmware application for the end product, which can be used as a training tool. Once the firmware application is complete and has been tested in the virtual device, the virtual device can be distributed to marketing teams or customers for evaluation and feedback. This can significantly streamline product development. The virtual device can be used as a deliverable in and of itself, a distributable deployment that can be shared to be used as a product training tool. The virtual device makes documentation easier, as screen captures from the virtual device can be used directly to provide exact visualization of product functionality.

Unreal Engine is the engine and workflow of choice for modern high-end gaming and 3D visualization. Verismo is an adapter framework to allow an Unreal Engine game to be seamlessly integrated into a .NET application. With Verismo you can interface with any Unreal Engine game actor as a .NET class and hook that up to your virtual device. Using Verismo and Virtuoso together, you can create nearly photo-realistic, real-time scenes with your fully interactive product executing actual embedded code during the development process. Welcome to the future of embedded product development.

Embeddetech’s Montage Solution Management Software integrates seamlessly with Virtuoso. Keep your Virtuoso Visual Studio project and your embedded target project perfectly in sync. Create and manage other variants of your solution as well, including the processor-specific embedded target build, the Virtuoso virtual device build, or an alternate target platform on a different processor. Solution management and hardware migration the way it was meant to be.

Virtuoso can be used with Visual Studio Community or Express, which are free to non-Enterprise developers. If your target compiler requires a license, only the developer implementing and testing the hardware drivers and building the embedded target needs the paid target compiler license.

Experienced managers of embedded systems programs understand that the most difficult aspect of embedded systems project planning is the logistics unique to embedded systems. An embedded systems design project involves a myriad of project schedule and logistical dependencies, and the complexities associated with managing these dependencies can have dramatic effects on product development costs and the return on investment of embedded design activities.

Typically in an embedded systems project, a hardware team is responsible for designing the custom hardware for the application, and the firmware team is responsible for designing the firmware, which runs on the hardware. This tight coupling creates a large potential for unexpected increase in design costs, as firmware teams are forced to wait while the hardware design is finished, or debugged. Firmware application development can also be halted due to other logistical issues, such as unavailable third party hardware components. Another very common source of dramatically increased development expenditure is the logistical complexity of implementing and testing the business logic of a firmware application. For example, business logic may involve interaction with large equipment or remote areas such as oil rigs, which are not amenable to sitting neatly on a firmware developer’s desk.

Another common logistical issue associated with embedded firmware development is associated with interaction complexity. For example, firmware running on an engine control unit (ECU), which is responsible for monitoring sensors and devices in a vehicle, has an extremely large number of use cases and scenarios. The requirement of having to physically connect an embedded system to an engine and develop a firmware application that interacts with the engine is an arduous logistical challenge to say the least. Particularly when the system must be manually manipulated to create the interaction conditions necessary to test the firmware application development.

The Virtuoso virtual device paradigm simplifies this design methodology considerably in many respects. Virtuoso provides a platform for a virtual device to be easily created, in conjunction with the virtualization of any peripheral system components needed to facilitate the implementation and testing of the business logic. Since the virtual device is already hosted in a PC application and running a high-level language environment such as C#, peripheral systems could then be easily simulated in the same high-level language environment to interact with the virtual device. The firmware application developer could then focus on the problem domain in the most natural and direct way. For example, to test a firmware application’s response to a 10,000 PSI condition in an oil rig application, the developer need not spend the time driving to a rig and testing with a physical system that generates the conditions necessary to test the business logic, instead the condition can be virtualized with a simple slider control which hooks in at the appropriate driver level, to provide the input needed. When the developer runs the virtual device and controls the slider representing system pressure, as far as the firmware application knows, it is running in embedded electronics installed on an oil rig and watching the pressure increase or decrease. The value of decoupling the business logic from hardware setups would be difficult to overestimate, as any firmware developer who has frustratingly lost days of productivity due to a bad cable or faulty or difficult-to-work-with setup would attest to. Once the firmware application has been developed and tested, now in parallel with the hardware development and the rest of the project activities, when the hardware is complete the virtual device is simply ported over to the hardware target, and the product is ready to ship, as the flow diagram below illustrates.

A common practice among PC application developers is so-called Test-Driven Design. In this paradigm, application requirements are defined in the context of a test, which is defined and developed first in order to verify understanding of the requirements. Thus if particular actions are needed to be taken in the event of particular conditions, in TDD the test would be written first, to verify that a piece of code will behave as expected. Once the test is designed and written, the actual code is written and tested. Test driven design can improve both the development speed and quality of code, however is difficult to achieve in embedded systems due to automation difficulties. For firmware written to interact with the “real world” on an embedded target, automation is generally not practical. However with Virtuoso, test automation is often not only practical, it is a financial necessity. The economic costs associated with the deployment of embedded systems with poorly tested firmware would be measured in the billions globally. Virtuoso provides the ability to hook directly into the firmware application at the lowest level possible to provide comprehensive test coverage, using the latest technologies developed by Microsoft for enterprise level application development, called Unit Testing. Unit testing and full code test coverage is considered a necessity for many application deployments. Virtuoso provides the adaptation of this and many other technologies to the embedded design platform.

As a virtual device running in Visual Studio, the entire set of Visual Studio functionalities and plug-ins are available to the developer for a dramatically improved development experience. In addition to the capabilities provided by Unit Testing, the local code debugging nature of Visual Studio, as opposed to remote testing through a debugging hardware interface, makes code debug step-through much faster. The environment also provides all of the IDE features that Visual Studio developers are accustomed to, such as IntelliSense, code snippets, plugins, etc.

Embedded firmware is usually developed and tested by running on the physical microprocessor. This means that if a single line of code is modified, the project has to be rebuilt, then loaded into the microprocessor using a hardware tool. Then the development environment must communicate directly with the microprocessor when the developer wants to execute a single instruction at a time in order to single-step through code. This requires constant communication between the design tool and the microprocessor, and creates a much slower and typically lower-capability debug session. The virtual device is completely free from this limitation. Requests to execute individual instructions occur instantaneously, and other capabilities not available to embedded debugging environments are also available. This difference might seem relatively innocuous; however the difference in productivity due to a software developer that is focused on a problem and getting immediate tool responsiveness is significant.

With the firmware running in a managed environment, runtime diagnostic capabilities are possible. For example, state information about the firmware application state can be added as an observable to the virtual firmware C# view model. With the framework facilitating these runtime application-level variables being exposed to a C# view model, the C# view can easily be modified to display this information at runtime, or allow other diagnostic functionalities like event logging to be added in a way that would be impossible or awkward to do in an embedded device.