Re: Some broad questions

Hi Paul,

Thanks for your post you have been most helpfull.

Okay, I now understand what you are saying about the VGA. It mainly makes
sence, the core functionality of every panel is different and we need the
right interface circuitry in order to connect it to our board.

Yes, I will have to look into what I can do for the proximity issue... its
true that not too many boards offer digital I/Os.

In the mean time let me think about all of this, it seems to be a great
effort in choice of hardware and software.... I thankyou for your time Paul,
you have been very nice to me!

bye!

--
Best regards
Robert


"Paul G. Tobey [eMVP]" wrote:

You'd have to check with the "USB chipset" vendor and make sure that they
will provide a CE driver or that you have the expertise to write one
yourself.

Display is, as I said, the main problem. That's a *very* weird size. I was
going to suggest another of our devices, which has a 10.4" touchscreen, but
that's apparently too big for you. This device could do everything you've
told us about so far, with the addition of a camera and an external,
probably RS-232-based, proximity sensor.

VGA: You're going to connect this 'screen' to your board, right? You don't
think that every LCD panel that you buy from Sharp or NEC has the same
interface to the main board, do you? Hah! Not even close. That's the
first challenge: how do I connect my display to my board? VGA is an obvious
choice, but that means that you have to find an LCD, with a touchscreen, in
the size that you specify, which has a VGA interface. I've never heard of
one. Yes, the processor has a display controller which can speak VGA, as
your PC does, but you can't buy a LCD panel that speaks VGA. All of those
flat panel displays at Circuit City have *extra circuitry* in them to
implement that, so, if you have identified a LCD panel and you want to add a
VGA interface to it, so that it will plug into your standard, off-the-shelf
board, *you* have to implement VGA; another hardware design job. The driver
for the controller is not a problem. It's the physical hardware interface
between the board and the display that is the problem.

On the proximity thing, remember that you aren't designing your own CPU
board, right? It's not necessarily true that every board is going to
provide some "digital I/O" for you to connect to!

BSP: Yes. The board support package supports a specific board for Windows
CE, pretty much like what it says. It allows the given board to be used as
a Windows CE device.

SDK: Since you are going to be custom-designing the contents of the OS, you
are going to have to generate the SDK. You have to understand that there
isn't going to be a bare-bones, but with full-motion video support, OS
laying around for any reference design board! You want a very strange set
of components in your OS, which means you *are* going to have to configure
and build the OS yourself. Once you have a custom OS, you *must* use an SDK
that matches the set of features in the OS, which means that you also have
to build the SDK for the OS. When you build this, you choose whether it
targets eVC++ or VS, and once you do that, you've determined what tools will
be used to develop application software for your device. Driver software
will still be built with Platform Builder, probably.

Microsoft probably *could* recommend a vendor, but they won't (and remember:
you're *not* programming the 'board' with eVC or VS; you're programming the
OS, which is why the SDK has to be generated by the guys who build the OS).
Frankly, it seems to me that you don't have enough support in the hardware
design area to do this project. You might consider taking on an
organization that will consult with you on hardware selection, help you get
the OS built, and show you how to do the other things that you'll have to
do. There are folks who frequent this newsgroup who would be good choices
(not me).

Again, the *first* thing you have to do is figure out what display you're
going to use. Once you've identified a display, you'll know what hardware
interface it has (and I'll bet it ain't VGA). It might be a semi-standard
differential signaling interface, or it might be TTL signals for clock and
data. In either case, *then* you know one of the key parameters of the
board you want to connect with (the display interface). Just about any
board that you'd buy will have VGA, but a small subset will be able to
handle other interface types, so you just cut down your choices
significantly. Next, you have to figure out touchscreen. Since most of
your possible CPU boards *don't* have any touchscreen support, you just cut
down your choices again. Select from the ones still in the running based on
having enough I/O (USB, digital I/O, if you're determined to do something
non-standard, serial I/O, etc.)

Either get a BSP from that board vendor or base a new one that you'll
maintain yourself on the CEPC BSP that comes with Platform Builder.

Paul T.

"Robby" <Robby@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2116B799-9F75-45AC-94BB-447CA8BA0C11@xxxxxxxxxxxxxxxx
Hi Paul

You are very kind to have responded with such an explicative post! It is
most appreciated!

Oh I know that this is a long project !!!!

As for the WIFI, I can always get a USB chip set, I have seen them on the
market.
But then how can I make sure it will be compatible with WCE and the
reference board I would buy.

As for the touch screen, it has to be 24 bit color TFT or LCD, 4" x 5"
max.
This is just the type of stuff that I am confused about:

"(CRT, LCD with ordinary LCD I/O or a VGA interface, which standard LCD
panels don't
have, mostly)"

What do you mean by VGA interface?

*Usually* the processor connects to a display controller which connects to
the LCD and WCE should have the required libraries to speak to this
controller. More than this!!!! I don't know, I would need a vendor that
sells
a reference board with this stuff on board and ready to work with WCE....
This part is sort of shady for me! I am sorry Paul, I don't understand
this
stuff enough to under go an intelligent discussion of my requirements!

As for as the proximity issue, I can design an electronic board that
captures motion where a digital signal can be sent to one of the digital
inputs of the x86. So if I read TRUE, then there is motion, if I read
FALSE,
then there is no motion!

As far as the packaging is concerned, I must build this in a case and this
is pretty much what needs to be done in terms of functionality.

Can you please, gracefully, confirm the way I understand the following two
subjects, I am having so much trouble understanding the terminology that
explains SDK and BSP? I don't know why?

-As for the term BSP, from your post, the way I understand it, is that the
reference board has to have a software that communicates between Windows
CE
and the specific hardware on the board and this software usually comes
with
the reference board so WCE can have access to ex: USB, display
controller...
and so forth... right?

-In Robert's E. Zaret's post he mentions that generally we must choose a
platform(Which is the reference board Right?), and then get the SDK for
it,
(which is the Software required to burn the WCE image on the processor
Right?
and can it be the SDK from Microsoft.... ie: platform builder?) and then
we
must make sure we get the compiler that works with that SDK.(Can it be
eVC++
or Visual studion?)

I was wondering, if Microsoft can suggest me a vendor that can sell me an
x86 reference board which can be programmed with eVC++ or Visual studio
and
where I can cofigure the WCE OS with platform builder ?

Thankyou Paul!

--
Best regards
Robert


"Paul G. Tobey [eMVP]" wrote:

OK, that's definitely a custom device. In virtually *all* cases, drivers
will be the thing that limits your ability to hook up random devices to
the
system. It looks to me like you could do the following hardware:

1. You need some means of connecting a WiFi device. The ones that you
can
most-easily use with Windows CE are USB and PCMCIA. So, you'll have to
count up the number of ways to connect devices to whatever hardware you
choose and make sure you have enough.

**2**. Touchscreen/display is a problem unless you do everything yourself
because there's no standard way to connect it. There is at least one
standard touchscreen manufacturer out there that has a CE driver. You
can
use GoogleGroups at groups.google.com to search the archives for them.
Have
you identified some kind of a display device that hooks to VGA and has
touchscreen for PS/2 or USB on it? You need to concentrate on this one
until you figure out how you're going to do it. It's the one that you
are
furthest from implementing, since you don't know how you're going to hook
up
the touchscreen and you need to define what 'display' means to you (CRT,
LCD
with ordinary LCD I/O or a VGA interface, which standard LCD panels don't
have, mostly).

3. The camera has recently been 'solved' as long as you use *one*
particular
USB camera by an open-source project started by MS. Look at
http://msdn.microsoft.com/embedded/usewinemb/ce/sharedsrccode/usbdriver/default.aspx

4. I don't know *what* you are going to do for proximity. We've used
proximity sensors that have RS-232 outputs, but not with CE. You'd have
to
figure out exactly what to do about that on your device and build
something
suitable into the OS. Of course, if it's serial, you can just code
serial
I/O into your own 'proximity driver' or something, but, of course, that's
custom code.

All-in-all, after figuring out how you're going to do #2 above, I'd start
off looking at a board based on a VIA processor (x86, PC-like thing).
You
need a board that has a Windows CE Board Support Package for it, of
course,
as you don't want to have to create such a thing. That BSP will handle
the
initialization of the on-board devices, will provide the drivers for
those,
as well as for the I/O that's already on the board (display controller,
USB
host, PCMCIA, if appropriate).

For software development, look at it as two pieces: 1) the operating
system,
support for the underlying main board, and the drivers for the peripheral
devices, and 2) the actual application software that will handle
detection
of people nearby, reading of camera data and display of other user
pictures
from remote cameras, network communication, handling disconnected state
of
network (which will occur if you are using wireless, absolutely). The
components of item 1 above will be developed with Platform Builder. The
components of item 2 above will be developed with either eMbedded Visual
C++
4.0 or Visual Studio 2005. Since you are building the OS and can
generate
the SDK yourself, you can choose which application development
environment
you want to use.

Further, how is this going to be packaged? It's just a loose board with
a
display somehow connected to it and a camera that the user plugs in? Or
are
you building it into a case? Does it do anything other than provide
visual
communication between nodes and indication of user presence at a node?

We actually have a device in development that would handle much of this
stuff (no proximity or camera, although you could use the driver
mentioned
above and USB to connect it). I can't go into details about when it will
be
done or how much it's going to cost, but you could contact me off-line if
you want to talk about it in some more detail.

This is a multi-man-year project -- I hope that you've figured that out
already!

Paul Tobey
New Product Development Manager
Intelligent Instrumentation
p <dot> tobey <at> instrument <dot> com


"Robby" <Robby@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:05CA02A1-6AE5-49CE-89FD-65064532723C@xxxxxxxxxxxxxxxx
Hi Paul!

Firs and fore-most, thankyou for your post.

My project consists of several points in a commercial plant where each
point
is an embeded board running WCE. Each point must be able to talk to
each
other using the WIFI medium. Also, each point must have a 4" inch touch
screen display and a small camera so that the users at each point can
visually see each other.(Meaning say, at the top left corner you can
see
onother user at another remote point located within the same building.
And
where the rest of the screen would be buttons or list box controls and
so
forth....)

Furthermore, only if the user is in the proximity of his point (Say 2
ft
or
closer to the embeded board), then the other points are informed that
there
is a user present at that point.

I can go on.... however I think you get the idea.

I am not expecting to find a vendor to sell me a reference board with a
camera and the motion detector and IOs..... I can do that stuff using a
USB
port on the refernce board and connect some of my own interface
electronic
boards or a USB camera.

But I don't know where exactly to start or where I can buy a board that
would suit this application. Also, will WCE have all the drivers to do
this
through eVC++ or Visual studio.

Let me know if you want more detail....

Your time is much appreciated!

Thankyou!
.