Extras > White Paper > Highlights

OK, I think I understand. What other features of Tibbo BASIC can you highlight?

We carefully tailored it to fit the requirements of embedded and real-time systems applications. First of all, our system is event-driven. This means that your program does not execute as a "single piece" from top to bottom but instead consists of chunks of code that are called in response to events registered by the device. For example, you push the button, this causes a "button pressed" event to be generated, and then a piece of BASIC program you have written for this event executes.

Windows programs work like this, right?

Yes, but "homegrown" firmware usually is not like that. If you want it this way, you need to spend a lot of time on firmware design, or use a rather heavy and difficult to master embedded OS. We bring event-driven programming to you in an easy to understand and use way.

What else?

Second, we have addressed the requirements of the real-time market by making the system deterministic, timing-wise. For example, for the "button" object we can guarantee, that pressing a button will be noticed within a certain number of milliseconds. It doesn't matter how busy the system is or how complicated your program is — once the button is pressed for longer than X milliseconds, an event is generated. For real-time systems, this is a big deal! It guarantees that external events won't be missed.

Third, our system has been carefully designed to offer non-blocking operation. This means that for an operation that requires a lot of time, execution is completely asynchronous to the execution of your BASIC program. For example, supposing you system needs to establish a TCP connection with some other host on the network. You insert a certain "connect" statement into your program. Now, when TiOS gets to processing this statement, it takes note of what needs to happen, and then the execution of your BASIC program continues right away. Meanwhile, a separate process, fully independent of the VM, handles the actual connection establishment, which can take substantial time! Your BASIC program is not "blocked" while a connection is being established.

This is special?

YES! Even on Windows there are a lot of blocking operations. For example, when you try to send some data out of the COM port, your program will be paused until all the data you wish to send goes out. For real-time systems, this is simply unacceptable! On our system, when your program says "send", the execution continues even before the first byte leaves the serial port.

Fourth, and the last feature I want to explain is the separation of the language itself and the I/O. We call our BASIC a "pure" language because it does not directly include any input/output functionality. In most languages, there is always some I/O mixed in. For example, in QBASIC for DOS you have a PRINT statement that outputs a string of text onto the screen. Our language does not include anything but logical and mathematical "facilities".