by Neil Horman
I’ve always liked Trolltech. They make Qt, the cross platform application development framework that forms the basis of the K Desktop Environment (KDE–my desktop of choice). While I don’t normally work in the world of GUI application development, I did like that they provided the embedded Qtopia product, so they definitely kept my interest. (Embedded development was my career in a former life). Recently, they’ve showcased Qtopia in their Greenphone SDK, a fully functional GSM phone with a big video touchscreen, running an embedded Linux kernel. Its a nice looking platform from the marketing glossies, so when Trolltech contacted Red Hat to get us to review their SDK, I jumped at the chance.
Before I dive into my thoughts regarding the SDK, a quick disclaimer. Its a working phone, but don’t expect it to be in your local wireless store. This piece of hardware is strictly being produced by Trolltech for sale as a development platform. If you have GSM service and you dream of having a phone that you can hack your own applications onto, your only recourse today is to spring for the $695 price tag for this kit and hope for the best.
So, to begin, what is the Greenphone? Its an Xscale processor (specifically a Marvell PXA 270) with 64MB or Ram and 128MB of flash, and a Broadcom BCM2121 GSM baseband processor for phone communications. It supports USB via a mini usb port, as well as bluetooth. On the whole it struck me as fairly comparable to something between a Palm Treo 650 and 700, minus the keyboard. Not surprisingly its also sized in terms of processor speed and memory to support a Linux-based software stack rather nicely, which in this case was founded on a 2.4.19 kernel (more on that later).
I’ve been looking and as of yet, I can find no open source support for the BCM2121 chip, which means support for phone communications on this system is handled via a proprietary kernel module. That’s certainly not surprising, since radio communications and open source software are still very cautiously feeling each other out (and anyone who has any involvement with Linux wireless development can attest to that). This will no doubt rub against the sensibilities of some open source purists, but it’s really not that shocking. Give the technology a few years, and this wall, like all others, will start to crack.
Beyond that, it’s pretty stock phone fare handled by standard kernel components. User space is similarly appointed, constructed out of busybox plus the other applications that run the various phone peripherals. There is an ftp and telnet server, which allows you to access the phone via network from the provided SDK over the usb port at a console. This allows you to explore the system very easily and at a low level. All in all, very well put together as a development platform. Robust yet flexible.
But that’s only a small portion of the picture. The real differentiator between other embedded SDKs and this one is its development environment. Being Trolltech, who are known for a nice look and feel primarily through KDE, I expected it to be very slick. Well laid out, fairly intuitive, tightly integrated, etc. Thats why I was somewhat taken aback when I first popped the included CD into my system. There was very little on the CD save for a Vmware image file and some documentation that primarily told me to go download the vmplayer from Vmware. So I was left thinking to myself “Heres a company that, among other things, prides itself not only on the quality of its software, but also the fact that they are one of the few companies in existence that provide windowing toolkits that run on both Windows and Linux. Yet, their development kit doesn’t bother to show that off and instead provides an image of a preset development environment for everyone to use.” It was a poor first impression. It’s well and good for a quick demo or some evaluation, but for anyone with an already existing environment, or for those who would rather not put up with the overhead of having to run a vmware session just to develop for this phone, it comes up pretty short. Fortunately, after a short amount of digging I was able to find all the required binaries for setting up your own development environment for this system. So I can give the CD bits a break.
If you’ve ever developed for KDE before, the Greenphone SDK will be quite familiar. The preset environment uses KDevelop to do most of its development and Qt Designer for GUI development, as seen in Illustration 1 and Illustration 2:
Both tools are well built and intuitive, which is saying something coming from me, as I pretty well keep to vi for my big IDE needs. I decided when I started this review not to plan to write any particular application for the phone, but rather just start a project and add pieces to it in an effort to exercise the phone’s available hardware. I’m pleased to say that it only took about 10 minutes to put together a base project with a UI containing a button that exited the app on the phone. It contained no code beyond what the standard KDevelop project template has, but it was easy to create and easy to build and install, following the quick start instructions on the CD. Granted, this is about the easiest thing you can do with the SDK, but given that I’m neither a common user of big IDE’s, C++ (which Qtopia is exclusively written in), or GUI development, I thought this was a good early sign of a quality product.
So, I managed to get a GUI application running without a headache, but I don’t need a phone SDK to do that. Next I decided that I should play with the other part of this system: The hardware. Some quick exploration on the phones console revealed several ttyS prefixed devices (serial consoles). I had high hopes that they were registered against the GSM chip and that I would be able to use one of them to dial out over the cell phone. Having had enough fun with GUI development for the time being, I grabbed a copy of the uucp package, extracted the source for the old cu program, cross compiled it using the SDK’s included gcc arm cross compiler, and transferred it on to the phone. Unfortunately my efforts were foiled by Qtopia, who locks and manages access to all the devices. Drat. On the plus side, I expected the implication here that Qtopia provided a class library for making phone calls. Sure enough a little searching on qtopia.net revealed the QphoneCall class, which seemed to be just what I was looking for.
Things started to get a little dicey at this point. As I mentioned, I’m not one to feel overly at home with big, everything-plus-the-kitchen-sink IDE’s, and what happened next is why. I went ahead and hacked in a QphoneCall instance to my little project, and configured it to the best of my ability, according to the class documentation, to call my own real cell phone when I pressed a new button that I had added to the UI. The good news was that the documentation was sufficiently clear and well written that I managed to add the class without any compile time errors on the first try. The bad news was that I managed to encounter a slew of linker errors, pretty clearly letting me know that the definition of the QphoneCall class was nowhere to be found in my binary. Unfortunately the Class documents that I had only told me what headers I needed to include in my project, not what libraries that I needed to link against. So I needed to spend a few minutes with find, nm, and grep looking for libraries that might contain the appropriate definitions.
Fortunately, I soon found the libqtopiaphonecall.so library, which was available both on the development environment and the phone, so I had a winner. Of course, shortly thereafter I came to realize that the Makefiles for the project are auto-generated at some point during the build processes (which I was unsure of). So I had no way of persistently adding in the appropriate shared library to the linker command. It took me a good 40 minutes to track down the appropriate config file for the appropriate build tool in the environment to add in the file. Perhaps, had I had more experience using this particular IDE, I would have figured this out more quickly, but nevertheless, there’s no need to bury something as rudimentary as Makefiles inside so many levels of indirection. Or more generally speaking, there is simply no need to take the tools that your IDE relies on and hide them so far away that you can’t quickly get at them when you need to. Suffice it to say, once I found where I needed to make this change, all was well, and my application rebuilt right away.
So of course, once I had this new ability to dial a number compiled into my little program, I loaded the code onto the phone, ran it, and was greeted with an immensely satisfying ring on my own cell phone when I pressed my applications call button. If you buy that, I’ve got a bridge to sell you. Of course it didn’t work the first time. It never does. Or rather if it does, then you’re not doing anything overly useful. And of course, given that this is a GUI environment, it not overly obvious where I can find any console output. The implication there being that without a console, my favorite debug utility (printf), isn’t going to be of much use to me. Fortunately, The SDK comes with a debugger for just this purpose. It actually comes with two debuggers, one for the softphone and one for the actual phone. I started out thinking it would be nice to see how well the softphone worked, since that seemed like it would be a great way to enable parallel development (when I did embedded work, one of the biggest obstacles to development was having sufficient target hardware for everyone to use). So I fired up the softphone and was greeted with the screen in Illustration 3.
I was rather impressed. The phone worked just as the actual hardware did, and the development instructions for the softphone were almost identical to those for the actual greenphone. I rebuilt my application for x86 development (having to track down that qmake config change again to build in all the appropriate classes), and fired up the debugger, seen in Illustration 4.
Unfortunately, I started debugging, only to realize that of course it wasn’t going to work, since the soft phone is great for debugging software, but couldn’t dial a phone number, which is exactly the process that I need to debug. Well no matter, re-targeting for the hardware was easy, and the target debugger worked flawlessly and identically to the soft phone. To make a long story short, I managed to find my problem and was eventually met with the dial out that I was hoping for.
So, having gone through this exercise, what did I walk away with? Mostly I walked away with the impression that, when done right, application development in a big IDE can be quite pleasant. KDevelop and Qt designer’s time as the development environment for KDE has really enabled them to make embedded system development smooth and easy. I’m not a big user of C++, and I never like writing code in languages (and using libraries) that I don’t fully understand, but given that embedded systems development cycles sometimes require that, this environment proved rather helpful. I was able to go from zero to functional application in a matter of hours. Doing the same thing with vi, given my familiarity with the Qtopia libraries, would have taken days. Despite my difficulty when I had to “lift the hood” on the IDE, I think the net result was positive given my time frame. If you’re a embedded developer and you have a need to build an application with UI support, Trolltech’s SDK is worthy of strong consideration.
Win this Greenphone
If you’re a developer who would like to win a Greenphone (with SDK), check out the terms and conditions, then fill out the (brief) entry form with your name, email address, mailing address, phone number, and one sentence telling us about the projects you’ve worked on as a developer.