Return to Table of Contents
Embedded Image Processing
Under OS-9/MGR
by Carsten Emde
Self-hosted target vs. cross-development
Traditionally, there are two different approaches to developing software for embedded systems: self-hosted target systems and cross-development systems. Self-hosted systems allow for use of identical hardware (CPU, analog and digital I/O, counters, timers etc.) and identical software tools (symbolic debuggers, memory and process visualizers etc.) to develop, to test and to run software required for a given target system. The important advantage of a self-hosted system is, therefore, a considerably higher efficiency in software testing. In consequence, the general recommendation is to use cross-development systems in projects that do not heavily rely on dedicated hardware and to use a self-hosted target system if the complexity of the project and the integration of dedicated hardware require intensive target debugging and testing.
In earlier days, one of the disadvantages of self-hosted targets was that typical operating systems such as OS-9 and LynxOS were less well equipped with state-of-the-art development tools. In the case of OS-9, the problem was that neither standard tools nor a portable graphical user interface was available. Another disadvantage was that the initial investment costs of a self-hosted target were sometimes higher than the costs of a cross-development system, since the hardware for the latter may already have been available. All of these arguments, however, have drastically changed in recent years: OS-9 now comes with a certified ANSI-C compiler; GNU C/C++, GNU make utility and the latest version of the MicroEmacs programmer's editor have been ported to OS-9; a shell similar to the Unix standard shell bash ("Bourne"-again shell) with many OS-9 specific enhancements has been developed; and last but not least, the MGR graphic system has been adapted to OS-9. Submitted to the VITA Standards Organization as a standard graphic system for embedded applications, this fast, compact window manager is available not only for OS-9, but also for LynxOS, VxWorks, SunOS, Solaris and Linux. A port for DEC-Unix that runs on 64-bit alpha stations will be released in summer '96.
Many elements of the MGR user interface such as dialog windows, menu bars, text and image browsers are similar to those available under Motif, Windows, MacOS etc. so that, in conjunction with the above mentioned standard development tools, any application that is written in the C language and runs under X Window, Windows or MacOS can also be realized under OS-9/MGR and run in an embedded system. This also applies to the heurisko image processing system that was recently ported to OS-9/MGR and is now available from ELTEC. As one of the first VMEbus manufacturers, ELTEC has decided to make the MGR graphic system the company's graphic standard and to integrate the MGR server and many MGR tools into every OS-9 development system.
The heurisko image processing system is based on a so-called workspace language that may contain not only references to the provided or dedicated image processing algorithms but also to dialogs via the graphical user interface. Thus, it is possible to develop the entire target application on one of the supported systems (Unix, Windows, OS-9) and to run it in an embedded system - e.g. on a 68k-based VMEbus CPU board. The explanation for the efficiency of such a procedure is easy: It combines the advantages of a self-hosted target system (apparent when ELTEC ported heurisko to OS-9) and cross-development system (apparent when a user runs a heurisko workspace on a target system).
The MGR graphic system
It is generally agreed that the MGR graphic system is one of the most code-efficient graphic systems available today: Despite its unrestricted functionality, the growth of the MGR server size is less than 5% per year as shown in this chart, and an entire MGR-based embedded system (OS-9, MGR server, MGR client application, auxiliary files) may still fit into a 512-Kbyte EPROM.
The MGR server receives input from the keyboard and pointing device (e.g. mouse, trackball, touch panel) and has access to the graphics hardware via the MSD (MGR screen device) interface. Whenever an application window is created on screen, a communication between the MGR server and the application is established via a so-called pseudo-TTY. The application running in an MGR window may be an ordinary program; cursor and full-screen management are then realized using MGR's termcap support. In other words, any termcap-based program can run in an MGR window in the same way as it runs on a terminal. Similarly to this terminal emulation, a full-blown MGR application also communicates to the MGR server using a byte-stream protocol. The advantage of this technique is that an MGR client may also talk to an MGR server via a modem connection or via a telnet network link.
An MGR application with a graphical user interface consists of two parts: the graphic resource and the program source. The graphic resource is developed using the MRe resource editor as shown here.
The resource editor's output may be compiled and linked to the application, but it is also possible to generate an independent binary image of the resource data that is loaded at run-time only. The latter enables distribution of a single binary program and several resources to support various natural languages.
Last but not least, an interface to X-Window and Windows is available that permits running the MGR server on a remote host but displaying its screen in a window of the local graphic system, as shown here.
The heurisko image processing system
The heurisko image processing system mainly consists of an interpreter, a hardware interface to frame grabbers, a software interface to graphic systems and a collection of thoroughly tested and optimized image processing functions.
The interpreter is based on a problem-oriented language used to compose so-called workspaces. The important advantage of this language is that most operators can be used in conjunction with any of the available heurisko object types. Such an object can be as simple as a single 8-bit value, or it can be a two-dimensional array such as an image... but it can also be a sequence of a color movie resulting in an up to seven-dimension variable. For example, let's set the brightness of a pixel to 128 and to increase it by 10:
byte pixel;
pixel = 128;
pixel = Add (pixel, 10);
The same function is used to perform the same operations on an entire picture as shown below:
byte picture [256] [256];
picture = 128;
picture = Add (picture, 10);
In addition to multi-dimensional arrays, data can be organized in structures. Similarly to the C language, the heurisko workspace language is not line-oriented but uses the semicolon to mark the end of an expression. Again as in C, heurisko has functions that can be passed arguments and that may return a result value. Frequently used and non-obvious constants can be assigned to macros to ensure better readability of the code. Last but not least, a number of I/O functions permit accessing of data through the local operating system. Some of these functions provide automatic conversion of bitmap formats such as TIFF or JPEG from and to heurisko's internal storage format.
The hardware interface to frame grabbers is based on the definition of a frame buffer. Except for one hardware-independent frame buffer type (window, see below), the settings of a frame buffer reflect the properties of a given frame grabber. These settings are separated into two different types of variables - mandatory and optional.
The software interface to graphic systems is intended to create a state-of-the-art graphical user interface. The functionality of this graphical user interface includes inspection and manipulation of workspaces, definition of frame buffers and, most importantly, inspection and evaluation of the frame buffer contents. In addition, function slots are provided to input numbers and text, to output numbers and text, to input pixel positions, lines and rectangles within a given frame buffer and to input numbers using sliders. These function slots have been used to realize the OS-9/MGR interface.
Using heurisko under OS-9/MGR frame buffers and inspector windows
A frame buffer may be defined by writing a code section in the workspace language that defines the required 'framebuf' structure
framebuf fb {
string type,
short dispsize [2],
float range [2],
short winpos [2]
and another section that assigns appropriate values to the structure elements such as
fb.type = "win";
fb.dispsize = {256, 256};
fb.range = {-128.0, 127.0};
fb.winpos = {0, 364};
But, heurisko may also provide this piece of code automatically.
Whenever heurisko successfully executes the above declaration of a frame buffer structure, a window of the requested size and at the defined position appears on screen as shown here.
A bitmap can be copied into the inspector simply by assigning the bitmap to the frame buffer structure "fb":
byte image[256][256];
image = Read("gears.tif");
fb = image;
This frame buffer inspector has two menu buttons "Inspector" and "Help". The first one contains the entries "Row plot", "Column plot", "Line plot" and "Histogram". Upon selection of one of these entries, a plot window appears on screen where the requested line or histogram plot is drawn as exemplified here.
The inspector window for a hardware frame grabber is very similar to the example shown above except that the inspector menu contains the three additional entries "Live", "Freeze" and "Snap". In live mode, the content of the inspector window is updated continuously up to 30 times per second, depending on the selected TV standard.
Text output window
Whenever the heurisko executor encounters a text output operator, i.e. the name of a heurisko object followed by a semicolon -
"List of object features:";
obj.pos.area;
heurisko creates a text output window on screen, if not yet available, and prints the specified constants or the contents of the specified variables into the text area of that window. Similarly to the workspace inspector window, there are vertical and horizontal sliders that allow for browsing through the output text as shown here.
Unlike in the workspace inspector, a "File & Clear" menu button is provided. The entries of this button, "Clear", "Save" and "Save as" allow for erasing the text and for saving it to a disk file.
Dynamic slider dialog
Before a slider can be displayed on screen, the required structures must be defined
struct threshpars {
byte values[5],
string name
};
struct threshp {
byte val[2],
short end
};
and appropriate values must be assigned to the structure elements. The following settings, for example, will produce a dialog box with two horizontal sliders scaled from 0 to 255 as shown here:
ListAppend (threshpars,1);
threshpars/0/.values = {0, 255, 1, 10, 128};
threshpars/0/.name = "Lower threshold";
threshpars/1/.values = {0, 255, 1, 10, 255};
threshpars/1/.name = "Upper threshold";
OpenParSelect(threshpars);
InquireParSelect( );
threshp = RetrieveParSelect( );
CloseParSelect( );
The function "OpenParSelect" creates the requested dialog box on screen. The function "InquireParSelect" makes the slider dialog the active window, and the function "RetrieveParSelect" returns the current slider position in the array "val". The information whether the user has clicked on the "Done" or on the "Quit" button is returned in the variable "end". If "end" is true, then the heurisko workspace normally calls the function "CloseParSelect" which, finally, removes the slider dialog box from screen.
If the "OpenParSelect" function is called up with more or less sliders than two as in the example, the shape of the slider dialog box is adjusted automatically and the sliders and boxes are arranged appropriately.
Conclusion
Thanks to the MGR graphic system, any embedded system can now be equipped with a state-of-the-art graphical user interface. This interface may provide all the communication elements a user familiar with other graphic systems such as X Window, Windows or MacOS may expect. In contrast to the above graphic systems, the MGR code is smart and small enough to fit into the restricted non-volatile storage space of an embedded system. Furthermore, the growth rate of the MGR graphic systems is similar to the growth rate of the other components of an embedded system. This enables continuous software maintenance without requiring regular memory and CPU upgrades.
As an example, the OS-9/MGR port of the heurisko image processing system has been presented in this article. This port clearly demonstrates the power and the versatility of the MGR window manager. In addition, it introduces cross-development on the level of the heurisko workspace language, since heurisko workspaces can be developed and tested on any of the supported platforms and run in an embedded system without requiring modification.
About the Author- Carsten Emde has a long history of working with VMEbus-based embedded and real-time systems. As one of the owners of the CE Computer Experts AG in Switzerland, he provides consulting and engineering in form of training courses and software development to machine industry and research institutions. Carsten Emde can be reached by email under <carsten@ceag.ch>.
References:
[1] Emde C: The MGR window manager. OS-9 International, I/1993, pp. 18
Send an email to Carsten Emde
Return to Table of Contents