Ming's Embedded Blog

DevHealth and DevHealthViewer

2009-03-05T01:16:00Z

As many of you know, MemoRX should not be used for Windows Mobile 6.1 development, instead we recommend developers to use DevHealth & DevHealthViewer. The DevHealthViewer tool replaces MemoRX and displays much more information than what MemRX did. Typically you will run DevHealth to capture a snapshot of your virtual memory usage (the log file is called mem_X.txt), run the tests, and then run DevHealth again to capture the virtual memory snapshot after the test. By using DevHealthViewer, you can visually compare the two memory snapshots and see which process is leaking memory during your test. Though DevHealth & DevHealthViewer do not tell you which function or module leaks the memory, it will point the process you should focus on. From here, you can use other tools such as Application Verifier to shim the module and gather the callstack for memory leaks!

Automating DevHealth runs

2009-01-13T00:16:00Z

Hope everyone had a good New Year. I was doing some Hopper runs on a partner device and gathering DevHealth logs to see memory usage over time. It was rather painful to manually collect the DevHealth logs since Hopper was interrupting me (did not have KITL so could not launch DevHealth from the Target Control Window) and I also wanted to run DevHealth at specific intervals, say every 60 minutes.

I decided to write a quick application to help me do this and now am sharing my experiences with you. The application I created as a no-frills command-line app. The pseudo-code for the application follows:

FOR i = 1 TO X

Create DevHeath Process

Wait until DevHealth Process has finished

IF I == X -1 THEN

Exit loop

Sleep for Y seconds

END FOR

Where X is the number of times you want to launch DevHealth to collect samples (for me this value was set to 25) and Y is the time between collecting the DevHealth logs (I set this at 3600 seconds). Some implementation notes is that you can use CreateProcess to create the DevHealth process and do a WaitForSingleObject on the process handle (returned via struct from CreateProcess) to wait until the process is finished.

Some improvements:

- Ensure only 1 instance of this application is running (i.e. make sure if Hopper tries to start another processing using this executable, don’t allow it). I’d probably use the Toolhelp API to enumerate the active processes and perform the check based on process name.

- Enable basic data logging. Creation of a small log file to mark the when DevHealth started collecting data, and when it stopped collecting data.

Hope this will give you guys some ideas and save you time on collecting those DevHealth logs.

Windows Embedded MCTS & Books

2008-12-23T20:10:00Z

Recently Microsoft has created an MCTS (Microsoft Certified Technology Specialist) program for Windows Embedded CE 6.0. Along with the certification test, Microsoft and its Gold Partner, Adeneo, have created the Windows Embedded CE 6.0 Preparation Kit. Incidently my former project manager, mentor, and good friend Nicolas Besson (Windows CE MVP) was a co-author of this book! It is recommended that you have about one year of experience in Windows CE before looking into this certification.

In addition to the creation of the certification program and the prep kit, there have been some great books that have been published lately about Windows CE! Douglas Boling has released the 4^th edition of Programming with Windows Embedded CE 6.0 Developer Reference. There are also been two other books that have been published in the second half of 2008.

Windows Embedded CE 6.0 Fundamentals from Microsoft Press is a great primer for learning about CE. I read a few chapters of this book and it was a fairly easy read J. You can order a printed copy of this book or download it for free (link to the soft copy of the book can be found in the link below). The focus of this book is more on the lower levels such as the Board Support Package and Build System. Lastly, there is another book that was published in November 2008. This book is published by Wrox and called Professional Microsoft Windows Embedded CE 6.0. A pre-draft version of the book can be found at the link below.

In order to access the resources I have discussed above, please go to http://msdn.microsoft.com/en-us/embedded/cc294468.aspx.

Embedded Application Architecture

2008-10-14T08:07:00Z

Lately I've been reviewing some of the projects I have done in the past and wondered how we could have improved application compatibility/portability between different operating system versions and across different devices (CE devices often have custom SDKs). So I came up with the following architecture:

Figure 1 – Application Architecture

Let’s go over this architecture one layer at a time. I called the lowest level the OS/BSP Abstraction layer, this layer interfaces with the operating system (kernel and drivers); this level is used to isolate the rest of the application from any OS API changes and any device driver design changes. Device driver changes can involve a change in struct layout or change of IOCTL codes. So in its simplest form, this layer is comprised of wrapper functions that simply route a call from the application to a corresponding kernel API or driver call (think of it as a proxy pattern). In addition to simple routing, this layer can also perform some checks to make sure that the input/output parameters are valid and handle exceptions as needed. There is a performance impact by having this layer route function calls to the OS, however, the hit in performance is negligible and are outweighed by the benefits of having this layer. The advantage of having this layer is whenever there is a change in the BSP or OS, the change will only impact the OS/BSP Abstraction Layer.

The next level is the Document layer, this layer is essentially all the business logic of the application. It has hooks into the OS/BSP Abstraction layer and calls the wrapper functions to gain access to the OS and drivers. In addition, it also sends events to the View layer and handles the View’s request for data or change in state. The last layer is the View and its responsibility is to display the results from the Document layer and to handle user inputs (key presses or touchscreen taps).

Many of you may recognize the similarities between MVC (Model-View-Controller from the Smalltalk days) and the Document-View architecture. Essentially the Model component of MVC is replaced by the Document Layer and the View and Controller components are condensed into just the View Layer. Both architectures allow for the developer to swap out the user interface without making any changes to the business logic, MVC allows for some more flexibility in that you can swap out the input devices, however, it makes the architecture more complex and since the input modes for Windows Mobile/CE is standardized, I think that the View Layer can take over the responsibilities of both displaying results and taking in user input.

So by having layers we can avoid major changes to the application when the following occurs:

- Update of SDK (BSP has been modified, driver IOCTL codes or structs have been altered)

- Request for UI redesign

- Update of OS Version

- Migrating application onto a new device

Hope this helps!

Introductions

2008-10-09T19:42:00Z

Welcome to Ming Wang’s Embedded blog. I would like to introduce myself. I graduated from the University of Washington with both my BSEE and MSEE in Electrical Engineering. Also, I am a MCTS (Microsoft Technology Specialist) in Windows Embedded CE 6 and a MCT (Microsoft Certified Trainer) in Embedded CE. My specialization is in Board Support Package (BSP) development as well as some applicative development on Windows CE. I have recently joined the OEM Mobility Consultant Team and am eager to assist OEMs on their projects. I believe this is a very exciting time in the embedded ecosystem and there is a bright future for both Windows Mobile and CE J.

Disclaimer Post

2008-10-08T19:58:00Z

Welcome to my blog! As this is my first blog, be gentle ;-).This post is just a disclaimer post so that all the legal stuff is out of the way.

Disclaimer:

Postings here are provided "AS IS" with no warranties, and confers no rights.
The content of this site consists personal opinions and do not officially represent my employer's view in anyway.
The thoughts and opinions of the author often change.You should not consider out of date posts to reflect the author's current thoughts and opinions.