Category Archives: Plain

Plain VM – RTOS

I need a few C/C++ components to implement the Plain VM, one of them is a RTOS . I wrote my own RTOS that runs on both Arduino, ESP32, STM32, Windows and Linux years ago. It is a simple linear scheduler.  I found it quite handy even on Windows applications as it scale better and have some good timing/signalling schemes.

The principle is simple as we loop executing task after task, but controlled by timing parameters and signals. This means we execute a single instruction in each VM before we continue to the next VM.

We will be using this stand-alone as well as together with FreeRTOS, Windows and Linux.

Plain – Parsing VM Instructions

One concern as I implement the VM is the parsing performance on instructions. The Data Descriptor below illustrate the challenge. It is a dynamic structure with bit fields. For every bit field I end up decoding it causing AND /ROTATE instructions.

It is bit packed to save space, but decoding a bit-packed field will cost performance. To increase performance I could use more space – I can’t win, so this will be a horse trade.

For now I will ignore the challenge and be prepared to optimize this later. Plain is not designed for high speed, it is designed for high level logic, so I think it will be ok. I will do a performance test later.

The fastest “bit” packing is a XML string if you ignore space. This will surprice many, but a well build XMP parser is far faster than a bit decoder.

Plain – Call Instruction

I decided to change the Call Instruction to the one below. As we return with an event code we consume the NIX and process the first “On” that will test for event code and continue to next “On” if not.

At this point I can consider dropping “On” and replace it with “If” or “Switch” – one lesst instruction to worry about. But, I will consider that as all instructions are drafted.

I really like this version of Call as it leaves me with a minimal function call if I don’t need On. Let’s test it out:

Func MyFunc(uint32 x)
    if( x = 1)
         Raise E1("Text 1")
         Raise E2(2)
         Raise Error(x, "X is wrong value")
Event E1(string s)
Event E2(uint32 i)
Event Error(uint32 i, string text)

uint32 x

for x=1 to 3
    Call MyFunc(1)
    On E1(string s)
        println("Event E1 is called")
    On E2(uint32 i)
        println("Event E2 is called")
    On Error(uint32 i, string text)
        println("Error is called")

The annotaded figure below show hoe Call would be in this example. I will return to details about On Instructions later.The key with Event’s is that unless it is handled we do nothing, we just fall through. The function will mark Event’s as Optional, Mandatory or Static. If we must have a On we mark it as Mandatory etc.

Plain – Getting the details right

All the Plain entries in here have served their design purpose as I consolidate and wrap up Plain Specification. I usually never bother with a specification on software I do at home, but the complexity and technical design of both language and VM have to many details that needs to be right.

The new VM Instruction header is simplified as shown above.

The old “Object Descriptor” used for parameters have been replaced with a “Data Descriptor”.

The Expression Tables have been moved out from the Instruction and attacched as separate tables at the end of the Instruction Table.

The VM core will be modified, I will return to this later. The main difference is in the Data Descriptor, but also all the details that now get nailed down right so we can move on.

At the end I probably also need to clean up this blog my marking old Plain discussions as obsolete. This happens in engineering as you move forward improving designs.

Returning to Plain

A blog is excellent for sharing ideas down and returning to evolve them later. It’s been a while since I wrote about Plain. I basically stopped because I had other things I wanted to work on, but I think it is time to review/consolidate the specification and move on.

Is it worth it? Will it make a difference?

I work on PLC alike technology as a profession, and I am stunned by how much work that goes into even simple system changes. What I want to achieve is (1) plug in a new sensor or actuator, (2) automatically detect this as an unallocated resource, (3)  put it into a system diagram with a few clicks.

We will get there…

HMI – User Controls

I still have some work to do on the basic drawing/HMI engine, but will soon be focusing entirely on what I call “furniture” as in pre-made controls we can use. I will create some fancy, build in controls, but the most important one is a “User Control” enabling us to create custom controls. Now-keep in mind that the entire HMI is specified in XML format and loaded as we start the HMI Browser, so a custom control will need to be loaded as part of this. For the Designer, we would like to have a library that is made available, but only those that are used to be included in the final XML.

The User Control itself needs to be built from other controls and by adding colors, scaling, rotation etc to create a new control. This means our user control will be a list of build-in controls where we create our own, new interface. As input values can transform to position or rotation we should be able to create most controls these ways.

To enhance our customization capabilities, we have Polygon and Plain. I don’t want to dig into the same security problems as ordinary browsers, so the Plain VM will only have access to HMI Browser, not any of the host OS capabilities. If we need the later we will have other options for that.

Plain Logic Diagram – Terminator

I did a few prototypes to test a graphical programming language a few years back. First one in VC++/MFC and later one in C#/.NET. What I will do next is to write blog entries discussing the syntax and wrap this up as a language specification.

I called this “Plain Logic Diagram” (PLD) by accident and I will use that name for now.

We have already described Plain as an assembly language, so this is a “compiler” that generate Plain assembly. The syntax is based on a combination of classic Flowcharts, SDL (Specification and Description Language) and some new concepts to take advantage of graphic diagram qualities.

The illustrations I use will have to be created in various tools, this one show the terminators of a diagram and is drawn in PowerPoint.

A classic function have a start and an exit. We already know that Plain raise events with different output parameters. In the diagram this is shown as multiple exit terminators with associated parameters. The new part is that we also have multiple input paths with different parameters in the same diagram.

The key principle here is that one diagram is a function with multiple entry points and multiple exit points. Exit points are event’s that either are Static, Optional or Mandatory.

A Static event is a hard-coded jump to another diagram that can not be changed.

An Optional event also have a hard-coded default that the user can chose to override as he uses the function.

A Mandatory event must be present in the diagram using the function.

These are the same principles we decided on for Plain assembly events. In the real diagram we will add notifications to visualise these.

A diagram is the same as a “function”. Off-page connectors can only be through terminators, but a diagram can be as large and complex as you want. Logic is flow-chart like and will be instantly recognized by most people. This diagramming technique have been tested as executable specifications and have proven itself as a superior specification technique in front of customers. The only drawback is that you need a specialized tool to do this otherwise you just end up using far to much time creating diagrams.

So in short – the IDE and language goes hand in hand. A graphical language can only exist if we create a proper IDE/Tool for it.

The diagram example shown here do however suffer from the issue that I can’t see the parameters. I see high level logic, but I don’t see the actual executable details. Also – what about local variables etc?

to be continued…

HMI Designer Annotated

This premature screenshot shows an early version of the HMI Designer. The designer itself is quite simple, you use the menu/commands on top to create a “diagram” and the design tools at left will come up. In this case we create a HMI, but I will re-use the framework for other diagrams later.

An HMI (or GUI screen if you like) is straight forward. You just draw the HMI components you want into the screen and assign names to them. This example only show a few rectangles and ellipses. To edit the properties you click on a symbol and change the properties using the property editor at right.

A tab field on top (not shown) will allow you to select between HMI screens as you design a project.

This concept should be well known for anyone with experience from Delphi, Visual Basic, C# etc. I want to just start with a simple HMI Designer for now. The objective is to create the HMI framework, XML format, HMI Designer and HMI Browser to an usable stage.

I will use Plain as a scripting engine capable of processing HMI events locally. In a later version I will add support for experimental diagram logic and see how that goes. I will write a separate entry about the ups- and downs- using a graphical programming language later.

HMI Browser will in reality be an app that starts up with either a file- or communication path. It can either retrieve the XML from a file or have it sent up from a device.

As for time-line an application of this nature will take some hours to get right. As it also have to be done as I teach myself Qt and are occupied in very tight projects elsewhere it will be something we need to focus on for a while. I do however have plenty of unfinished electronics that we can play with if I need a break.

HMI Designer

One of the applications I want to create is a “HMI Designer”. This is technically very easy as I have done similar applications before. What I will do is to create a graphical application that can design square objects on a form. Each object will have a name that we can use for IO through a serial line. To make the designer a bit more WYSIWYG we animate the objects as if they where “furniture” like Text Edit, Graphic Plot, Grid, Button etc. Each object will have a list of properties that are set/get design and run-time. The result is stored as an XML file and executed by a “HMI Browser”, a special application that download the XML and interact with the system.

This way we can design config HMI’s stored in the embedded devices as XML files and we only need to re-create the HMI Browser to support HMI on Windows, Linux, OSX, Android etc. The concept is not so unlike a Web Browser with the exception that the server here can be small embedded system in a closed loop. Nextion are selling displays build on a similar concept, so in time we can do our own embedded graphics displays as well. I do however want to do tings a bit different from Nextion.

One of the differences is usage of Plain as “scripting” language and interfacing using easyIPC and RSX as well as Ethernet/Wifi. The other difference is that I want a significantly larger object library and take advantage of GPU’s on Raspberry PI etc. I also want this to be a portable software package, not locked to proprietary hardware.

The most important difference is however system thinking. I want HMI Designer & HMI Browser to be building blocks in the CASE (Computer Aided Software Engineering) Tool I want to create on top of Plain. For now we will use Plain and the HMI Designer, but I do plan a fully graphical programming concept later.

As mentioned before with my Plain blogs I want to evolve the way we do software based system development. The network I build here have plenty of fun for C programmers and electronic hobbyists, but we need to create infrastructure and tools enabling this for non-specialists.

Plain – hitting the road

I wrote lengthy blogs about Plain syntax and concepts earlier this year and want to wrap up the specifications and get going. The challenge with pushing on ideas and concepts is that you start getting blind-folded and stuck as you push for results. This is why I prefer new concepts to mature because what seems like a good idea one day might not the second day. Many of the concepts in Plain have however evolved over several years as I started on this far earlier than this blog.

The difference with other programming concepts is that I don’t want to create another language, I want to evolve the way we work so we can achieve more with less. Plain embrace several new concepts aiming for that, but this is untested theory. I believe it will work as expected, but I am also prepared for setbacks as we move forward.

Plain is also more difficult to achieve than normal programming languages because I need electronic devices supporting it and an established infrastructure to build on. Things take time, but we will get there.

Thanks for reading.