Re: Vs2005 to PDA to Rs232 interface
- From: "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com>
- Date: Wed, 12 Apr 2006 16:14:07 -0700
So, use that as an XML test just for reading the data set, but use .NET CF
1.0 and code the application for the real target device.
Windows CE 5.0 is not different enough from 4.2 to warrant any sort of
operation like this. The version of IE in there is newer, etc., but the OS
isn't different enough for you to care about from the application layer at
all.
Serial support in 2.0 is basically the same as OpenNETCF 1.4, so...
Your last paragraph lost me, or part of it did. No, I can't quote you a
date when .NET CF 2.0sp1 will be available. Soon, roughly. Are you asking
whether adding .NET CF 2.0 to the 4.2 build you already have should be
easier than making CE 5 run on your device? Yes, probably. I don't have
the service pack in my hands, either, so I can't speak from experience, but,
in that case, you don't have to port the board support package and other
low-level stuff to a new operating sysem, you *presumably* just have to
include a new set of run-time files for .NET CF 2.0sp1...
Paul T.
"John Olbert" <someone@xxxxxxxx> wrote in message
news:7A0A3ACC-7002-4DDD-BAC5-D6881EC591B5@xxxxxxxxxxxxxxxx
The main issue was the speed improvement of the DataSet.ReadXml(). The
present App (which is a migration of a Desktop to Netcf1.0 takes about 60
seconds to load in the device. The majority of that time is spent
de-serializing the various DataSet's from Xml files. We are looking at
doing
a custom serialization/de-serialization on a DataSet but we are still
interested in the speedup on going to Netcf2.0.
I realize comparing the Dell x51v to our pcb is apples to oranges but it
would give us a feel for the speed improvementl. Also it would let us
deploy
to a piece of hardware that support WinCe5.0. I also believe that Vs2005
does
not have a emulator for WinCe5.0 at this time.
There is also interest in the standalone DataTable (serializable) and the
support for Rs232 in the Netcf2.0.
You mentioned that the Netcf2.0 would be available soon for WinCe4.2. Do
you
have any idea of the schedule. For various internal reasons we are have
difficulty getting the resources to upgrade our pcb to the WinCe5.0. I am
not
a firmware developer but I assume that upgrading the WinCe4.2 would be
considerably easier then switching to WinCe5.0.
Thanks.
--
John Olbert
"Paul G. Tobey [eMVP]" wrote:
Yes, true, but how much effort will you be putting into making something
that has no value for the final application work? Of course, .NET CF 2.0
will also be supported on 4.2 devices fairly soon, in the first service
pack. Unless you really, really need something that literally is *not*
in
1.0, I see no reason to start out targeting 2.0. If you target 1.0 and
then
switch to 2.0 later, you get the faster XML stuff, assuming you need
that,
with no cost.
Do you need the new functionality? What part?
Paul T.
"John Olbert" <someone@xxxxxxxx> wrote in message
news:68743EF1-1A46-4E6A-8E75-A4CD24699187@xxxxxxxxxxxxxxxx
DataSet.ReadXml() is fairly slow in Netcf1.0. The articles online
indicate
a
significant speed improvement with Netcf2.0. Also there is some new
functionality.
Thanks.
--
John Olbert
"Paul G. Tobey [eMVP]" wrote:
So, why do you need .NET CF 2.0? Seems like 1.0 would be fine for
most
things and that would allow you to use the real device immediately.
Paul T.
"John Olbert" <someone@xxxxxxxx> wrote in message
news:4DEF191F-48D9-41E4-90F1-2FC20C6ACA9E@xxxxxxxxxxxxxxxx
It sounds like this approach is either not going to work or would
not
be
easy. Our problem is that the device we are using which is an
industrial
grade device (with Internet, Rs232 and Usb connections) is not due
to
be
upgraded to WinCe5.0 for some time. We wanted to use Vs2005 and
Netcf2.0
which is not presently supported on this box which is still at the
WinCe4.2
level.
We wanted to get a start on developing for our target devices (they
are
instruments that are used by chemists and go from Mass Spectrometers
to
simple liquid valves used in Liquid Chromotography). I suspect that
we
can
still use the Dell PDA to deploy to but to attempt to have a "PC--to
PDA--to
Device" link up is asking a bit much of the PDA.
Thanks for the guidance.
--
John Olbert
"Paul G. Tobey [eMVP]" wrote:
I don't quite understand what you're thinking. You're going to
test
this
on
a device that can't actually be used for this in the field? The
only
way
to
connect from USB to serial in your situation would be an adapter
that
plugs
into the Dell and has an RS-232 on the output side. This would
only
drive a
single device, of course, as RS-232 is not a bus. Also, the Dell
would
have
to have a driver for that USB-to-serial device. Further, the
scheme
requires that the Dell device have a *host* USB port, not just a
slave
port,
like that used to connect to a PC for ActiveSync communication.
The
two
ends of USB are different and operate differently. If the Dell has
a
host
port, as well as the client port that it must have, that's at least
part
workable, but there are so many problems beyond that that I don't
see
the
overall scheme as sensible.
USB is *not* generally daisy-chainable. You could, in theory, have
a
couple
of USB hubs, each giving you four ports, say, each and plugged into
each
port you could have a USB-to-serial device. I've never tried to do
something like that, but it seems unlikely to work smoothly, but it
could,
if you can find a driver for the USB-to-serial piece for the Dell
(and
if
the Dell has a USB host port), in theory work.
How many external devices are connected *at a time*? If it's one
and
you're
just moving the screen-based device around to capture the data, use
a
device
that has a serial port! It's so much simpler that it's not even
funny.
If
you need to connect to bunches of devices all continuously and the
central
device doesn't need to be portable, you should look at some other
Windows
CE-based device that will handle that number of serial ports. If
you're
interested, we have a unit that can handle at least 16 or 20 RS-232
ports
(they're added in groups of two or four at a time, as modules).
It's
an
industrial device with no UI, but you could easily use your Dell
device
as
the UI and use network programming to send the accumulated data
from
the
RS-232 'aggregator' to the Dell via 802.11 or something.
www.edasce.com.
Paul T.
"John Olbert" <someone@xxxxxxxx> wrote in message
news:376635CC-6E32-4C3C-A01B-0697488BDEE6@xxxxxxxxxxxxxxxx
In a privious reply it was indicated that a device like the Dell
Axim
X51v
PDA which supports Windows Mobile 5 could be used to deploy and
test
Netcf2.0
App's written in C# using Vs2005. The device supports a Usb
connection
to
the
Pc.
What we are trying to do is use the Dell x51v as a test bed for
programs
that will be used to control analytical instruments and
components.
Most
of
the latter use a Rs232 interface.
Assuming there is a device out there that will take a Usb
connection
and
allow communication with a Rs232 connection, is it possible to
daisy-chain
devices on a Usb. That is, have the PC (with Vs2005) communicate
with
the
Dell X51v via its Usb and have another Usb going to the
hypothetical
Usb/Rs232 box which in turn would communicate with the external
instrument?
Any suggestions would be appreciated.
--John Olbert
javo2000@xxxxxxxx
--
John Olbert
.
- References:
- Re: Vs2005 to PDA to Rs232 interface
- From: Paul G. Tobey [eMVP]
- Re: Vs2005 to PDA to Rs232 interface
- From: John Olbert
- Re: Vs2005 to PDA to Rs232 interface
- From: Paul G. Tobey [eMVP]
- Re: Vs2005 to PDA to Rs232 interface
- From: John Olbert
- Re: Vs2005 to PDA to Rs232 interface
- From: Paul G. Tobey [eMVP]
- Re: Vs2005 to PDA to Rs232 interface
- From: John Olbert
- Re: Vs2005 to PDA to Rs232 interface
- Prev by Date: Re: Getting a referenvce to a form
- Next by Date: Re: Out of memory exception loading a bitmap from a stream
- Previous by thread: Re: Vs2005 to PDA to Rs232 interface
- Next by thread: Re: Vs2005 to PDA to Rs232 interface
- Index(es):
Relevant Pages
|
