r economy is also crucial, because hand-helds are expected to run for weeks, rather than just hours, on batteries.
EPOC32 addresses these needs by cramming features that you would expect to see only in a big-iron OS into minimal ROM space: It supports preemptive multitasking, hardware memory protection, and an innovative threading model that yields very low interrupt latency. Psion intends EPOC32 to be at the heart of future generations of smart telephone and communicator products, which means real-time performance is of the essence.
As the
screen shows
, the Series 5 implementation of the EPOC32 OS includes a full set of personal productivity applications -- word processor, address database, sketch pad, diary, world clock, alarm, and sound recorder -- that run under a pen-navigated GUI called EIKON. The EIKON interface is built as a clear
ly separate layer on top of the core OS. This setup allows you to replace the EIKON interface with a fully custom GUI while still reusing the underlying font, bit-map, and rich-text abilities.
Clients and Servers
EPOC32 is built on thoroughly modern design principles using a microkernel, a client/server structure, and object orientation. The kernel provides basic system-wide services, such as memory allocation, thread creation, semaphores, and timers. Some higher-level services are provided directly from the I/O device drivers via an object-oriented User Library API. All other EPOC32 services are provided by system threads acting as servers, which run as separate processes outside the kernel.
The Psion Series 5 implementation includes 10 such servers, among them window, file, database, communications, and font/bit map. A key feature of EPOC32 servers is that they are responsible for cleaning up all resources used by their clients -- after both normal and abnormal termination -- to avoid
resource leaks.
A scaled-down version of EPOC32, used in embedded applications, still provides the core OS services but limits the system to a single thread of operation. This restriction provides increased speed and reduced interrupt latency, which can be important in a real-time embedded system application.
Threads and Superthreads
EPOC32's kernel exploits ARM's memory-management unit (MMU) hardware to provide a separate address space for every process running in the system. Threads are preemptively scheduled within these processes. The kernel executive runs in privileged mode and has access to all parts of the system.
Unprivileged user (i.e., application) threads must access all services via the kernel server. Applications are not allowed to directly access the system hardware, I/O, or interrupt hardware. This architecture allows EPOC32 to run with interrupts enabled almost all the time -- and thus be very responsive to interrupt requests. A null thread, which runs only when the
re's nothing else to do, controls the ARM's power-saving circuitry.
For the very lowest latency tasks, EPOC32 provides "superthreads" that run on the kernel side and allocate their own resources without going through the kernel server. Such a task might be a GSM satellite phone application, where certain events require a response within milliseconds, with a permitted tolerance of just a few hundred microseconds.
A communication that crosses process or thread boundaries is expensive, and EPOC32 servers use tricks to minimize this: Multiple processes aren't allowed simultaneous access to the same data file; the window server queues requests and executes them in batches; the font server shares its heap so clients can BIT-BLT directly from it; and all communications servers run within the same process.
EPOC32 uses an innovative asynchronous model for kernel and I/O service requests. To avoid power-wasting polling loops, each server spawns an "active object" that manages a request and waits on
its completion. In effect, these active objects offer nonpreemptive multitasking within a single thread, so few applications or servers ever need spawn more than a single thread. A word processing application, for example, reads keyboard and pen input, reformats text in the background, and updates the state of GUI controls, all while concurrently using active objects within a single thread.
Engines, Objects, and Embedding
All EPOC32 applications divide cleanly into an "engine" that provides the application's basic functions and a separate GUI that drives it, as shown in the figure
"EPOC32 OS Architecture"
. Applications access their data only via the engine's API methods, never by direct knowledge of its file format. An important EPOC32 module provides support services for application engines and their GUIs, in addition to two core data models -- the stream store and the text content.
Stream stores underlie every data structure in EPOC32: files, the clipboard, even th
e undo buffers. Each application's persistent data is a collection of streams (text, sound, or bit maps) linked by pointers and contained within a single store. This is similar to Microsoft's Structured Storage, except that it's built into the heart of EPOC32 right from the start.
EPOC32 uses its engine-support layer to build several higher-level "views." The Text view provides a user interface for displaying, editing, and formatting rich text; the Chart view provides business graphics, such as bar and pie charts; and the Grid view is a rich text grid that underlies the spreadsheet.
These views provide images for printing as well as for screen display. By reusing them, you can make any application truly WYSIWYG with negligible programming effort. To make a new application able to embed pictures and sounds, you just use a Rich Text view as one of its components. EPOC32 embedding is limited compared to OLE: You can edit embedded documents in place, but you can't embed previously created documents. A
future release will overcome this limitation by adding a linking mechanism based on HTML.
Developing for EPOC32
EPOC32 is intended for final deployment only on ARM7- and StrongARM-based platforms. Psion has built a simulator program, called WINS, that uses the actual EPOC32 code to emulate EPOC32's behavior in a screen window under Windows NT or 95. Only the EPOC32 kernel's hardware abstraction layer (HAL) needed to be rewritten for the Intel x86 CPU, since Win32 supplies all the graphics and file services.
All EPOC32 file-server references are mapped to a designated "safe" area on your hard disk to ensure that buggy development code can't touch your PC files. You can use WINS to develop EPOC32 applications in C++ with standard Microsoft Visual C++ tools and run them directly in the emulator environment. Once your application is fully debugged, you perform a final cross-compile onto the ARM using a tool set based on GNU C++. Later this year, Psion will release OVAL for EPOC32, a Windows-
based rapid application development (RAD) language environment that's much like Visual Basic.
Psion hopes that this easy development path will help it to license EPOC32 not only to other hand-held computer manufacturers but to vendors of set-top boxes, mobile telephones, and communicators. Launching a new hand-held OS that competes with Microsoft's Windows CE takes a lot of confidence, but Psion has reason to be confident in this arena: According to Forrester Research, the Series 3 is the hand-held market leader, with a 33 percent share and worldwide sales of more than 1 million units.
Where to Find
Psion Software PLC
London, U.K.
Phone: +44 171 208 1800
Internet:
http://www.software.psion.com/
A New Epoch for Hand-Helds
