Palm, Inc.
Imagine If

Format for Printing

Format for printing

Request Reprints


By RheS
April 16, 2001

Posts selected for this feature rarely stand alone. They are usually a part of an ongoing thread, and are out of context when presented here. The material should be read in that light. How are these posts selected? Click here to find out and nominate a post yourself!

1future asks (following up on davidsharman's post about that Register report about Motorola canceling their Palm-phone project): "Anyone out there have SW background to explain why PALM OS is "not powerful enough" (from the Register article) to run an internet-enabled cell-phone? Is it something (i.e., communication API)? that PALM will address in OS 4.0 release?"

I'll try, although much of it is a matter of design choice... that is, there are things that you might be able to make work, but you choose to design a product differently because of personal style, or corporate style, or other intangibles. Engineers have even been known to make design choices because they thought that it would improve their resume, so they could get a better job later....

This is going to be long. You are warned.

And let me begin by commenting that The Register seems to have an anti-Palm bias of some sort... perhaps, like some who post here... they're fans of EPOC/Symbian and therefore just jealous of Palm. Perhaps it's anti-USA feelings. Perhaps it's something else...? But that bias has certainly been there... and the fact that this whole story is based on an overheard conversation at a trade show makes it all a little weak. Still, as I said before, Motorola's action makes sense, given that they're cutting out nearly everything.

Also, I should disclose that Motorola is across town from me, here in Chicagoland, as the metro area is known. I know a bunch of engineers at Moto, mostly at their two cellular-related divisions (there are handset builders, and then builders of "infrastructure" which means base-stations sold to cell phone provider companies). I also know engineers who have just been laid off.... But I haven't worked for Moto myself; I did work for 3Com, and spent some of my time in Motorola's labs, testing my product, which Motorola purchased and integrated into a larger system.

But as for operating systems...

There are two flaws with the PalmOS, which make it unlikely to be the controlling processor in a cell phone:

(1) The system has an open address space, with no protection between one program and another. This means that a malicious program can mess with the data belonging to another program. Note that this makes some kinds of Palm applications, like datebook modifications, easier.

(2) The system has a single task scheduler. This means that a given program has control of the processor until it voluntarily gives it up. Palm alarms work because almost every program does give up control to the OS periodically, but they don't have to... and if they don't, they can screw up other tasks that the OS is trying to do in the background: battery management, alarms and display power-savings are obvious ones. Indeed, PalmOS is sufficiently simple that it can't be hotsyncing while you're looking up an address.

Now, these two issues raise havoc with the idea that the phone's transmitter and receiver hardware will be controlled by programs running in the same processor. Obviously, no cell phone is going to be certified (that is, approved to operate on the cell network) if it can be turned into a jamming transmitter by a programming error in a solitaire game! Or if the phone's id can be changed by a program, any hacker can download from the net.

So how do current PalmOS cell phones work? They have two processors: one is the Dragonball running PalmOS and controlling the display and buttons, and a second one running the phone. That second processor runs only code supplied by the manufacturer (maybe in flash memory, so can be upgraded, or maybe ROM) and has a defined interface so that the PalmOS processor can tell the phone to dial and so forth. But user programs don't get into that CPU.

Does the phone control processor have an OS? Probably... but it doesn't matter, since the user can't see it. Perhaps it's a proprietary system invented by the manufacturer, or perhaps it's a commercial real-time system sold by another company (WindRiver, for example... their OS is inside a lot of products). But because there aren't any user-loaded programs there, it doesn't matter. Sure, it could be EPOC in that processor.

If I were the cell-phone designer, I'd use as much of the same code in my Palm phone as I use in other phones... that gets me to market faster. And it doesn't matter what OS that is, since the user doesn't see it. That's how all the Palm phones built so far have worked. And I like the two-processor design, not just because of the separation between user-program and radio, but also because it makes power management of the radio unit much simpler. Cell phones need to keep online constantly... so that the local cell knows they are there for ringing messages and (if this cellular protocol supports them) paging-type messages.

So why would an EPOC-based phone work better? An EPOC-based phone could do the whole job with one processor, saving some cost. True, it needs to be a more powerful processor, because it has to timeshare between running the radio and being the PDA. But there's probably a couple of dollars of cost savings there. There's some risk of hack-attacks to the transmitter... but it should be possible that EPOC could protect those other programs, and the hardware they control, from user-loaded programs. I don't know how well it actually does do, but that's the claim. But the one EPOC device I've actually touched did demonstrate running a communications program at the same time as doing other lookups on the screen.

But there's no particular advantage to using EPOC/Symbian as a phone developer... unless you've already got handset code that runs under EPOC/Symbian. If Nokia has that (or is developing it now), it will be to their advantage to use EPOC/Symbian in future PDA-phones, too.


(a) There was a release (I don't remember if it came from Motorola Semiconductor or Palm...) about a possible chip which combined a Dragonball CPU with an ARM CPU (which is very popular for communications work) to essentially make two-CPUs-in-one. This lets you build the two-processor phone with only one chip, saving space, and, hopefully, some cost. This gossip reported by The Register comes from a Moto handset guy, not a semi-conductor guy. There is no reason to believe that any processor deal is cancelled.

(b) There was a demo at some Palm meeting of some PalmOS programs running in software emulation on an ARM processor. This would allow the ARM to run some other OS (even EPOC, if it supports ARM) and provide a PalmOS environment for the Palm GUI as well as downloaded PalmOS programs. Obviously, the choice of the ARM for this job is arbitrary.

(c) I personally like the two-processor design being used by Kyocera and others now. The main disadvantage is size... since, in theory, the two processors should be able to be less powerful (and so cheaper) than the single processor that does both of their work. Certainly, it's the quickest to market.

(d) PalmOS could be enhanced to provide better protection, and a single-processor phone made out of that. It's impossible to tell if that's what the plan is for future versions of PalmOS, or not. Palm has not been very specific... which makes sense. We'll hear about features as soon as Palm developers (there are a lot of them... and somebody will leak to the trade press) find out.

"Also, I've read several times about Nokia's plan to use PALM as a GUI over Symbian OS. I'm not sure what this really means. From a technological perspective is this like Win3.1 OSapp running over DOS? Doesn't Symbian OS its own GUI interface? Does this mean that if the Nokia units are a success, both PALM and Symbian will profit?"

It's more like running an old DOS program in the "DOS box" under Windows NT... you emulate the simpler environment using the facilities of the more complex one.

But yes, EPOC/Symbian has its own GUI, and it's not clear how well they would work together. This is a flavor of the alternative design (b) from above. But if you hide the EPOC GUI, there's no particular advantage to choosing EPOC unless you already have your cell phone code written for it. You might just as well choose a different operating system, for which your cell phone software is already designed, and use that. Whether it's VRTX or pSOS (two popular commercial RTOSes) or some homebrew OS invented locally, it doesn't matter, as long as it can schedule tasks to tight time requirements (because the cell phone network needs its messages in the right timeslots) and protect the rest of the system from the user-supplied programs, it will be sufficient.

As for whether Symbian will profit, that's more difficult to determine. If the largest user disables the Symbian GUI, then there's not as much incentive to keep enhancing that GUI. It's hard to tell what kind of deal Nokia would make with Symbian; for sure, it won't be very disadvantageous for Nokia... or they'll do something else instead.

This is a long explanation, and represents only my opinion. Thank you for your patience in reading to the end. I'm not at all sure if I've managed to be clear enough... but I'd be happy to have response, including more questions.

Fool On!

Dick Smith