Re: Create Demo Application for Emaulator

You could show the *appearance* of the device with the application running
on it. That's about it. Not that doing that might not be valuable, but it's
a significant amount of work, installing the emulation environment on any
machine where you want to show it, etc.

The payoff, as far as my own opinion, of that is so low that I seldom
generate emulator images for our devices. We have one device that has a
two-line character LCD, no graphical display. I generated an emulator for
that early on, so I could see how a program that wanted to display strings
on the LCD would work, as I created the API for it. That required me to
write a simulator driver for that text display, however, which has no final
value in the actual device. The value of this simulation ability was
relatively low; you can see a floating window in the emulator graphical
image that indicates what would be on the text display at that point in time
and when you 'print' something to the display, you see where it would show
up, potentially allowing you to make sure that you don't send strings that
are too long, etc. Nothing there that a real device wouldn't give you and
*no* information about performance *at all*.

You can emulate the serial port I/O using the hosting PC's serial port in
the emulator, but you can't do anything much with USB, unless it's just
storage devices that you'd plug in there. To simulate anything on I2C,
you'd have to build a driver specially for simulating those devices on the
host PC, where you don't have them.

If you run your .NET CF program on the desktop to show the UI, it could
access serial ports and, potentially USB storage, but it's not going to do
anything with I2C and the method of accessing files will be different
because desktop PC's use drive letters, C:, D:, etc. while Windows CE does
not.

So, you can use the emulator, or just run your .NET CF program on the
desktop, to show the UI, but you can't simulate, effectively, the serial I/O
speed, the USB access speed, the I2C access, etc. in any pre-hardware
device; you must have your own built hardware, running a Windows CE image,
to see how the performance will be and to really do the I/O. For demo of
user interface, I'd just start working on my .NET CF program and run it on
the desktop to show what the screens will look like. The customer has to
understand that there's no way to accurately simulate a completely different
OS, in terms of performance, on a device (the desktop computer), that's
completely different than the actual target hardware.

Paul T.

"B" <B@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9239E993-6EF6-43E0-87D3-02C75CF570E6@xxxxxxxxxxxxxxxx
Paul,

From what you are saying I woudl get no benefit at all from using an
emulator for this Gui demo?

Just to give some more infor:- My expectation is that I will use .NET CF
because of the rich graphical components and the library capabilities. I
expect to use C#. I will be interfacing to Serial ports, USB and perhaps
some
I2C devices. There will be some configuration of the devices on startup.

The application will be displaying tables of received values and possibly
drawing some graphs of data. The display update rates will be in the
region
of 500ms to 1 sec.

Thanks, B


"Paul G. Tobey [eMVP]" wrote:

Paul,

Thanks for the feedback.

Our customer has a great sensitivity of the GUI. They want to see as
representive a set of displays as possible. So the customer is pusihing
for
this.

If I do create a demo on the desktop, I have a couple of concersn:

1. How do I ensure that the display will work well on a 640x480 LCD
display?

Make sure that your application window isn't any bigger than 640x480.
You
won't be able to demonstrate performance, if that's what you're asking,
on
anything other than the actual final device. Emulator is useless for
that,
too. Only the real hardware can tell you how fast the display will
udate,
etc.

2. I do not want to waste any of this desktop effort and through away
this
code, how can I reuse these screens created for the Desktop in the
targetted
embedded system?

Before you get too deeply attached to this demonstration code, you should
plan that you're going to throw away 50% or more of what you write
anyway.
Getting personally attached to your own code often causes you to waste
time
and effort, or live with a poor user interface, when just throwing away
the
garbage and rewriting it would fairly quick and easy.

Win32 is the API used on both. Whether your desktop effort will be
wasted
or not will depend on how you write it and what tools you use. Sure, if
you
use the .NET Framework and managed C++, that's all going to waste. If
you
use the .NET Compact Framework (act like you're targeting Windows CE, but
run the EXE on the desktop; it will work fine, as long as you don't use
anything that's only available on Windows CE, like dialing a phone or
sending an SMS message), then the code is just the code and targeting it
to
your real hardware is no more difficult than changing a setting in the
project after you have your device and have used Platform Builder to
generate an SDK for it.

If you are planning to use standard Win32, no MFC, no ATL, no .NET, then
there will be a few things that will be different. Menus are not
attached
to windows in the same way on Windows CE as they are on the desktop,
where's
it's pretty much automatic. You use a CommandBar and several API
functions
associated with that to connect the menu with the main window. Of
course,
you also have some limitations on what calls are available and you need
to
be aware that Windows CE is ONLY Unicode, so you'd want to build your
sample
code on the desktop for Unicode (or you're going to have to change every
string declaration in your program when you try to compile it for Windows
CE).

If you plan to use MFC, reconsider. .NET Compact Framework is
more-logical,
easily to program with, and more-complete. Yes, you have to use Visual
Basic or C#, no C/C++, but that's a pretty minor problem if you're a good
C++ programmer.

Without knowing what the program is supposed to do, that's as far as I
can
go...

Paul T.





.

Relevant Pages

  • Re: cross-platform serial api for gforth
    ... serial port on Unix and Windows? ... The project we are working on is an interactive display for a device ... way for me to use Gforth on a Winblows machine? ...
    (comp.lang.forth)
  • Re: Create Demo Application for Emaulator
    ... emulator for this Gui demo? ... How do I ensure that the display will work well on a 640x480 LCD ... Emulator is useless for that, ... use the .NET Compact Framework (act like you're targeting Windows CE, ...
    (microsoft.public.windowsce.app.development)
  • Re: cross-platform serial api for gforth
    ... implement serial port I/O and the top level code be the same. ... If you start from what Windows and Unices offer at the raw API ... the serial port stream is just that, ... emulation for display of the data that is updated in real time. ...
    (comp.lang.forth)
  • Re: Serial port problem using pocket pc emulator
    ... > pocket pc 2002 emulator. ... Port 1" and "Serial Port 2", which can be mapped to physical ports on the ... windows and its fine just in emulator ...
    (microsoft.public.pocketpc.developer)
  • Re: Emulator and GPS Receiver
    ... here's how to configure the emulator to use a Windows ... Serial port configuration is at the bottom of the dialog. ... >> How do i get my emulator to communicate with a GPS receiver that i have ...
    (microsoft.public.pocketpc.developer)