Simple Multitasking Executive

smx™ is a real-time multitasking kernel for use in embedded systems. It is specifically designed for demanding real-time applications. smx offers a full suite of 100 kernel services, yet emphasises simplicity and ease of use.

Features

Task Management

Full task control including create, delete, start, stop, resume, suspend, lock, etc.

Scheduling

Pre-emptive, time-slicing and co-operative scheduling. Unique 2-level interrupt handler to minimise interrupt latency.

Memory Management

Near heap, far heap and dynamically allocated regions. Block pools, message pools and fast block pools.

Timing & Timers

Real-time and elapsed-time clocks. Wake-ups, time-outs and precision delay. Cyclic and one shot timers.

Input and Output

Pipes and buckets for character I/O and macros for interrupt management.

Intertask Communication

Message exchanges, semaphores and pipes. Near and far message pools. Dynamic messages.

Event Management

Count events and monitor combinations of flags.

DOS is optional

Works under DOS or standalone, can provide DOS emulation if required

smx Technical Aspects

Pre-emptive Scheduling

smx is a true pre-emptive kernel. Each task is assigned a priority. (More than one task may have the same priority.) Normally, the task which has the highest priority and is ready to run is the one that runs. If more than one task at this priority level is ready, the first task at the level (i.e. the one waiting longest) runs. Tasks become ready to run due to interrupts or due to smx calls made by the current task. Following either, the scheduler checks to see if a higher priority task has become ready to run. If so, the current task is pre-empted and the new task takes over. If desired, a task may lock itself. It will then be allowed to run without pre-emption until it unlocks itself.

Easy To Use

smx exhibits a symmetric structure. For example, a task can stop, start, suspend, or even resume itself. These are not necessarily useful operations but they do sometimes happen due to special circumstances. smx imposes very few special cases (often the source of programming errors and additional code). All operations which suspend or stop a task are subject to timeouts. Hence a task cannot just disappear from action. (Of course, timeouts can be defeated if desired.) Extensive error checking is implemented. (See Error Manager.)

Robust Design

smx is a robust kernel designed to be used in demanding applications. It has undergone over eight years of intensive user testing and appraisal. During this period there have been numerous revisions to fix bugs and to add refinements. This process continues today. It is our goal to make smx more and more robust, easier to use, and less susceptible to errors and malfunctions.

Written in C

smx calls are written in C and are invoked like ordinary C functions. Only the smx86 scheduler is written in assembly language (which was done for performance). smx control blocks, buffers, and other objects are defined as C structures, C arrays, C pointers, etc. Because of this, smx is completely compatible with C and C++. There are no transition routines nor obscure assembly language constructs. Complete C header files are provided. smx works well with C source debuggers such as Turbo Debugger, CodeView, Soft-Scope, Paradigm DEBUG, and SingleStep.

For those who prefer assembly language, we provide a set of assembly macros to invoke smx calls in a clean, readable manner. We also provide all of the necessary assembler include files. Finally the smx platforms provided illustrate the blending of C with assembly language (which is generally the best approach for embedded systems).

Layered Ready Queue

The ready queue (rq) has one layer per priority level. When queuing a task, its priority is used to index into rq and the task is placed at the end of the level. No searching is required. A pointer, rq_top, is maintained to point to the highest occupied level of rq. Hence, finding the next task to run is also very fast. The layered ready queue feature enhances performances and deterministic behaviour.

Full Range of Stack Options

One drawback of most multitasking kernels is that each task must have its own stack. If using stack-intensive C library functions such as print(), stack size may need to be 500 bytes for 16-bit processors and 1000 bytes for 32-bit processors, or more. If an application requires 40 tasks, then 20K to 40K bytes of RAM is needed for stacks, which is significant for many applications. smx implements a unique solution to this problem. A task can be assigned a stack from a stack pool when it actually begins running. As long as the task is running or suspended, it retains the stack, but if it is stopped its stack is returned to the stack pool. Tasks may wait for messages, signals, events, timeouts, etc. in either the suspended or stopped condition. Hence, a 40-task application might require only 10 to 20 stacks.

Those tasks requiring exceptionally large stacks, or private stacks for other reasons can be permanently bound to stacks at the time they are created. These stacks are allocated from a heap.

smxHeaps

smx heaps are designed to be more robust than those supplied with C compilers. Allocated blocks are separated by heap control blocks (ChB's) rather than just pointers. An hcb contains a pointer to the next hcb, an onr field, and fences at the beginning and end. The onr field identifies the task which owns the block. The fences are fixed patterns used to detect heap block overflows. They are checked whenever a heap block is freed and also may be periodically checked with heapchk() or heapwalk() calls.

Segmented smx86 provides both a near heap and a far heap. Other versions of smx provide a single heap. These may be used in place of compiler heaps or in conjunction with them (thus providing up to four heaps!) The smx heap calls have slightly different names (e.g. _fmallocx() instead of _fmalloc() ). To replace standard heap calls, they are simply renamed with macros or called via translation functions which are included. smx heap calls are task reentrant.

Low Interrupt Latency

To minimise interrupt latency, smx uses a two-level foreground structure, rather than disable interrupts in critical sections of kernel calls. (This same design has been used in well-known operating systems such as RSX11 and Windows NT.)

The two levels are: (1) interrupt service routines (isr's) and (2) link service routines (lsr's). isr's are invoked by interrupts. They, in turn, invoke lsr's to make kernel calls. By restricting isr's from making kernel calls, interrupts need not be disabled in any kernel calls, nor in 98% of the scheduler. In smx, interrupts are disabled only in a few very short sections in the scheduler. Hence, interrupt latency is extremely low. See chart in smx86 or smxPPC brochure for the maximum interrupt latencies on sample processors.

Other Special Features

Any of the following can be especially helpful for a given application. These unique features distinguish smx from other kernels.

• Small Size
  Each smx function is in a separate module to minimise how much is linked in. Total smx size varies from a reasonable minimum of about 8 KB to a maximum of 36 KB, depending upon how many functions are used.
• C++ API Available
  smx offers an add-on package (smx++) which recasts smx as C++ objects. This package has recently been reworked to enhance its usability for object-oriented programming. See smx++ brochure for details.
• Dynamic smx Objects
  All smx objects (tasks, exchanges, semaphores, messages, etc.) can be created and deleted at any time. The ability to delete objects that are no longer needed helps to minimise an application's memory requirements.
• Timeouts on All Task Waits
  All smx calls which cause tasks to wait are equipped with timeouts. If the expected event does not occur within the timeout, the call returns with a zero value.
• Timers
  Both one-shot and periodic timers are supported. These offer low overhead and good accuracy. Timeouts start foreground tasks (lsr's), which can make kernel calls.
• Counting Semaphores with Thresholds
  Support mutual exclusion, neuron-like behaviour, fuzzy logic, etc.
• Message Priority & Multi-level Exchanges
  Exchanges allow anonymous message destinations. (i.e. The sender need not know the receiver.) Message priority gives increased control where necessary.
• Priority-pass Exchanges
  Facilitate client-server designs -- message priority is passed to the receiving task (server).
• Hook
  Adds task-specific exit & entry routines to save & restore special context information or to perform special functions when switching tasks.
• Event Manager
  AND or OR combinations of flags. Multiple tasks may wait at each event table.
• Event Queues
  Precision counting of events or ticks.
• Full Range of Memory Options
  As well as heaps, smx also supports block pools and special, very fast block pools. The latter are used primarily for smx and C++ objects.
• Layered Queues
  All smx queues are layered. Each layer may correspond to a single priority or to a range of priorities.
• Test Mode
  Its full error monitoring can be disabled for increased speed and reduce size by a compiler option.

   

smx Speeds Development

Simplicity

The hallmark of simplicity is to be able to proceed on a straight path toward one's objective. The following features of smx contribute to this:

• integrated platform to start from
• good examples to follow
• well-written, accurate manuals
• availability of source code
• minimal restrictions upon smx calls
• robust, flexible, open structure
• good support

Many of these features are discussed in the sections which follow.

Integrated Platform

A single, integrated platform is provided for all versions of smx. This platform, called the protosystem, is a skeletal smx application, to which demo tasks and code are added for other smx products (e.g. smx++, smxFile, smxNet, etc.) Full source code is provided for the protosystem and for each demo. Demos provide helpful examples and possibly even some useful code for your application.

A single make file serves to build this integrated platform for a particular combination of products. The combined protosystem and demos show not only that the products work together, but also how they work together. To develop your application, you simply remove or rework the demo modules and add your own.

The protosystem runs on your target, whether it is a custom design or a common PC. The ability to run on a PC is convenient during development. (For target processors other than the x86 family, PC development is accomplished by running under a simulator/debugger.)

The protosystem illustrates how to replace C compiler start-up code start-up code appropriate for your application. It shows how to configure and use smx. It makes no DOS or BIOS calls. It also shows how to simulate I/O and interrupts. Many smx users have successfully debugged their code on a PC without target hardware (which is invariably late when it is custom-designed).

Full Support For Compilers

We have exhaustively tested smx with the latest versions of the above compilers and with the tools which come with them (make utility, librarian, linker, assembler, and debugger). We have made all libraries and platforms for all versions and models with no errors and usually with no warnings, even at the highest warning levels. smx libraries are pre-made, and smx platforms come with all necessary make and batch files. Using these is easy. For example, to make a specific platform simply enter:

             mak m v

     m = memory model = s, c, m, or l
     v = version = (blank), t, or v

The memory models are (for segmented x86): small, compact, medium, or large. The versions are: non-test mode, test mode, or debug. To run a platform:

             run m v

To test a platform:

             test m v

What could be simpler? A lot of work has already been done. All you need to do is to start building on the platform best-suited to your needs. The smxphilosophy is to make your job as simple as possible.

Error Manager

The smx error manager monitors over 70 errors types. These include out-of-range parameters, broken queues, heap overflows, stack overflows, invalid control blocks, null pointer references, out of resources, and others. When an error occurs, a unique error service routine (esr) is automatically invoked via a jump table. The esr records the error type, time of occurrence, and current task or lsr in the error buffer (eb). It also increments a unique counter for the error and loads the error i.d. into a global, xerrno. The esr can also perform unique functions for the specific error type. esr's are user-extensible.

The error buffer is allocated from an smx heap. Its size is user-controlled and can be very large (up to 6550 records). eb is viewed as an array of records under a debugger. It may be viewed symbolically with smxProbe. (See smxProbe brochure for details.)

All smx calls return 0 if an error or a timeout has occurred. Hence point-of-call error monitoring can easily be implemented as follows:

     if(smx_call())
          /* normal action */
     else
          /* error action */

The error action code can access eb (via the eb last pointer) to determine what action to take. Alternatively, the user may customise esr's to deal with errors centrally.

The error manager is omitted from the non-test mode libraries to permit smaller and faster-executing code. The error manager source code is included in the smxdevelopment kit.

Documentation

Helpful Manuals

smx manuals are well-written, complete, and accurate. They are easy to use. The manuals are a convenient size (7" x 9") which fits nicely alongside a keyboard. They are spiral bound so that they will lie flat or can even be folded backward. The manuals are as follows:

Quick Start

40 pp. Cookbook style instructions (1, 2, 3...) on the left page with sample code on the right page. Topics are covered such as "What You Will Need," "Beginning a System," "Creating Tasks," and "Sending and Receiving Messages."

User's Guide

234 pp. Tutorial manual with a full index. This manual presents the theory of smx in two main sections: "How To Use smx" and "Advanced Subjects." We have received many compliments on this well-written manual.

Reference Manual

224 pp. Combines the standard reference manual format with a comprehensive glossary. Together, the two sections 100% define smx . Each smx call description explains all details of the call and has one or more relevant examples.

smxSummary

41 pp. Brief description of each call plus other useful information. A convenient quick-reference for design and coding. (5.5" x 8.5" centre-stapled.)