In search of a common API for connected devices -

In search of a common API for connected devices

The rapid evolution occurring in the connected computing environment tells me that it's more important than ever to develop some common standards, platforms, and APIs. But this could be easier said than done. The sheer diversity of connected-computing devices cries out for some commonalities to emerge if a viable support infrastructure is to develop.

The range of alternatives already available in the connected-device space is breathtaking. Relatively simple, single function devices are morphing into a wide range of multimodal devices, incorporating cameras, audio, video, camera and wireless phone features. And now these previously standalone devices have added wireless personal area networking in the form IrDA, Bluetooth, and 802.11a WLAN as well. In the near future, compute intensive multimedia is planned along with the ultrawideband wireless connections to support it.

For the consumer it means a multiplicity of choices. But it's a double-edged sword for the semiconductor companies providing the silicon and the companies building the devices and providing the services.

From what some of you tell me, the range of choices makes it harder to determine what consumers will go for. Where the buying public once preferred low cost, a black-and-white display, and clam-shell designs, two or three months later the mainstream of the market may have shifted to color, moderate cost, and WLAN connectivity. Once they do make a choice, the market can turn on a dime as they move to the next new thing.

Developers are finding themselves hard-pressed to shift as quickly. At this particular point, at which there is no common operating system, tool, hardware standard, or platform, this highly volatile market requires a new design almost every three months.

In terms of OSes, there are still a multiplicity of choices, but leading the pack are Microsoft's Windows permutations for the small devices; Linux, in its various flavors; and Symbian, which started in wireless and is now making headway in a number of other platform environments.

In the second tier are a range of real-time operating systems, including Wind River, Accelerated, OSE, QNX, and a number of geographical variants in Japan and the Far East. With regard to CPUs, the ARM and StrongARM derived architectures are in center position, but there are still half a dozen other contenders, from the various MIPS variants to newcomers who believe the X86 architecture still has a chance in this market.

At one point developers were facing such problems alone. Now, about half a dozen competing consortia are each committed to a specific architecture, OS, and set of tools. While this trend reduces risks to some degree, developers, and their companies, especially the smaller ones, are still in a tough position.

They must commit to one approach. But they have no fallback position. They cannot, if they guess wrong, shift easily to another platform and port the large majority of the work, code, and hardware to the new environment. One of the reasons for the popularity of Linux, no doubt, is that many developers see it as a way out of this Catch-22.

What is needed is a common applications programming interface that is industry wide, crossing boundaries of OS, application and most importantly, CPU architecture.

Why? Two reasons. First, in the near term we need it to make development of applications that function across multiple architectures work. We should do more than pay lip service to this concept. We need to make it a reality.

Second, in the long term it will make it easier to transition to the new CPU architectural paradigm that is waiting in the wings. Despite the current predominance of control and data-processing-oriented reduced instruction set computer (RISC) architectures, the connected computing environment is forcing a shift to alternatives more akin to data flow and data movement.

The desktop and the various small-footprint, wireless embedded CE devices may be the last to shift, but otherwise you can see the shift all around us. The various embedded network processor architectures that support and move data around the network core from the likes of Motorola, Intel, IDT, and Xcelerated are to varying degrees, based on data flow ideas, forcing a rethinking all the way down to the programming level.

Until recently, the design alternatives for the NPU elements have all been based on derivatives of sequential RISC architecture, says Gary Lidington, marketing VP at Xelerated, Inc. in Burlington, Mass. Discussions have been limited to trade offs between processor interconnect topologies (parallel, pipelined and matrix) and the degree of hardwired support for specialized functions — either via specialized instructions or specialized coprocessors). Lidington says that data flow architectures, unlike RISC architectures, are very efficient at moving data and the amount of parallelism that can be extracted from the application is limited only by the data dependencies. “Given these attributes, the challenges that remain are to scale the processing capability in a manner that allows easy programming while introducing the notion of fully deterministic execution to meet hard real time (wire speed) requirements.”

Looking at the problem from a purely software developer's point of view, even Microsoft's Bill Gates is talking about the need for a more data-flow-oriented approach. His grand vision is for seamlessly connected computing from desktop to server to consumer device.

But some developers of desktop, handheld and embedded CE devices have told me that while this might be appropriate at the NPU level, it will be a long time before a shift will be necessary at the point where the computer user's finger hits the Enter or Start button.

And history would seem to be on their side. The Intel 8080 and its competitor, the Zilog Z80, which began as embedded complex instruction set controllers (CISC), served as CPUs in the first generation of personal computers between 1975 and 1980. Even with the introduction of the 8086, '186, '286, and '386 in the mid to late '80s, the legacy of the architecture as a controller did not fall away until Intel shifted to a RISC design with the Pentium (nee '486) in the mid '90s. That's a good ten or fifteen years during which the industry had to time think about the architectural shift that needed to be made.

But Robert Payne, Sr. VP/GM of Advanced System Technology at Philips, says he doesn't think that we can depend on history repeating itself. He says that the network connected nature of the new consumer appliance devices, together with the heavy multimedia processing load being placed on them, will force a shift to architectures that place more focus on data streaming and data movement.

While there are a number of alternatives that might present a viable starting point for an architecture independent API to help us make the transition — Nokia's Series 60, Microsoft's CE.NET, and the Java framework, among others — most are still wedded to traditional computing architectures.

A recent effort that may result in the necessary transitional API is the Universal Home Application Programming Interface (UH-API) initiative proposed by Philips and Samsung. Initially, this home networking oriented API seems to be focused on the OSes and CPUs currently in use. Indeed, it is initially being promoted as a stable, hardware-independent API to act as a bridge between the middleware and application software from ISVs and the architectures from the chip manufacturers.

But the fact that it is being proposed by Philips — one company that seems to have recognized that a new computing paradigm shift may be upon us more quickly than we expect — leads me to believe it would be a good starting point.

But if the UH-API is not what I hope it will be, then we will have to invent an appropriate mechanism. Otherwise, we face yet another round of chaos in the market until some sort of common architecture independent transitional framework emerges.

Bernard Cole is site leader and contributing editor of iApplianceweb and an independent editorial services consultant working with high technology companies. He welcomes your feedback. Call him at 602-288-7257 or send an email to .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.