Embedded Controller Technology

Of the vast number of programming languages at large, C is undoubtedly the most prolific. But, with the advent of the web and browser technology, scripting languages have been given a new lease of life.

The biggest benefit of a script, in a nutshell, is that it doesn't need a compiler; it is interpreted 'on the fly'. Another advantage is that it enables an array of tools, making use of the language's immediacy and relatively simple structure to create the visual programming environment.

This makes their use even simpler. For instance, WYSIWYG tools are popular for web design because knowledge of HTML isn't a prerequisite. But because what you see isn't always what you get, a real command of HTML (and others such as VisualBasic and JavaScript) is a valuable skill, even with their relatively short learning curve and the wonderful array of programming tools available.

For good reason, most scripting languages remain high level - systemically speaking - and dedicated to a small number of applications. Typically, these would be inter computer communications, where there aren't any people to get in the way and mess things up.

The other real difference between scripting languages and compiled languages is that different people use them. Embedded software engineers are typically in the C camp, whilst 'programmers' per se will slip seamlessly between scripting languages of all kinds used in the networking world, as well as C, Java and others.

Whilst software engineers and programmers are breeds apart, they are often grouped together in the minds of those outside the software domain as their skills are based on the same languages, whether in the embedded world, or networking and infrastructure.

Software skills in all areas are sought after and often in short supply. Short supply and high demand creates a high price tag, meaning it is not always viable to maintain a full time team of programmers. In particular, in the embedded world, where entrepreneurship is rife, those software skills can often be an overhead that smaller companies cannot sustain and often couldn't make full use of anyway.

Microcontrollers go a long way towards solving this problem. Often employed for simple control functions and not requiring reams of programming, the assembly language approach requires no more discipline than good engineers would employ in all areas of their work.

But it doesn't stop there. As simple as assembly code may be, it still requires some understanding of the basics of software - such as assembling, syntax, linking files, file structures and managing resources.

A more elegant solution to keeping it simple uses none of the usual software chattel; instead, it uses a straightforward, high level scripting language executed directly on the chip.

Simply put

This high level scripting language has been around since 1986, when it was developed by Cambridge based Micro-Robotics (www.microrobotics.co.uk). Written specifically to enable non programmers to tackle the typical control tasks that microcontrollers do so well, the language has evolved beyond 'simple' chores. Today, it can handle relatively complex communications protocols, such as the ubiquitous TCP/IP.

From its early days of controlling robots using the BBC Micro, the company has always been a proponent of high level language. The original syntax for the language was based on Logo, a much underrated scripting language which, among other things, enabled children to develop a program rapidly to control a 'turtle' using directional commands.

Meanwhile, the industry at large soon picked up on the potential of the language so Micro-Robotics decided to 'industrialise' it. This became known as Scorpion and powered the Scorpion K4 - a credit card sized control system based on an H8 microcontroller from Renesas (formerly Hitachi).

In the early 1990s, the language underwent a transformation to make it object oriented - eventually the name changed to Venom - but it has stayed true to its H8 heritage, highlighting one of the downsides to this simple, yet versatile, language.

Simple and versatile it may be; portable it isn't. This isn't a big problem for Micro-Robotics, because its main business is selling the boards on which Venom runs. Although it would licence Venom to someone else to port to another architecture, it isn't likely to happen because of the work involved. Whilst the language itself is written in C and is, therefore, relatively transportable, the real value is in the drivers, which would need to be ported to the alternative architecture at considerable cost and effort.

With all this functionality built in, it might be reasonable to expect a large memory footprint, but it isn't that onerous. The compiler takes a mere 40kbyte, while the drivers require around 150kbyte. Other requirements consume a further chunk of memory but, typically, the boards are supplied with 500kbyte of memory, with nearly 200kbyte for the user's program. There is no memory map to worry about either as that's taken care of on chip. With this level of automation, it is easy to see why it is so closely linked with the architecture.

No antidote required

This doesn't faze Micro-Robotics, which has always maintained that Venom, however attractive, is really only a 'calling card'. Its main business lies in off the shelf and custom made boards, often enabled by Venom. And given the trend towards board level design, it is easy to see why.

There are a number of companies that sell single board computers based on an industry standard or proprietary format, so there is little value in redesigning the wheel. But, arguably, Micro-Robotics takes it a step further by asking 'why reinvent the software?' Or, more precisely, why spend effort on the software when the value is in the end function. By deskilling software, the emphasis moves back to the application, which drives the development.

Software engineers may disagree and, to be fair, they have every right to as Venom isn't perfect for every application, it isn't an 'open' standard in the classic sense (which is very much the flavour of this millennium) and it isn't transportable.

Venom has a few other 'isn'ts'. It isn't supplied with a graphical user interface and there isn't a development environment of any sort - integrated or otherwise*. Code is fired down a direct connection to the board in its text form and the board fires back an instant indication of whether the code is any good or not. There isn't a compiler to go through, because the code is semi interpreted - the compiler lives in flash alongside the microcontroller. This means that as soon as power is applied, you're ready to go. There is also no way of loading the code back from the board to a pc - which, Micro-Robotics claims, maintains single source control whilst providing a relatively high level of security.

This 'blind' approach may grate with software engineers, but non aficionados seem to love it.

http://www.neon.co.uk/tech/editorial.cfm?categoryid=351&editorialid=6381

*Since this article was written, Micro-Robotics have released an Integrated Development Environment for Venom-SC.