Introducing MicroWorkflow for Netduino

MicroWorkflow – create your own automation on Netduino in a visual way.

 

Disclaimer: this project and its name has nothing to do with the http://micro-workflow.com/ site.

 

MicroWorkflow is a framework layer for creating simple automation on the top of a host .Net application. It currently supports both the standard .Net framework, and the .Net MF.

A snapshot of the designer showing a very basic workflow.

It’s not meant as a replacement of the underlying programming language, but rather a simple and effective way for creating small tasks, which aid the main hosting application. A dedicate engine provide one or more tasks to run, by interpreting runtime the complied workflow designed by the user.
The language structure is procedural, similar to Pascal. Several functions are available at the moment of writing, but many more will be added, as well as general improvements.

---

 

At a glance…

Structural features:

• Deeply inspired by the Windows Workflow Foundation: meant to be a very light, yet flexible platform for small/embedded devices.
• The tasks run on the top of the .Net framework, so that their implementation code can be loaded/unloaded anytime, with absolutely no assembly-gluing.
• No special firmwares are required.
• The tasks run in a “sandbox”, which share a custom interface with the hosting application. This is perfect for keeping the application protected, while the custom tasks can be modified by the user.
• The engine is structured in a functional-fashion: that yields to an easier thread-safe concurrency, for running many tasks simultaneously.
• A compiled task is very compact and easy to transfer, as a simple string is.
• Total independence from the communication channel: the data can be sent via TCP/IP, UART, SPI, etc. Any feasible way for exchanging a string can be used.
• The compiled tasks may be stored in any non-volatile medium, such as SD or EEProm. Afterward, the hosting app could load the right task on-demand.

Interop features:

• No skilled programming required, nor complicated IDEs. Even Visual Studio is not required. A full-visual approach has been chosen for creating your own tasks.
• The target engine supports the step-by-step remote-debugging of the running tasks (i.e. over the same channel above mentioned). [COMING SOON]
• Ability to create your own procedures and functions by using the workflow. [COMING SOON]
• Block commenting. [COMING SOON]
• Performance (see below)

Known limitations:

• no support for exception yet. [COMING SOON]
• no support for arrays yet.
• no support for even trivial literal expressions (e.g. “3+5”), and blocks must be used instead. However, this feature is planned.
• not feasible for specialized/low-level tasks, such as buffers, port handshakings, etc. These features should be exposed by the hosting app interface.
• no overload resolution for generic functions/procedures. However, operators are overloaded.

The hardware prototype used for testing the framework.

---

 

Performance.

Here are some very basic tests, just to quantify the typical engine capabilities.

NOTE: It is worthwhile to bear in mind that the engine rely massively on the boxing/unboxing process. The performance cost of that operations is well known. Inside the workflow engine, every single “instruction” may involve several of these processes, thus the limited speed.

 

Tight-toggling the on-board led.

The loop yields a toggling frequency of about 440 Hz.

The above workflow is equivalent to this C# code:

    public class Program
    {
        public static void Main()
        {
            //this is inherently declared by the hosting app,
            //thus outside the workflow
            var led = new OutputPort(Pins.ONBOARD_LED, false);

            //here begins the equivalent workflow code

            while (true)
            {
                led.Write(true);
                led.Write(false);
            }

        }
    }

 

Tight-toggling an OutputPort (other than the on-board led).

The loop yields a toggling frequency of about 350 Hz.

The above workflow is equivalent to this C# code:

    public class Program
    {
        public static void Main()
        {
            //this is inherently declared by the hosting app,
            //thus outside the workflow
            var port = new OutputPort(Pins.GPIO_PIN_D0, false);

            //here begins the equivalent workflow code

            while (true)
            {
                port.Write(true);
                port.Write(false);
            }

        }
    }

 

Tight-toggling an OutputPort by changing the value of a local variable.

The loop yields a toggling frequency of about 150 Hz.

The above workflow is equivalent to this C# code:

    public class Program
    {
        public static void Main()
        {
            //this is inherently declared by the hosting app,
            //thus outside the workflow
            var port = new OutputPort(Pins.GPIO_PIN_D0, false);

            //here begins the equivalent workflow code

            bool temp;

            temp = false;

            while (true)
            {
                port.Write(temp);
                temp = !temp;
            }

        }
    }

---

 

The alpha-version.

The project will be hosted in the http://cetmwf.codeplex.com/ repository.

---

 

The demo.

Enjoy it!