3
System Structure
epoc.struct
We've seen how to build programs for EPOC. Now we need some extra background information to understand how to write them.
In this chapter, we'll introduce as many issues as we need for the following chapters, without getting deeply involved in much C++ code. All these issues are fundamental for EPOC system design, and all will be essential background as we move to look at coding conventions, the user library, and other basic APIs in the next few chapters.
We'll start with by reviewing the hardware of a typical EPOC machine, from a developer's point of view. Hardware is more limited than that provided by a typical desktop computer, which on the one hand creates many new market opportunities, and on the other hand imposes many constraints on software and software development.
We'll look at the four types of software that need to run on EPOC:
q Applications
q Servers
q Engines
q Kernel
We'll cover the facilities provided by the EPOC base (the kernel plus lowest-level APIs) to support programming. Much of this is standard fare in system design, and will be familiar to anyone who's worked with an OS like Windows NT or Unix.
Then I'll introduce something that's quite unique to EPOC: its optimized event-handling system using active objects and the client-server framework. Although we won't be tackling the details of this framework until much later in the book, everything we do will use it, and its existence is a key enabler for EPOC's performance, compactness, and robustness.
I'll conclude the chapter with two sections on the big picture, to whet your appetite for the rest of the book. Firstly I'll summarize the EPOC R5 APIs that we'll be covering in the book. Then I'll do a quick tour through the application suite, so you can see how they use the APIs, and so get an idea for how you might use them yourself.
EPOC is intended to run on hand-portable, communications-oriented computers. This profoundly affects the design of its software system. So let's begin this section by looking at the hardware facilities more closely.
Here are the main aspects of hardware on an EPOC device:
An EPOC-based system includes
q A CPU: EPOC is designed for 32-bit CPUs, running at lower speeds compared with CPUs in desktops or workstations. Available EPOC Release 5 systems are based on 36MHz ARM or 190MHz StrongARM CPUs. Future EPOC machines may use faster chips, and support for Motorola's M*CORE architecture is also planned.
q A ROM: the system ROM contains the OS and all the built-in middleware and applications. Compare this to a PC, in which only a small bootstrap loader and BIOS are built into ROM, with OS and applications loaded from hard disk. The system ROM is mapped as the z: drive. Everything in the ROM is accessible both as a file on z:, and directly by reading the data from ROM. So programs are executed in place, rather than being loaded into RAM and then executed, as PC programs are. EPOC Release 5 machines use around 12MB of ROM.
q System RAM: the system RAM is used for two purposes: RAM for use by active programs and the system kernel, and RAM used as 'disk' space accessed as the c: drive. The system uses as much as is needed for these purposes: you don't have to pre-allocate some RAM for one purpose and some for another. Usually there is also some free RAM. But since the total RAM on a typical machine is only around 8MB or 16MB, there is a real possibility that RAM may get exhausted, resulting in an out-of-memory error or (if the problem occurs when a file is being written) a disk full error.
q I/O devices, including a screen with 'digitizer' for pen input, a keyboard which may need to be even more compact than those found on laptops, a CF card slot for additional 'disks' accessed as d:, a serial port for RS232, dial-up TCP/IP, and connection to a PC; an infrared port for 'beaming' data between EPOC machines and others such as Palm or Nokia Communicators, or for convenient wireless access to data modems on a suitable mobile phone; and other devices.
q Power sources, including main batteries, backup battery and external power (from a mains adapter).
The Psion Series 5mx has 12MB ROM, 8MB or 16MB RAM, a 36MHz ARM CPU, one serial and one IR port, 640x240 pixel screen displaying either four or sixteen shades of gray, and a digitizer over the screen to support pen input (slightly extended to the left and below to support the sidebar and taskbar). Power is from main and backup batteries, and external (mains-derived) power.
EPOC OEMs have freedom to vary this basic specification quite widely. The Ericsson MC218 is very similar to the Psion Series 5mx. The Psion Revo has a smaller screen (480x160), and an in-built rechargeable battery instead of main and backup batteries; however, while it uses infrared for communication with other EPOC machines and compatible mobile phones, and a docking cradle for communication with PCs, the Revo has no CF card slot. The Psion netBook and Series 7 use a 190MHz StrongARM CPU, and have 640x480 color screens. The Geofox One, an EPOC Release 2-based machine no longer available, used a 640x320 screen without a digitizer: instead, it had a track pad pointer similar to those found on many laptop PCs.
OEMs also have flexibility in the way they manage the ROM and deliver built-in applications. Applications can be delivered on a CD-ROM with the device, to be installed into RAM if the user wants them, instead of being built into ROM — rather as you would bundle software with PCs. There's room for ingenuity in managing the ROM itself: the Psion netBook and Psion Series 5MX Pro have only a very small bootstrap loader in ROM. On cold boot, they load a ROM image from CF card into system RAM — using as much RAM as needed. After this, the RAM used is marked as read-only and behaves exactly like a ROM. This arrangement allows the ROM to be configurable by an enterprise IS department, or field replaced by the user.
We've put together information on machines available at the time of going to press, it's in the appendices.
EPOC supports this variability by essentially the same techniques used in the PC industry: it uses a device driver architecture, and offers an abstracted API for each device, to programs that use that device.
But EPOC is otherwise very different from the PC industry.
q Resources are constrained: the CPU is slower, and there is less memory
q There is no hard disk: we can't do disk-backed virtual memory, and we can't assume there is an infinite amount of room in which to place our program or data files
q Power management is critical: user data is often held on RAM disk, so power must never be lost, even when the machine is switched off, or the batteries are replaced. Data and machine state must be maintained in low-power conditions.
To summarize, you have to make software compact, and you have to tackle errors such as out-of-memory and others. You have to keep going, because EPOC systems virtually never reboot. EPOC is designed from the ground up to help you do this, but you must learn the disciplines this involves and implement them in the software you write.