As you may recall from my ~~meandering musings~~ previous writings, I spend an inordinate amount of time creating capriciously cunning hobby projects, most of which are powered by different flavours of Arduino or chipKIT microcontroller (MCU) development platforms.

Not surprisingly, there are multiple aspects to each project, including any non-electronic hardware like the cabinet and associated accoutrements, the MCU platform, and the power supply. Two of the most problematical facets to the project are the additional electronics hardware components (including wires and connectors) and the software running on the MCU.

The reason I mentioned "wires and connectors" in the previous paragraph is that I seem to be experiencing a surprising number of wire-related failures recently. At least three times over the course of the past few days a prototype has failed due to a bad wire. The problem is that the wire is the simplest element, so, paradoxically, it tends to be the last one I look at, and then only after I've stared at my code until my eyes water and checked all of the more interesting devices on my component tester.

Of course, bad wires are just the tip of the iceberg. I can't tell you how many times I've triumphantly thrown a project's power switch, poised to shout "It's alive; it's alive," (in an unassuming, humble way, of course), only to stare despondently at the system as nothing whatsoever happens.

Well, yes, of course this is preferable to watching days of work go up in a puff of smoke, but it's still somewhat wearing on the nerves. The problem is that you don't know which part of the system has failed—is it the software or could it be the hardware?

All of this brings me to the reason for this column, which is that I was just chatting with Jonathan Torkelson and his dad who we will call Doug (because that's his name). Jonathan is the president and principle engineer at EmbeddeTech—an embedded technology design service and research company that support customers at all stages of electronic product development, from concept to production.

As part of their activities, the folks at EmbeddeTech have been developing virtual systems for internal use. Now they are poised to unveil an embedded virtual device framework called Virtuoso and, as part of this effort, they've just launched their Virtuoso Kickstarter Project.

The Virtuoso embedded virtual device framework is extremely powerful and takes full advantage of Microsoft.NET technology. As we read on the Kickstarter page:

In a nutshell, Virtuoso works by taking your embedded application C/C++ code and wrapping it in a .NET class to create a powerful virtual run-time environment. This C# .NET class serves as a run-time model for the virtualised embedded application according to the "Model-View-ViewModel" (MVVM) design pattern. This target model is completely managed by Virtuoso, and all embedded threads, variables, timers, and data streams can be configured to be exposed on the target model. Developers are then free to leverage the power of .NET to build a virtual target, using either pre-built Virtuoso library components or components written from scratch. The application code has no idea whether it's talking to 'real' hardware or virtual components.

Actually, there a lot more to all of this than we can hope to cover here, but you can learn a lot more by visiting the Virtuoso Documentation page of the Virtuoso website.

Having the ability to quickly create a virtual representation of your embedded system and then verify your software in advance of having physical hardware conveys many advantages, not the least of which is having the confidence that any problems aren't caused by open-circuit faults in a bad batch of flying leads (not that I'm bitter, you understand).

Furthermore, it can be extremely advantageous cost-wise to be able to deploy virtual models of a system for use by software developers around the world, as opposed to shipping myriad expensive physical systems, especially if a subtle hardware problem rears its ugly head downstream in the development process.

Another huge target for this technology is education. Imagine a graphical representation of an industrial process, such as a water tank with some sort of gas heater, hot and cold water feeds coming in, and a water pipe exhaust going out, all of which can be controlled by valves. It may be that you wish to control the state of the water output valve with your mouse (or your finger on a touch screen), and that you wish the control system to maintain the depth of the water and its temperature at some constant values. Having a virtual system allows the students to evaluate and compare different control algorithms like PID versus Fuzzy Logic without actually blowing anything up (of course, it wouldn't hurt to include a virtual explosion if the algorithm fails to do its job).

One very interesting aspect to all of this is that users can create their own virtual devices and then share them with, or sell them to, other users.

What about the Maker-Hobbyist market? Well, take a look at this video showing a Virtuoso virtual embedded system based on the Curiosity Development Board from Microchip Technology.

Jonathan told me that it took his team only a day or so to create this virtualised environment. Now, I think that creating Virtuoso embedded environments will be beyond the scope for most Makers and Hobbyists—especially beginners. On the other hand, more experienced developers will find this to be relatively easy, so I don't think it will be long before virtual Arduino, chipKIT, BeagleBone, etc. systems start to appear, and I, for one, can't wait!