次の方法で共有

Embedded Development: Forget the O/S!

  • [アーティクル]

I'm presenting a session at Embedded world 2007 - the title of my session is "Embedded Development: Forget the O/S" - this would appear to be a strange comment coming from an operating systems company. My presentation starts by examining the shopping list for a typical embedded device - you need hardware, "plumbing" (typically provided by the operating system), and applications that "glue" the device experience together (much like duct tape and "the force").

Hardware can come in one of two forms, off the shelf or custom built - each has advantages and disadvantages depending on the type of device you are building.

Devices based around off the shelf hardware are quick to build (since you already have the hardware), the device functionality can perhaps be extended through the use of external peripherals (perhaps USB based). Embedded devices that use off the shelf hardware are typically based on the x86 processor and could therefore run a desktop operating system (Windows XP/Vista, other), embedded operating system that targets x86 processors (Windows XP Embedded, Windows Embedded for Point of Service, other) - and yes, there are a number of other "off the shelf" boards available like the Gumstix which is an ARM based device. PC/104 designs are a good example of commercially available, off the shelf hardware that can be used to bring an embedded device to market quickly without the need to design and build custom hardware. The downside is that the cost per device is higher than a large run of custom built boards, the devices typically run x86 based processors and are therefore not suitable for handheld/mobile applications.

Custom built hardware has the advantage of being tailored to the specific device category you are building, whether that be an in-car navigation device, portable media device, set-top-box, medical monitoring device or whatever - the device ships with only the hardware components needed for your device, and with a processor that's suitable for the intended task (the majority of mobile devices are based around the ARM processor core). The down side for custom built hardware is the cost and time needed to develop and bring the hardware to market.

So what about the underlying plumbing ? - Much like your bathroom at home the plumbing should be invisible, you know for sure that the plumbing exists, but at the user experience level you typically don't need to know or care about the plumbing (unless something goes wrong, but that's what plungers and debuggers are for!). Operating systems provide a number of services to developers, this includes memory management, thread management, process management, and a host of underlying application services, this could be a media player, codecs, web server, web browser, FTP server, remote desktop functionality, TCP/IP stack, real-time communication services, image decode libraries etc... - the interesting thing about plumbing from an embedded device perspective is that the plumbing is something that you shouldn't be writing for yourself, right? - Writing a TCP/IP stack from the ground up or writing a JPEG decode library doesn't make sense when an operating system can provide this functionality for you.

Let's put this another way - Take a look at application development for embedded systems over the last 30 years, in many cases the embedded device wouldn't have an operating system, the device would boot directly into an application - developers would write all of their application code in assembler (remember printing assembler listings on 132 column green/white striped paper? - with only 10 or so characters per line ?), having to manage the stack within your application by hand, figuring out how many times you had pushed/popped items from the stack, which registers you had stored items in - so much hard work (but I really enjoyed programming in assembler!). Thankfully higher level languages came along like C or C++ - the source code still gets compiled into assembler (so the end result is still the same, but some might argue that the code isn't as elegant or 'tight' as hand coded assembler) but developers were now able to be far more productive, focusing more on the application logic than the interface to the underlying processor. If we then kick it up another notch to more recent application development languages like C#, Visual Basic, or Java then the application developer is even further abstracted from the processor, and from the underlying operating system but the speed of application development is amazing. From an application developers perspective where does it make most sense to spend your time, grubbing around in assembler twiddling registers on the processor, or writing just two lines of code to call into an XML Web Service to book a hotel and a rental car for your up-coming vacation ?

So far we've only looked at this from the embedded developer perspective, what about the end user? - certainly the end user demands more from their devices these days - look at the progression of capabilities of GPS navigation devices - the first electronic devices had a B/W LCD screen that provided LAT/LONG and compass, these devices really didn't provide much more than a standard compass - the next generation of devices still provided LAT/LONG, and direction but plotted your location on a topographical map - so you could now (roughly) see where you were - now skip to the latest GPS navigation devices, devices that have a rich (did I really say that!) color screen, 3D mapping, turn-by-turn voice navigation in multiple spoken languages (you can even download Scooby Doo and other character voices for some devices!), these devices can interface with your cell phone to provide hands-free voice features - we're now starting to see some of these devices with data connectivity to dynamically route you around trouble spots, or to use data connectivity to determine the cheapest gas/fuel costs based on your current location, even media player capabilities. That's just one example, what about the humble VCR - let's jump into the "Way back when machine" many people used the VCR to record TV shows by pushing the "Rec" button on the front panel, many users couldn't even figure out how to set the clock on the device let alone schedule a TV show to be recorded on a specific date/time - now jump forward to the latest DVR boxes - some of these devices have multiple tuners so you can record two shows at once, or record one show and watch another - the EPG (Electronic Programming Guide) is displayed on your TV screen and is searchable - some of these devices provide movies on demand, others can browse the Internet and give access to web based e-mail.

The thing that sets the latest generation of devices apart is the user experience, the way that applications are integrated, the flow of the user menu system, the ease of use, the discoverability (is that a real word?) of features - the fact that the device "Just Works" in the way that the user would expect - all of this takes time and effort and is sadly an area that developers tend to overlook. The user experience is where you should be focusing your time, not on the underlying operating system plumbing.

 - Mike

Comments

  • Anonymous
    February 01, 2007
    I must be missing your point.  It seems that you are saying don't forget the OS, but always use one, instead of doing it yourself? That's a perfectly fine point, but it doesn't seem to match the title?

  • Anonymous
    February 01, 2007
    Hi Jon, Given the complexity of many of todays embedded devices you definately need an embedded operating system to schedule threads, manage memory, and provide the underlying operating system services, this may include networking, media engines, codecs, web serves/browsers etc... All of these items may be needed for your specific type of embedded device but should "just be there", easy to include/exclude from an embedded operating system image - the operating system development tools should make this simple, but that shouldn't be the focus for your device developers time, who should just rely on the fact that the services they need are there and work. This leaves developers free to focus on the user experience.

  • Mike

  • Anonymous
    February 01, 2007
    The comment has been removed

  • Anonymous
    February 01, 2007
    Ok, I see. But, someone has to do the work, and depending on how custom your hardware is, I would expect more work needs to be done. I started a CE 5.0 build this week, and because we are using almost exclusively off-the-shelf hardware, with a BSP from the vendor, we are going much faster than we have with our 3.0 and 4.2 builds, where our hardware was based on a BSP, but we wrote some drivers from scratch, and optimizing vendor and Microsoft provided drivers and fixing bugs in the OS, etc. so it took a long time.  This product is an x86 platform, and is much faster, so we don't have to care about speed as much as we previously have. But, the problem with having all this stuff happen "magically" / provided by the OS, is that when things go wrong, we don't have any idea where to look for things.  But, so far, things are going well, so we will see what I think six months or so.

  • Anonymous
    February 01, 2007
    Jon, I'd be very interested to hear about the progression of your project and any issues you encounter on the way. The interesting thing about Windows CE is that if things aren't working as expected you can debug the kernel, drivers/BSP and other portions of the operating system. Windows XP Embedded doesn't ship with source (but does ship with very wide hardware support).

  • Mike
  • Anonymous
    February 16, 2007
    Hi! <a href= 972c16f442eba60469680bf869dd6a89 ></a>   [url=972c16f442eba60469680bf869dd6a89 ][/url]