Okay... I've been planning on writing a review of my Nokia 770
for my own blog, Stacking Fault
, for a couple weeks now and have yet to find the time. I figured I would use this journal entry as a place to store my thoughts until I have a little more time to write a proper article.
Figuring Out I Wanted One
So I've been working with small embedded devices for a while. Some of my first serious programming gigs were doing real-time control things for Commodore 64's and Apple ]['s back in the day. More recently I've been doing PalmOS, WinCE, Symbian, iTron and J2ME programming. If you've ever had to deal with these platforms then you probably know why I'm nostalgic for the old days. I've also done a fair amount of Unix programming, mostly building development tools and encryption libraries. Way back in the olden days I worked for a company called Convex that had a "real time Unix" operating system. I remember I chuckled when I first heard this term and in some ways I still do.
The main reason I chuckle about "real time" Unix is that when I learned about operating system design, the conventional wisdom was you either had "real time" or "time share". "Real time" meant your program had more-or-less complete control of the CPU and you needed it to quickly respond to I/O requests. "Time share" on the other hand meant you shared the CPU with other users (or at least other programs.) Your program ran for a little bit, then the OS "pre-empted" your program to give a time slice to another program. Modern systems were configured so that this was transparent to your program. When your program was halted, it's entire state was safely stored in a protected region of memory.
So the reason that "time share" was considered the opposite of "real time" is that time-share systems never knew when they would get interrupted; real-time systems on the other hand had to know these things so system integrators could figure out if the programs they were loading up on the device could handle the typical I/O load. So when I heard about "Real Time Unix" it was as if someone was taking great liberties with the concept of "real time" or the concept of "Unix."
The Convex solution (like many modern solutions such as DROPS
) is to put a "real time layer" underneath the Unix/Linux kernel. Using this technique, you can (or should be able to) insulate Linux from the device hardware and run it as a task in a "real time" OS. In other words, you write another smaller OS that knows how to handle real-time I/O requests and when that OS isn't doing anything important, you run the Linux kernel or Linux processes.
But nobody's really doing that these days, they're all running Linux directly on the hardware. (Actually this isn't really true... Early last year Qualcomm
announced they (like every other mobile device manufacturer) are going to start supporting Linux. Later last year they announced [PDF]
they're actually using L4/Iguana to do real-time Linux.
So I've always been a little curious, so I've been trying to get some version of the L4 microkernel to run on a Cirrus EDB9301 Development Board
I have kicking around. I never had too much luck with the project, mostly because I just don't have the time.
Then a couple of co-workers bought 770's and I fell in love with them after seeing them. For being a Tablet, they're a beautiful form-factor. They have a 800x480 screen and are handy enough to carry about easily. They're slow as molassas, which is kind of funny since they're supposed to be running a 250Mhz TI OMAP processor. My suspicion is the OS is dreadfully mis-tuned for the hardware. Based on experiences with other, similar systems, the interface should be at least as twice as fast, and then with optimization, it could be an order of magnitude faster.
In a couple of weeks after my personal life has settled down, one of the first things I'm going to try to do is port the Squeak
virtual machine to the thing using the current Maemo
tool-chain. Squeak is not really known to be a speed daemon, so if I can get decent performance out of Squeak, then I'll know something's up with their modified UI widget toolset. From there I think I'm going to try to find out how to write directly to the screen and see how much of a performance hit we get from their UI framework. Eventually I would lke to get some form of L4
up and running on the device. But I'm not a big fan of the C++/IDL solution the Pistachio guys are working on, and I'm also interested in trying to figure out if a Single Address Space OS like Munghi
would be a performance boost for this class of device.
So, in short, I decided I wanted one of these devices because I think the form-factor is beautiful, and it deserves to have a reliable, secure OS on top of it. Please don't take this to mean that I think Maemo
is "bad". They're doing a phenomenal job wading through a lot of issues and supporting a number of different stake-holders. Future versions of Maemo for the 770 are, I am sure, going to be a lot speedier and come with more features.
Getting a 770
Getting one's hands on a 770 is a bit tricky. Some people I've talked to believe this is because Nokia can't be making money on these things. This belief stems from the fact that the screens are very, very nice. Plus you add the WiFi and Bluetooth and you get a BOM cost over $425. At the time I'm writing this, the 770 retails for about $360. So our theory is that Nokia's just seeding the developer market and they're not planning on making the 770 in mass quantities. Keep in mind that this is idle speculation... though I've been writing software for embedded devices for a while, I have no real way of knowing how true this suspicion is.
But I do know that a lot of early adopters were ticked off by Nokia's handling of pre-orders. I wasn't paying attention to the details of the story, but essentially what happened is this... Nokia told people they were going to ship them in November '05, and even opened up a site where you could pre-order them. So imagine everyone's surprise when they announced shipments were going to be delayed until January. Yikes. Engadget has a story about the whole sordid affair on their site
Topping things off Nokia started passing these things out to bloggers and reporters while developers were left waiting for their orders to be fulfilled. This kind of ticked off the user community who pointed out that it's the developers that make or break a platform, and giving the early devices to bloggers and reporters when the device is "not ready for prime time" will only get you bad reviews from the press and tick off the developers. The guys at Internet Tablet Talk
posted an An open letter to Ari Jaaksi of Nokia
, complaning about this practice (amongst other things.)
My experiences weren't as bad as some peoples, but I've got to say, I really had to keep on top of the Nokia guys. More than once they put my order on "hold." The first time they claimed they sent me an email saying I was supposed to call them to confirm the order. I never got such an order and I carefully checked my spam logs... nothing from Nokia. So clearly they have a little bit of work ahead of them. Like for instance... if you're going to require people phone in after making an online order, maybe you could put something on the order receipt page. After completing the order process on the web page, I didn't realize I needed to do anything else. The mysterious email you said you sent never made it to my mailbox. I only called to check on my order because I had heard rumors of other problems with the order process.
Well... I finally got my tablet, and I can confirm, the hardware is very nice. The software needs some work, however...