Freigeben über

Q: Which API should I use?

  • Artikel

I’m going to be presenting a couple of sessions at ESC East, Boston October 26th-30th (both of my sessions are on Tuesday, 28th October).

One of the sessions covers the topic of “Which API should I use” for an embedded device, for the session I will be building a digital picture frame based on CE 6.0 R2 – there are a number of requirements for the frame which I will list in a second – and then follow up with some additional posts that cover off each of the requirements.

You have a number of choices when writing your code – this includes Win32 (C/C++), MFC (also C/C++), or managed code (C#/VB). There are perhaps two things to think about when choosing your API set, one is device performance, the other is developer performance.

Device performance may include the “real-time” performance of the system, or at least having your code (and operating system) run within the hardware/software bounds that are required to fulfill the device scenarios defined by you or your customer.

Related to performance is reliability – you may be really good at writing small, fast code, but if the code is buggy, or leaks handles/memory then you have the potential to have an unstable system.

For the talk at ESC East I will focus on the two API options exposed on Windows CE, these are :Win32, and .NET Compact Framework (in my case using C# as the development language – I’m a “curly brace guy”).

In a nutshell Win32 gives you low-level access to your embedded device, perhaps you can think of Win32 as being the assembly language of Windows. Giving you a lot of flexibility, but also requiring you, the developer, to do most of the heavy lifting, including cleaning up after yourself (memory/handle/object allocation/free). In some cases you may need additional frameworks to add support for useful classes/libraries (strings for example), examples are MFC, ATL, WTL, STL. Win32 is required for some o/s pieces, including Drivers and Services, and typically used for all “real-time” work. Interestingly, Maarten Struys wrote an article called “Real-Time Behavior of the .NET Compact Framework” so it may be possible to build a hybrid device that requires real-time behavior and uses both Win32 and .NET Compact Framework.

Managed development (.NET Compact Framework) – The .NET Compact Framework exposes a set of application development libraries that provide the developer with a toolbox of classes/APIs that provide for rapid application development – using a language like C# also gives the combined benefits of C++ and Java programming combined into one language. Unlike C/C++/Win32 you can be a lazy programmer (I’m not saying that you should be), letting the framework clean up behind you – if an object you’ve created goes out of scope then the Garbage Collector will come along behind you and clean up. There is of course a hit for taking the Compact Framework into your image, for .NET CF 2.0 this is about 4MB. Perhaps this is ok given the upside in application development speed and the reduction in leaks.

ok, now over to the DPF requirements.

  1. Must be internet connected (wired or wireless) – I won’t spend any time talking about how to get the device connected, perhaps that’s another post – having a frame that just loads images from a USB stick, or from a Windows Media Connect source is so… last century.
  2. Must consume an image RSS feed – I’m using FrameIt (super cool!) – here’s my demo feed https://demofeed.frameit.com [1]
  3. Supports JPG Image format only (but only because the images coming from the RSS feed are JPG) [2]

For my session that means that I will focus on three things.

  1. Code to pull the RSS file down from FrameIt (so I can parse out the enclosures)
  2. Code to parse the RSS feed, and then pull down the images (could probably re-use the code from step 1).
  3. Code to display the images (nothing fancy, no cool transitions, but enough to show the images being displayed)

I will probably get the Compact Framework code done first, since that should be quick and easy!

Look out for some more posts on this subject coming soon…

- Mike

[1] – FrameIt – I really like the FrameIt concept, the fact that the DPF doesn’t need to know anything other than how to parse an RSS feed and pull down images from an enclosure rocks – this means that the FrameIt back-end owns building the images for the frame, and can aggregate content from a number of different sources – the frame only needs to subscribe to the one RSS feed.

[2] If you are using Win32 and want to load image formats other than BMP then you need to resort to the Windows CE Imaging APIs, these are COM based, and even though Don Box thinks COM is Love I’m not sure that I completely agree. There’s a Win32 sample for loading images here in the Wince600 install tree %_PUBLICROOT%\GDIEX\SDK\SAMPLES\SIMPLE

Comments

  • Anonymous
    October 08, 2008
    PingBack from http://www.easycoded.com/q-which-api-should-i-use/

  • Anonymous
    October 09, 2008
    A couple of days ago I published an article which talked about a session I’m presenting at ESC East on

  • Anonymous
    October 21, 2008
    Is there any way to get a copy of the Win32 sample for loading images (GDIEX)? I dont have access to the Platform builder, and need some help encoding images.