Several principles have guided us through the development process of Tibbo Basic. Understanding them would help you understand this manual better, and also the language itself. See below:

A Bit of History

Years ago, programming for the PC was the nearly exclusive domain of engineers. The languages traditionally available, such as C, simply required you to be an engineer to program.

However, one day something interesting happened. Visual Basic* and Delphi** saw the light of day. And that changed quite a lot on the PC front. Suddenly, people who were not engineers were finding out that they could actually create something cool on their PC. You could say VB* and Delphi democratized the PC software market.

The situation on the embedded systems market today is quite similar to the situation which existed for the PC market in the pre-VB era. Many embedded systems vendors do offer customizable or programmable solutions -- but to implement those solutions, you would really have to be an engineer and know C/C++ quite well. So, there was clearly a need for an easy-to-use programming system which would democratize this market, as well.

Principle One: Easy To Write, Easy to Debug

Choosing BASIC as our inspiration was the natural thing to do, for us. It's a language which doesn't require you to be a professional engineer. It is easy to understand. This is why it is embedded into many non-programmer products, such as the Office suite. So we went for BASIC.

Another part of the user experience, and a major one, too, is debugging. Writing your application is just half the job. You also need to debug it and for embedded systems, this is where things typically start getting rough around the edges. Many times you have to buy expensive tools, such as ICE machines (In-Circuit Emulators), just to figure out what your code is doing. Sometimes you don't even have the luxury of such a machine, and you actually debug by guessing and trying different things in your code.

With our system, one of our major goals was to offer a user experience which is close to debugging on the PC -- without the need for special tools, such as an ICE machine.

While your program is running on the target (embedded device), you actually see how it runs on your PC. You can step through it, jump to specific functions, check values of variables etc -- all from the comfort of your own PC.

Principle Two: Easy Doesn't Mean Sloppy

Some modern programming languages use certain techniques to make life 'easier' for programmers. They might not require the programmer to explicitly declare the variables he's going to use ('implicit declaration'), or might do away with the need to specify the type for the variable (i.e, use 'variant variables' which can contain anything).

This has several disadvantages. For one, it is just sloppy. After several days of writing code like that, a programmer might not have a very clear-cut idea of what his program is doing, or where things come from. While this is something which may be subject to debate, the next disadvantage is quite real:

This is simply wasteful programming. These techniques can consume quite a lot of resources, specifically memory. On the PC, a variant used to store just 2 bytes of data might take up to 100 bytes. This isn't a problem, because PCs have so much memory these days that it is barely felt.

However, embedded systems are often low-cost and bare-bones, so physical memory is a truly valuable resource. Waste too much of it -- and you would find that your code can do very little. But manage it prudently, and your code will be capable of quite impressive feats even on your 'low-power' embedded system.

So our systems requires you to be more organized. The effort is worth it.

Principle Three: The Purity of Language

Programming systems on the PC usually make no clear distinction between the 'pure' language constructs which perform calculations and control program flow, and hardware-dependant input/output. For example, many languages contain a print statement which prints something to the screen.

Since all PCs in the world are similar, this works. However, this makes little sense for embedded platform, which have vastly different input/output resources. Depending on the device, it may or may not have a screen, a serial port, networking etc etc.

In our system, we separated the language itself (what we call the core language) from the input/output of a particular device. Thus, the language itself remains the same, no matter what device you are programming for. The input/output part is hardware dependant, and changes from platform to platform.

When writing for a specific platform, you are provided with a set of platform-specific objects. These provide rich functionality and allow you to do 'real' work, such as printing messages to the serial port, communicating on the Internet or controlling motors and sensors.

Ideally, Tibbo Basic could run on a fridge just as well as it could run on a time and attendance terminal.

Principle Four: Thin and Agile

A lot of embedded systems are built by scaling down larger desktop systems, and it shows. What's the point of using a super-fast processor if you load it with dozens of layers of nested calls?

All the code TiOS includes has been designed from scratch for running on a very simple processor, and optimized for control applications. It has been crafted to have the minimum possible ROM and RAM footprint and to run as fast as possible.

We built TiOS with Pareto's principle in mind. In other words, if a certain functionality is required by only 5% of applications and yet its existence adds 90% overhead, we did not include it. For example, our BASIC only supports integer calculations. Most other BASIC versions, by default, operate using floating point arithmetic, but these are not usually useful to embedded control (and even get in the way). Another decision was to use a static memory model for procedure variables. Memory is not allocated and deallocated dynamically -- It is assigned on compile-time, which results in great performance improvements.

Principle Five: No B.S

... that is, no babysitting. Development systems intended for rapid application development on the PC will often try to handle every little error or problem the programmer may encounter. If a variable overflows, for example, they will halt execution and pop up an error to let him know. This makes sense for a PC-based product, because you are right there to see it halt.

However, when you are creating an embedded system, you expect it to run at all times, without halting. Nobody will be there to see any errors and babysit your system. Your device is simply expected to work.

This is a major difference also for the development process. In essence, since the whole language is built this way, you will also get much less errors even when doing seemingly 'strange' things, such as putting large values into variables that cannot hold them. The language will deal with it silently, in a very predictable and logical way -- but will not pop up an error.

Principle Six: Event-Driven Programming

Users of VB and Delphi and other Windows-based tools will find this principle familiar. However, if most of your experience with BASIC was under DOS, you might find this slightly odd. Under DOS, you would expect a program to begin from the beginning, then continue and stop. They execute from top to bottom. This may be called linear execution.

For Tibbo Basic, this is not the case. The programs you will write will be event-driven. Your program will consist of a number of event handlers which will be fired (invoked) in response to specific things which happen to your system in real life. If your platform was a fridge, you might want to write a handler for a 'door opening' event. When the door is opened, an event is generated, and an event handler, with your code in it, is fired.

So, you could say that your event-driven application has no beginning and no end. Event handlers are called when events are generated, and in the order in which they were generated.

* Windows, Visual Basic and VB are registered trademarks of Microsoft Corporation Inc.

** Delphi is a registered trademark of Borland Inc.