Linux on board: Developing for the Nokia N810
The Nokia N810 alarm interface allows developers to efficiently and easily set alarms programmatically. Peter Seebach illustrates how a small command-line program can hook into this API and make good use of it.
The most serious limitation of the Nokia 770 as a potential PDA replacement was the lack of any way to set alarms that could wake the device. A much-improved alarm interface was introduced on the N800 and is still present on the newer N810. In this article, I take a look at the C language API to the alarm interface, and suggest an interface to make this available to shell scripts or programs in other languages.
First, a brief overview of the N810 is in order. The N810 is an embedded handheld system with an 800x480 display. It has Bluetooth, wireless, and USB connections. The underlying kernel is a 2.6.21 Linux® kernel, adapted for the hardware.
The N810 is fairly similar to the previous N800. New features include GPS and a built-in keyboard. The only way in which the N810 might seem less flexible than the N800 is that it provides only a single available MMC/SD card slot. The N800 provides two slots for user-provided MMC/SD cards, both full size. The N810 comes with a hard-wired 2GB card in the "internal" slot and a miniSD slot for removable media. (This can be quite frustrating if, like me, you've accumulated stacks of SD media over a few years of playing with embedded systems.)
The development environment for the N810 is essentially the same as that described for the N800 (see my other articles on the 770 and N800). There have been updates to Scratchbox and the maemo environment, but the essential process remains the same, and the Scratchbox and SDK install remain quick and easy. There are two major changes that are likely to affect a regular developer. The first is that xterm is installed out of the box; this is a big improvement. The second is that, when you install the openssh-server package, you are prompted to set a new root password. This is a big step up from the previous behavior: a default root password of "rootme". Obviously, you should pick some other password.
The alarm API
The alarm API was introduced in the maemo 3.0 release last year. It presents a set of calls to interact with the alarm daemon, which provides alarm services. You should prefer using this interface to trying to write your own, and you should definitely stay away from writing your own timer code in an environment like the N810. Power management on embedded hardware is an advanced topic, and it is easy to get it wrong; instead, just hand the job off to the specialized code provided.
Even if your alarm code is written elegantly and well, there is a compelling advantage to a centralized service. Imagine that you have written a perfect alarm interface, which has to wake the system only rarely, perhaps once every five minutes or so. This will have almost no impact on battery life. Now, imagine that other people, just as skilled as yourself, write similar interfaces. With several of them installed, the system must wake up several times every five minutes. Worse, users tend to pick different intervals. So, if you have one thing that wakes every three minutes, and one every five, and one every seven, you end up with the worst of all worlds: even though no individual alarm goes off more than once every three minutes, you actually have an alarm about once every two—and worse, pairs of alarms going off may involve separate wake and sleep cycles. So use the standard API.
The alarm API can do a number of things. In essence, it can configure the behavior of a scheduled notification with a great deal of flexibility. An alarm event may or may not involve a display to the user. The three primary things alarm tasks can do are display messages, run programs, or send messages over D-Bus to other applications. You might not think of all of these as alarms, but they share substantial functional overlap with the simple reminder messages that a calendar application could provide. In short, if you are implementing enough alarm functionality to support calendar applications and the like, it is better to generalize a little further and handle everything.
Alarms are stored as XML in /var/lib/alarmd/alarm_queue.xml. This file is moderately human-readable, but does make liberal use of magic numbers to encode flags. You can get a lot of insight into the components of alarm event structures by creating events using other applications, then reading the XML stored in this file.
Click to read more
The most serious limitation of the Nokia 770 as a potential PDA replacement was the lack of any way to set alarms that could wake the device. A much-improved alarm interface was introduced on the N800 and is still present on the newer N810. In this article, I take a look at the C language API to the alarm interface, and suggest an interface to make this available to shell scripts or programs in other languages.
First, a brief overview of the N810 is in order. The N810 is an embedded handheld system with an 800x480 display. It has Bluetooth, wireless, and USB connections. The underlying kernel is a 2.6.21 Linux® kernel, adapted for the hardware.
The N810 is fairly similar to the previous N800. New features include GPS and a built-in keyboard. The only way in which the N810 might seem less flexible than the N800 is that it provides only a single available MMC/SD card slot. The N800 provides two slots for user-provided MMC/SD cards, both full size. The N810 comes with a hard-wired 2GB card in the "internal" slot and a miniSD slot for removable media. (This can be quite frustrating if, like me, you've accumulated stacks of SD media over a few years of playing with embedded systems.)
The development environment for the N810 is essentially the same as that described for the N800 (see my other articles on the 770 and N800). There have been updates to Scratchbox and the maemo environment, but the essential process remains the same, and the Scratchbox and SDK install remain quick and easy. There are two major changes that are likely to affect a regular developer. The first is that xterm is installed out of the box; this is a big improvement. The second is that, when you install the openssh-server package, you are prompted to set a new root password. This is a big step up from the previous behavior: a default root password of "rootme". Obviously, you should pick some other password.
The alarm API
The alarm API was introduced in the maemo 3.0 release last year. It presents a set of calls to interact with the alarm daemon, which provides alarm services. You should prefer using this interface to trying to write your own, and you should definitely stay away from writing your own timer code in an environment like the N810. Power management on embedded hardware is an advanced topic, and it is easy to get it wrong; instead, just hand the job off to the specialized code provided.
Even if your alarm code is written elegantly and well, there is a compelling advantage to a centralized service. Imagine that you have written a perfect alarm interface, which has to wake the system only rarely, perhaps once every five minutes or so. This will have almost no impact on battery life. Now, imagine that other people, just as skilled as yourself, write similar interfaces. With several of them installed, the system must wake up several times every five minutes. Worse, users tend to pick different intervals. So, if you have one thing that wakes every three minutes, and one every five, and one every seven, you end up with the worst of all worlds: even though no individual alarm goes off more than once every three minutes, you actually have an alarm about once every two—and worse, pairs of alarms going off may involve separate wake and sleep cycles. So use the standard API.
The alarm API can do a number of things. In essence, it can configure the behavior of a scheduled notification with a great deal of flexibility. An alarm event may or may not involve a display to the user. The three primary things alarm tasks can do are display messages, run programs, or send messages over D-Bus to other applications. You might not think of all of these as alarms, but they share substantial functional overlap with the simple reminder messages that a calendar application could provide. In short, if you are implementing enough alarm functionality to support calendar applications and the like, it is better to generalize a little further and handle everything.
Alarms are stored as XML in /var/lib/alarmd/alarm_queue.xml. This file is moderately human-readable, but does make liberal use of magic numbers to encode flags. You can get a lot of insight into the components of alarm event structures by creating events using other applications, then reading the XML stored in this file.
Click to read more
Posts
No comments: