| Using Windows CE in a battle-hardened handheld |
a case study by Microsoft (Jun. 6, 2003)
 Tripod Data Systems (TDS), a subsidiary of well-known GPS instrument maker Trimble Navigation, recently introduced Recon, a "battle-hardened" handheld that meets MIL specs for moisture, dust, extreme temperatures, and drop resistance. The new TDS rugged handheld is based on an Intel XScale processor running Microsoft's Windows CE .NET embedded operating system.
Below is an interview with TDS embedded systems architect Christopher Peskin, in which we learn why TDS chose Windows CE as the Recon's embedded OS, how CE .NET's componentization and other features aided the development process, footprint reduction tips, third-party software technologies used, and what tool chain was used.
Read more about the Recon itself in this WindowsForDevices.com device profile.
Q 1. What were the decision points that lead to you using Windows CE in your device?
Traditional data collection devices were using DOS or proprietary (HP48 calculators) and did not provide a rich user experience, nor were they easy for developers to write applications for.
Developers experienced with Windows desktop programming can easily start working with Windows CE. The componentized, yet full-featured OS offers TDS flexibility depending on device architecture and form factor.
Q 2. Explain why componentization was important to this project?
Removing unneeded functionality for the particular market of the device allows for enabling the device to be less complicated than desktop PCs and faster time to market because we were able to avoid localization, testing, and supporting of features we didn't need.
Q 3. What footprint reduction tips do you have for other Windows CE developers?
Recon uses the "ROM-only file system" mounted as root with a special NAND flash file system that together provides a level of fine footprint control and feature modularity greater than "RAM & ROM file system"-based architectures. Due to the recent advent of this feature in Windows CE .NET, developers may not be aware of the various implementation considerations including performance and footprint tradeoffs.
The RECON product is a rugged handheld data collector requiring user data to be protected/persisted in flash at all times, unlike traditional CE handhelds with a RAM-based object-store. The RAM-based file system common to PocketPC and pre CE .NET architectures exposed the user to being able to store files in RAM (under the root folder, Windows directory, etc.), where a power loss could wipe the contents of RAM. Elimination of this RAM-based file system though the use of the ROM-only file system mounted as root (a feature introduced with Windows CE .NET) hides (with the exception of databases) the volatile data storage for the user. However, the benefits of the ROM-only file system mounted as root are two-fold. Not only does it provide a better user-experience for our data collectors, it also offers some interesting architectural options that allow for a new flexibility in the Windows CE .NET OS footprint.
Due to the nature of the ROM-only file system mounted as root, operating system files (such as DLLs and EXEs) can be individually moved by the system implementer between the NK.bin ROM image and files on the root-mounted file system. This flexibility offers a wide range of RAM and FLASH footprint configurations, with various tradeoffs between the two.
Once a developer has a RAM-based configuration working, the ROM-only file system can be enabled with the platform builder component in the component catalog. The key with using this feature is that, in addition to modifying the registry keys (ex: MountFlags) as described in Platform Builder Help, the \Windows directory and corresponding files must be created on the file system to be mounted as root.
Essentially the resulting CE.BIB file of a build must be parsed to re-create the actual \Windows directory contents on the to-be root file system. Operating system files (such as DLLs and EXEs) can be individually moved from the MODULES section on NK.bin (i.e., from CE.BIB) and placed in the root-mounted file-system. This means the CE.bib file can be edited before the rom-image build-step to reduce the number of files resulting in NK.bin, essentially moving the files to non-volatile storage. One catch: not all files can be removed from the NK.bin. Certain components such as NK.exe (and boot.hv if you are using a hive-based registry) must exist in order to boot and mount the root file system.
If the to-be root mounted media is removable and runs FAT, it may be possible to install the resulting root file system with a desktop PC during development. Platforms using soldered flash chips and non-PC compatible file systems can make this process more difficult and schemes may need to be devised by the system implementer to install the necessary files. Recon is in the latter category. One trick we used during early development was to create a bootable CE image that used the standard RAM & ROM file system architecture, mounting the to-be root-mounted file system as a folder, and then copying the necessary files to the device file system via ActiveSync(tm). After this is complete, the new ROM-only file system based image can be booted.
Also note the concatenated .DAT file, initobj.dat, should also be translated into corresponding files and shortcuts on the to-be root mounted file system. With a normal RAM-based file system device interprets this file at boot time by filesys.exe, but mounting as root requires this to all be setup though some other means, either before boot or very early on.
The footprint tradeoffs come in when deciding which files to move to the root-mounted file system and which ones to leave in NK.bin (files in the MODULES section of NK.bin will be searched if no corresponding version is found in the root file system). In many platforms NK.bin is entirely copied to, and executes in-place from, RAM, as in the case of Recon. Therefore, a copy of nk.bin must also exist in non-volatile storage such that it is available to the boot loader at power on. In this case, modules in NK.bin actually consume both Flash and RAM storage, although the version in Flash may be smaller due to compression. Removing files from NK.bin reduces the RAM footprint, and also reduces the extra copy within the non-volatile copy of NK.bin. In trade, storage on the root-mounted file system is used to hold the module.
Another aspect to be considered is when the module exists in NK.bin, the .DLL or executable consumes RAM at all times, regardless of whether it is needed by the user or not. An advantage of shifting the module to the root-mounted file system is that the module is demand-paged to RAM as needed, however this paging can cause delays on execution due to the usually slower file-system access time to load the module.
One algorithm for selecting modules to off-load to the root-mounted file system might be based on the significance of the size of particular features vs. frequency of use. For example, WordPad, File Viewers, and Windows Media Player are desirable, but not used that often in a rugged data collector -- removing them from NK.bin can result in significant reduction in RAM consumption for most users. This type of decision must be made with the particular platform and end-user scenarios in mind.
Q 4. Beyond the core operating system features, what in-house or 3rd party technologies did you need to add to your device, and was integration of additional applications/drivers easy?
Recon uses a third party product to manage its non-volatile storage. This driver is a robust, high-performance, journaling file system for NAND flash access. It allows Recon to withstand a processor reset or loss of power without loss of data integrity. By having each file header carry all of its own size and attribute information, any modification of a single file does not affect tables, directories, or other information stored on the NAND flash media. This dramatically improves performance as well as data integrity. With this technology, Recon is able to achieve file system performance that approaches the raw NAND read and write data rates. This driver was easily ported to Windows CE.
To support the architecture described above for the Recon product, TDS has internally developed several tools surrounding the building and deployment of OS images that contain both NK.bin ROM images and a set of files need to be installed in the root-mounted file system. This tool-chain includes a mechanism for processing the CE.bib and initobj.dat files at build-time, and then packing the resulting NK.bin and root-file system directory in a format that our boot loader understands and can install on Recon's NAND flash file system.
Q 5. Describe the tool chain used to develop your device (Platform Builder, eMbedded Visual C++, Visual Studio .NET). Did you have the same engineers working on all parts of the project, or were you also able to develop parts of the project in parallel.
See item 4. above regarding tool chain. TDS develops both the OS and many applications for handhelds. We use all of the above mentioned products. The division of labor lies between OS development and application development. Applications are developed in parallel, using alternate Windows CE platforms, device emulators or pre-production OS releases when available.
Copyright © 2003 Microsoft Corporation. All rights reserved. Reproduced by WindowsForDevices.com under license.
Related stories:
(Click here for further information)
|
|
|
|
|
|
|
news feed