The following is an extract from an internal working document, part of a development of a new programming tool set to run on our upcoming ARM based embedded controllers, named Next Generation (NG). Reference is made to Tabula
.
This is a table based state machine design tool that can be executed in simulation mode and generates final code. Tabula is only one of the languages we will be providing.
The basic modular unit of an NG program is an
Acter. An Acter will correspond to a source file, which will be written in any of supported the languages.
A complete program will consist of one or more Acters plus underlying services provided automatically by the firmware and IDE.
The Acter concept is based to some degree on Object Oriented Programming, but differs in several ways. The most significant shared concept is that of
encapsulation.
Encapsulation means that the only way in which anything outside the Acter can instigate an exchange of data or commands is by making calls to the Acter's
Methods.
Methods are effectively subroutines, functions or words (call them what you will) that give access to the Acter's internal data and operations.
At no time can anything outside the Acter directly access its internal data or any hardware resource that belongs exclusively to the Acter.
An Acter consists of the following elements:
- 0, 1 or more free-running "tasks" (aka processes). A task is a bunch of normally non-terminating (endlessly looping)
code that runs in its own multitasking thread. This code must be designed to yield the processor when it has nothing to do,
in keeping with the underlying cooperative multitasking operating kernel. Typically a task will implement a
Finite State Machine.
- Local data (variables). Except for temporary stack variables all data in NG is static.
- Methods (code). A method may do something as simple as setting or retrieving a variable. It may also be the equivalent of a C function that computes a result from internal data or caller-supplied arguments.
A closer look at Tasks
The tasks should be viewed as semi-autonomous entities. They run in their own processing threads and have a life of their own. A task exists, and acts, even if the host Acter is not being called through its methods (i.e. is otherwise dormant). The main thing that differentiates Acters from conventional objects in Java, functions in C or subroutines in Basic is that Acters contain free-running code.
An task can make calls to the methods of other Acters. A task can also directly read or write the local variables within its host Acter. What is quite impossible, however, is to somehow make calls to a task from outside the task itself. All transfers of information in and out of the task must be initiated by the task itself.
NB: Don't assume tasks and Tabula tables are the same thing. Tasks can be written in several languages (Tabula being only one). Conversely, tables may not necessarily be free-running tasks.
The local variables
Local variables are the only medium available for transferring information into and out of tasks. The variables act as dead letter drops ... To send the task some data, drop it in the variable and wait for the task to come and read it out. To get data from the task wait for the task to drop the data into a variable, and fetch it from there.
The methods
The only way to affect a variable inside an Acter is via one of the Acter's methods. It follows that the only way anything inside an Acter can communicate with a task inside another Acter (say to send it some data or a command) is via method calls affecting internal variables.
