An interview with Ericsson's "blip" project R&D manager

Rick Lehrbaum of LinuxDevices gets the skinny on some cool new penguin tech.
Written by Rick Lehrbaum, Contributor on
Ericsson Business Innovation has announced the BLIP, a small self-contained Linux-based device that communicates wirelessly with mobile phones, PDAs, and other kinds of mobile devices that are equipped with Bluetooth short-range wireless technology. It's meant for use in shopping centers, airports, railway and bus stations, and other public places.
The BLIP is actually a tiny computer system, based on a 32-bit ARM7TDMI system-on-chip processor. It runs uClinux, an embedded form of the Linux operating system developed by embedded Linux specialist Lineo.

To find out more about the BLIP's internal architecture and functionality, and how practical it will be for developers to customize and modify the operation of the BLIP, LinuxDevices.com's Rick Lehrbaum spoke with Kjell Svensson, the BLIP project's R&D manager.
Here's what he learned . . .

RL: Why did Ericsson decide to use Linux as the BLIP's embedded operating system? What other alternatives did you consider?
Kjell: Actually, we started off the project designing for eCos. But when the requirement list of the functionality increased (for example, support for filesystems, well tested Ethernet/IP, nfs, ftp . . .) we decided to switch over to Linux. Our investigation on the availability of a suitable Linux package for our ARM7TDMI-based platform showed that uClinux supported most of the functionality we required, so since there was already production-quality support for the ARM7TDMI, we could concentrate on [porting to our specific platform].
RL: What is the functional architecture of the BLIP? That is, what does the software actually do, in order that the BLIP can serve as a Bluetooth gateway?
Kjell: The BLIP is designed to be a multi-functional platform, where application developers through application-specific code and/or platform reconfiguration could alter the default application-level behavior of the BLIP into something quite different. We intend to release an SDK for BLIP application developers through the "Ericsson Developerzone" program, where we in various ways will encourage third-party development of applications.
However, for the generic use of the BLIP devices, we have developed the "BLIP Local Infotainment Point" application. This software contains the Generic Ericsson Bluetooth Host Stack which implements the Bluetooth-specific communication layers, together with application specific code that implements support for the Bluetooth LAN Access profile. When a client connects to the BLIP over Bluetooth, this application spawns off a connection to the generic Linux IP stack via PPP. Through this architecture, the user can then use the BLIP device to either connect to the internal http/WAP server, or to connect to a LAN that the BLIP could optionally be connected to through its Ethernet interface. For the internal web server, we're using either the open-source boa http server or Ericsson's generic embedded WAP server.
RL: On the hardware side, is the BLIP's Bluetooth functionality based on the usual Ericsson Bluetooth module, or is it built from discrete chips that are integrated onto the same board as the BLIP's CPU and other computing components?
Kjell: The design uses the usual Ericsson Bluetooth module, complemented by the host ARM7TDMI CPU running the uClinux OS. The Bluetooth module connects to the host CPU through both the UART and PCM ports, enabling the possibility to run a mix of data and voice channels simultaneously.
RL: Will developers be able to upgrade and/or modify the BLIP's internal operating system in addition to its application software?
Kjell: The uClinux OS platform may very well be modified. As mentioned earlier, we have created a "default distribution" of the BLIP uClinux which we believe will be useful for most application purposes without any changes. However, as the complete sources for the BLIP's uClinux will be available through the Developerszone, anyone wanting or requiring to make changes to it may do so. Using built-in features of the bootloader, a modified system can then easily be downloaded into the BLIP through its serial port.
RL: Is the bootloader home-grown, or did you base it on an available open source bootloaders?
Kjell: Our bootloader is a proprietary home-grown firmware. In addition to setting up and performing some basic diagnostics of the hardware at boot time, it also provides functionality to transparently download updated software into the non-volatile memory of the device, thereby enabling easy upgrading or modification of the BLIP's Linux system. No special PC-host tool is required for this process, since the bootloader uses the serial remote GDB protocol for its operation (i.e a new linux+romdisk image can easily be serially downloaded into the device using gdb as its host tool).
RL: Have you generated any new or modified open source software during the project that will be available to the open source community?
Kjell: Yes. For example, all code generated to support the BLIP board (including its BSP) will be openly available through the Developerszone program. Beyond this, since the stock uClinux userland collection contains so much useful stuff, we have not yet really needed to implement any more generically useful software that would be worth releasing as open source.
RL: Can you share any future plans for the BLIP family?
Kjell: The present BLIP Model C11 is the first product in an intended future family of BLIP devices. Coming variants might, for example, feature different memory or interface configurations.
RL: Will the BLIP's wireless communication range soon be increased beyond the current 10m limit?
Kjell: The main intention for the BLIP products is to be able to provide location-dependent information. As such, we are taking advantage of, rather than suffering from, the 10m range of the current Bluetooth modules. That is, the limited range helps give closer positioning -- that is, if you're connected, you're within 10m (rather than 100m). So, for this application domain, we do not see any really good use for introducing a 100m version.
RL: Thank you very much!

Related stories: Talk back! Do you have questions or comments on this article? talkback here
Editorial standards