Porting Windows demo apps to WinCE/XP Embedded

Question

We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.

We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.

Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.

Our existing demos are built either in C++ under Borland Builder, or in Delphi.

Thanks in advance.

EDIT: see my answer below with info from a board vendor.

Answer 1

There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).

In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.

Answer 2

Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.

Answer 3

As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.

The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.

To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.

WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:

1. Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
2. Create an API for talking to the driver.
3. Use .net to create our GUI applications, and use PInvoke to actually talk to the API.

The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.